{jumping into a discussion somewhat late...}
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.
Counter mode for SRTP is a little different in that the "counter" part, the
part that increments for each keystream block (128 bits, for AES) is only
the lower 16 bits (rtp packets just don't get larger than that...) and the
"application supplied" starting count value (refered to as the packet IV in
SRTP) consumes 112 bits, starting at bit 16.
In general, the most flexible approach would be to provide an aes counter
encrypt function that took a 128 bit starting value (IV), incremented (+1)
it as many times as necessary to form the keystream (dependent on the size
of the buffer that needs encrypting), and performed the encryption and
subsquient xor'ing operation. As far as I can tell, the low bits that are
incremented will *not* overflow, by design, into the upper bits.
It should be up to the calling application to provide the 128 bit 'IV' for
each call to aes_ctr_encrypt(). You shouldn't need any AES_incr_ctr()
function. It's a little messier but it is more flexable and doesn't make
assumptions on where the counter ends and the IV begins.
(128 bit integers are a bit scarce to come by, I used char buffers myself,
which had the advantage of keeping things in network byte order as well).
There was one more generalization that I considered when the incrementation
value (+1 or +1<<64) was still under discussion and that was to have the
application provide the increment value as well but this has performance
impacts.
-lee
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Richard
> Levitte - VMS
> Whacker
> Sent: Monday, June 23, 2003 12:36 PM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: AES counter mode
>
>
> In message <[EMAIL PROTECTED]>
> on Mon, 23 Jun 2003 18:22:37 +0200, Thierry Boivin
> <[EMAIL PROTECTED]> said:
>
> Thierry.Boivin> My understanding of this one is (in a
> practical perspective) is :
> Thierry.Boivin> calling programs maintain a 64 bit long nonce
> counter. This counter is to be incremented by one from
> messages to messages. As this nonce is used to form the high
> part of a 128 bit long counter value -- we add 0 for the low
> part -- , the "counter" element is globally incremented by
> 2**64 from messages to messages. This is for the behavior of
> the calling program. If considering the routine implementing
> the message encryption (so the openssl routine), message is
> to be split into blocks and each block encrypted with a
> specific counter value : first block is used with the initial
> counter given by the application (64 bit long value <<64 + 64
> bit long zeros.). Next blocks of the message are then
> encrypted using a "counter value of blockN = counter value
> of blokcN-1 + 1" operation.
>
> And when should the increment by 2^64 occur? Is that something that
> the application should make sure happens with some kind of call to the
> currently non-existing functino AES_incr_ctr() (perhaps done in
> EVP_EncryptFinal())?
>
> If everyone can agree on such an interpretation, I have no problems
> changing it, as long as it also makes the implement crunch the
> available test vectors properly.
>
> --
> Richard Levitte \ Tunnlandsv�gen 3 \ [EMAIL PROTECTED]
> [EMAIL PROTECTED] \ S-168 36 BROMMA \ T: +46-8-26 52 47
> \ SWEDEN \ or +46-708-26 53 44
> Procurator Odiosus Ex Infernis -- [EMAIL PROTECTED]
> Member of the OpenSSL development team: http://www.openssl.org/
>
> Unsolicited commercial email is subject to an archival fee of $400.
> See <http://www.stacken.kth.se/~levitte/mail/> for more info.
> ______________________________________________________________________
> OpenSSL Project http://www.openssl.org
> Development Mailing List [EMAIL PROTECTED]
> Automated List Manager
> [EMAIL PROTECTED]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
