3 ms·
A timestamp doesn't prevent replay attacks, it just time-limits them. Also, requiring time sync tends to be problematic -- many people have incorrect clocks. Fi
by kentonv 12y ago
A timestamp doesn't prevent replay attacks, it just time-limits them. Also, requiring time sync tends to be problematic -- many people have incorrect clocks. Finally, just because your protocol uses a timestamp at some position doesn't mean some other protocol won't interpret those bits in some other way. Removing server-controlled bits makes an attack harder but not necessarily impossible.
- zaroth 12y agoBut anyone who can get this signed message can also get the session token? Or are the rules of the game this has to work over an unencrypted channel? In which case you need two keys and you do DH.
- kentonv 12y agoI assumed the "time is now" was meant to prevent replays. But yes, it's great if you can establish a secure channel first with a session key generated based on randomness provided by both client and server and then, once the session is up, send a signature of the session key, signed by your long-term key. No timestamp needed, then (I think). (Insert obligatory reminder not to roll your own crypto.) But this is beside the point. You still have the problem that you are signing a thing, and if the signing key isn't restricted to signing only this type of thing, there is a risk that the thing you are signing could have a different meaning when interpreted as a different type. Even if the client fully-controls the content of the thing to be signed, this is still possible. Perhaps you can dismiss it as "unlikely", but I'm not sure I'm comfortable doing so.