Using AES Counter Mode With IPsec ESP - This mandates a 32-bit counter, requiring rekeying after 2^48 octets of stream material.
Ah, this is interesting. Considering that OpenSSL is not only used for SSL / TLS encryption, and the mentioned RFC proposes to use a 32 bit counter and a 96 bit nonce, whereas other specs (NIST SP 800-38A) as you mention propose a 64 bit counter and a 64 bit nonce, it might be good to expose these differences in the interface of the crypto function and leave this choice to the caller.
There also should be an error condition indicating that no further plaintext can be encoded unless a new key and nonce were generated (i.e. in an SSL/TLS context, a new handshake is required).
>Using AES Counter Mode With IPsec ESP - This mandates a 32-bit counter, >requiring rekeying after 248 octets of stream material.
The counter would overflow after the transmission of 2**32 blocks, a block being 2**4 octets (128 bits, 16 octets), so rekeying should be necessary after 2**36 octets (= 64 GB).
> http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-aes-ctr-04.txt
Argument: let's write an Internet draft that describes the use
of AES CTR mode in SSLv3/TLSv1. We can do it however we like, modulo
the usual criticism and review in the IETF working group(s).
I'd support that, too. If this is done, I would propose to follow the ipsec draft as much as possible (and RFC 3268 of course, which extended TLS/SSL for AES originally - http://www.ietf.org/rfc/rfc3268.txt). There is no need to reinvent the wheel, and the 96 bit nonce / 32 bit counter is indeed appropriate for the bulk of actual communication - it would be a very rare exception that even a 32 bit counter would overflow.
- David
______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
