[no subject]

>
> > When is approval likely to be given ?
>
> It's not really up for approval.  It's out for comments, and I'd
> be happy to hear yours.  If there is sufficient interest in a
> cross-application counter mode spec, then I'll ask about making it an RFC.

I'm not really a cryptography expert, my area is more image processing,
but I do a lot of work in implementing algorithms in general in RTL.
So, I cannot really comment of the security aspect.
However, from an implementation point of view I liked that AES counter
mode you proposed seems readily parallelizable and it only used AES in
encryption mode. Since an encryption only AES module with a 128 bit
key (with no key expander) is only about 8K gates with a max throughput
of ~700 Mbit/s in 0.18 u, it follows that it would be easily possible
to support multigigabit applications with a reasonable gate count.

I also had a look at OCB and it was harder to implement. It also required
AES in both encryption and decryption mode. I don't remember exactly, but
I'm not sure whether it was readily parallelizable.

>
> ICM can be viewed as a specialization of the NIST suggested CTR mode (NIST
> Special Publication 800-38A, Recommendation for Block Cipher Modes of
> Operation - Methods and Techniques, online at
> http://csrc.nist.gov/publications/nistpubs/index.html) to packet
> encryption.
> The NIST document describes a counter mode using 128-bit integer increment
> as the next-counter operation, while icm describes how to use that
> definition to generate keystream segments appropriate for packet
> encryption.
>
> The most important security fact about counter mode is that it should be
> used with a random initial counter.

True random number in hardware are not too hard to generate. The problem
is convincing the ASIC vendor to accept the exotic circuit that
intentionally
violates all their rules :-)

> So no matter what spec you end up
> implementing, please keep that in mind :-)

I wouldn't implement something until it is standard or unless a customer
asks me to.

>
> > Is there any reference C code available ?
>
> There will be sometime soon, as part of the srtp reference code.

Thanks again. Is there a way to keep up to date on this ?
Maybe I can join this mailing list if possible. I don't expect to
contribute,
but I list I can follow when consensus is reached.

>
> dam

Enzo

------------------------------------------------------------------
Vincenzo Liguori
Ocean Logic Pty Ltd
PO BOX 768
Manly NSW 1655
Australia

Ph : +61-2-99054152
Fax : +61-2-99050921
Email : enzo at ocean-logic.com
WWW : http://www.ocean-logic.com