I don't have experience with counter mode for SSL (if there is even such a beast) or the NIST mode you are referencing (I believe Ipsec was looking at that mode a few months ago) but I do have experience with counter mode for SRTP (secure RTP; encryption of media streams). In fact, I wrote a counter mode encryptor/decryptor using the EVP_* functions.
CTR mode is not mentioned in the FIPS 197 document, NIST SP 800-38A specifies the CTR mode(s). This is a recommendation document, not a standards document. See appendix B.2 for a discussion of CTR values. This doc discusses the use of half the 128 bits as a nonce, and the remaining bits as a counter.
Lipmaa, Rogaway and Wagner is the definitive recommendation for CTR mode operation, and the mode exists as part of AES (as opposed to Rijndael) because of Helger's efforts. They explicitly state
Usage scenarios. In the recommended usage scenario, the party encrypting maintains an integer counter, nonce, initially 0, and produces the string ctr as the 128-bit string which encodes the number nonce . 2^64. (In other words, nonce is regarded as a 64-bit binary number, and ctr is constructed by appending to this number 64 zero-bits.) The number nonce is incremented following each encryption.
Using AES Counter Mode With IPsec ESP - This mandates a 32-bit counter, requiring rekeying after 2^48 octets of stream material.
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).
Comments? Rich? Richard? Stephen?
--
"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]
