Daniel Kahn Gillmor dkg@fifthhorseman.net writes:
i've been reading the latest nettle docs [0], and i wanted to say that they are excellent. Clear explanations, and useful contextual help about how various crypto primitives can be used in real-world settings as well.
Thanks!
Section 6.5 contains the following paragraph:
Besides signing meaningful messages, digital signatures can be used for authorization. [...]
This simple scheme is actually vulnerable to a replay attack: an man-in-the-middle attacker can pose as the service to the user while simultaneously connecting to the service directly. The attacker gets a nonce from the server, passes it to the user for signing, returns the user's response to the service, and gains access.
One way to avoid this is to ensure that the "random nonce" to be signed by the user is actually a negotiated value that neither party can fully control.
Right. A common and reasonable way to handle it is by negotiating a session key using DH, use that key for message authentication of the session (and why not also encryption, while we're at it). Then either side can let the other authenticate itself by signing a nonce which is not an independent random value, but computed in some way from the session key.
I have to think a bit more on how to explain this in a concise way, any suggestions? I think it may be appropriate to not recommend any protocol which doesn't include some kind of authentication of the session. And from this point of view, the session-key thing can be seen as an optimization, where the alternative is to sign each message.
- "bad things may happen", "a few subtle issues", etc. should have
outbound links
There are several places in the docs that mention potential security concerns implementators should be aware of. For example, the remark about CBC providing "information leakage" could link to http://www.kb.cert.org/vuls/id/958563
I've added this link. Patches for other missing references are appreciated...
Regards, /Niels