[shin_lao]

Your answer raises my eyebrows even more.

I ask why you don't use DH and you answer "because we want forward secrecy". DH has been designed for perfect forward secrecy. Therefore I fear we might have some sort of misunderstanding here.

You don't want to permit known plain text attack as "in depth defense" approach. If there is ever any weakness in your software, you want to make it very hard to exploit it. Known plaintext will make exploiting weaknesses in your PRNG very easy for example.

As for your last comment... If someone ever changes the behavior of read_packet, you're dead. So I'm sorry, but you have potential buffer overflow. Think in 4 dimensions Marty! :)

[tptacek]

DH wasn't designed for forward secrecy.

[shin_lao]

True, my usage of designed was a little bit liberal here. Mr. Diffie is one of the authors of the first paper to introduce the concept of PFS, but the DH key exchange algorithm hasn't been designed for PFS but rather for 0-knowledge key exchange.

Nevertheless, I stand by my remark regarding the pertinence of DH in that case.

[tptacek]

DH is also not a zero-knowledge key exchange algorithm. I think what's confusing you is that DH (a) is a useful building block for forward-secret protocols and (b) generates secrets that often require zero-knowledge proofs.

I'm not sure what paper you're referring to but wouldn't be surprised if Diffie's name was on one of the first "forward secrecy" papers; that stuff is/was kind of Whit Diffie's beat (not "privacy" per se, but the higher-layer implications of public key cryptosystems). But Diffie-Hellman predates any formalized notion of forward secrecy by something like 20 years.

[shin_lao]

DH is zero-knowledge in the sense that the two peers have no knowledge of each other, and yet share a knowledge at the end.

Again, I admit my word usage is a little bit liberal, but although I haven't done serious crypto for a couple of years now, I have the strange feeling you are nitpicking. Is it just a feeling? :)

I'm referring to this paper: http://link.springer.com/article/10.1007%2FBF00124891

Curiously, although I've always preferred DLP-based crypto, I actually never implemented any. So I gladly admit my knowledge of DH key exchange might not be as profound as I would like it to be.

[tptacek]

That's not what "zero knowledge" means. In the context of STS or, more generally, DH, a ZKP is something you'd add after DH, to verify that one party or the other had arrived at the expected DH result.

I don't think I'm nitpicking: I see where you're coming from but I think you might be entirely wrong.

I don't know what it means to "prefer" DLP crypto. Over what? I just don't understand what you're trying to say with that last graf.

[shin_lao]

Well, if you exchange your keys via DH and start using that key to cipher the communication, you're going to find out very soon if you exchanged the key properly, won't you?

In essence, once you've agreed on a key you won't keep it to yourself (although you could, in theory). But am I missing the point? Are we talking about two different things? I'm talking about ZK from a mathematical point of view, you know, the cavern, the treasure, the two paths... (if you know this layman example about ZK)

Unfortunately I cannot go into details, but what I meant about my preference for DLP is that although I was mathematically more attracted to DLP based algorithms (when it came to asymmetric cryptography) I didn't really have the chance to "play" with them and spent more time with RSA.

So it's probable my knowledge of the DH key exchange algorithm is imperfect and last time I wrote crypto it was very mundane (it was using RC4, that's saying a lot!), so maybe I should just refrain from commenting about crypto.

[ZoF]

Please explain how DH was designed for perfect forward secrecy...

Please explain why shown plain text in this context would make exploiting weaknesses in their PRNG any easier...