(I apologize this message is not correctly threaded. I only subscribed to the list recently, and I have found no way to cannot construct a proper In-reply-to header from messages in the archive.)
Peter Fairbrother wrote: > And most of their interception is passive, they just listen - you > generally need at least one plaintext/ciphertext pair to break a > cipher and find a session key, and most often they don't have the > plaintext, just the ciphertext. I agree with everything you have said, except for this. "GET / HTTP/1.1\r\n" is exactly 16 bytes, or one AES block. If the IV is sent in the clear -- which it is -- that is one plaintext-ciphertext pair right there for every HTTPS connection. In fact, _any_ aligned 16 bytes of plaintext in the conversation that are known, or that are in a guessable range, represent a plaintext/ciphertext pair if either of the following are true: 1) You sent the IV in the clear 2) You used CBC mode Of the modes I know (CBC, CTR, GCM, et. al.), the only one that does not freely give up such plaintext/ciphertext pairs is OCB. Of course, we assume our block ciphers are secure against even astronomical numbers plaintext/ciphertext pairs, because any evidence to the contrary would represent a publication-worthy if not Ph.D.-worthy result. But is it really such a good assumption against _this_ adversary? It seems to me that the IV could easily be negotiated at the same time as the session key. 2048-bit or 3072-bit RSA or DH already provide enough bits, so you can have a secret IV, independent of the session key, "for free". ECDH provides enough negotiated bits, too, once you are in the 256+ bit range. So, "avoid CBC" plus "negotiate the IV" seems like a simple way to stir extra entropy into the encryption. It does nothing for any security proofs, since those assume perfectly secure block ciphers... But it might make somebody's job just a little bit harder in practice. And since it would cost nothing, why not? - Nemo _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography