In theory, you may be right ;-). But: For one, I think that it can't hurt NOT to have complete confidence in the cipher. I prefer to err on the safe side. E.G. if an attack profits from having the same plaintext encrypted twice with different cipher texts, we would encounter these conditions a lot in http over SSL/TLS. This would be avoided by a nonce in the IV.
A good block cipher will change many bits in its output with a single changed bit in its input. There is no advantage to "whitening" the unused counter bits, cryptographically speaking -- use 128-, 192- or 256-bit key, and rely on the size of the keyspace (and limiting use of keystream).
"the same plaintext encrypted twice with different cipher texts" is actually KPA. We assume normally that many ciphertexts contain known bits of plaintext, and should only use ciphers that provide protection against this. All the extra caveats apply when using stream ciphers.
And also, we should take into account that a lot of people use OpenSSL's crypto routines in another context than SSL/TLS.
Right. Important to support the modes you mentioned, IPsec and Lipmaa/Rogaway.
My objection was to the use of a salt/IV/nonce in TLS/SSL without a sound theoretical motivation. Adding suspenders to the belt as protection doesn't make your zipper any stronger, if you'll forgive the analogy.
So, there are two issues (you may find more):
1) Support AES CTR mode in libcrypto, with support
for the usual modes of its use (IPsec included); 2) Do we pursue adoption of even an unofficial
AES CTR mode cipher for SSL/TLS? This could be
done simply by publishing a draft.--
"Well," Brahma said, "even after ten thousand explanations, a fool is no
wiser, but an intelligent man requires only two thousand five hundred."
- The Mahabharata______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
