Hacker News new | past | comments | ask | show | jobs | submit login

t0: Client A sends message (1) to Server for Client B

t1: Server sends message (1) to Client B

t2: Client B fails to decode message (1) due to an outdated key. Sends failure notification to Server

t3: Server sends rekey notification to Client A

t4: (usually <400ms or >1 second) Client A sends rekeyed message (1') to Server for Client B

For t4, if the Server notices the response from Client A came faster than a user could ever have seen and responded to a notification, it now knows Client A is more susceptible to a MitM attack. If, on the other hand, Client A takes an appreciable amount of time to send the rekeyed message (say, 1 second or more) then we know that either there was a network latency, or the user had to respond to a rekey notification before the message was resent. We should be more careful about launching a MitM attack on this class of user.

So, without changing the actual _actions_ that the Server sees, but just the pattern of the timing of those actions, we're still leaking important information.

Note: all numbers completely made up.




Thanks for the extensive answer, indeed if the receiver need to react than this is discoverable.

I was more thinking along the lines of discharging rekeyed messages and not showing the message at all to security conscious receivers. Whether this is behavior is good, I can not say, UX tests could give more insights.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: