[LinkSec] algorithm choices - criteria
Dear DJ:
Please see below for relevant references to the CCM mode. The CCM mode does
not have any particular advantages compared to a secure composition of an
encryption transformation and a data authenticity transformation, except
maybe for the use of a single key for both transformation (small advantage,
since one can easily derive two keys from one using a kdf function). CCM
requires two message passes (once for authenticity, once for encryption),
requires the length of the message to be known beforehand (thus requiring
buffering), and other disadvantages. I would advise anyone promoting the
use of CCM to consult reference [5] below for a critique. In my view, CCM's
claim to fame is that it was convenient for the 802.11 TGi community at the
time, while it struggled with adopting the far more efficient OCB (and
paying a very modest royalty fee) or go for suggested "royalty-free" status
of CCM and pay a performance penalty. There is not much else to it and
there are numerous other designs available, if one does not want to be
IEEE-centered. If one would like to adopt a so-called AEAD scheme (of which
CCM is only an example), I would advise considering also alternatives in
that space (see, e.g., NIST's mode of operation website, see weblink under
[4]).
For very high data rates, the implementation of an AEAD scheme (that
requires two data passes) might have a higher hardware implementation cost
than just implementing the composition of an encryption transformation
(such as AES-CTR) and an authentication transformation (such as
HMAC-SHA256), for the cost of the latter is mainly dominated by the cost
of performing AES operations (SHA-256 is much faster than AES in hardware).
Thus, CCM might require a higher clockrate or a higher gate count, to hit
the required data rate.
In general, I would like to advise against adopting any cipher that has not
established itself for a reasonably long enough time in the cryptographic
community. Furthermore, proper selection criteria include:
- cryptographic merits
- standardization and endorsement by bodies (e.g., FIPS, ANSI)
- implementation cost in software
- implementation cost in hardware
- re-use of implementation for both encryption and decryption
transformation
- RAM usage for keying material
I did not see any of the above criteria applied in the minutes of
yesterday's (Sep 2, 2003) conference call LinkSec. In fact, I do believe
that the applied crypto suite should be considered as a black box, and the
specification should just describe what the format of inputs and outputs
is. Please also see
http://eprint.iacr.org/2003/177/ and other publications in the IACR ePrint
Archive for proper guidance.
Rene
(cryptographer)
----------------
1.1.1 References
[1] FIPS Pub 113, Computer Data Authentication, Federal Information
Processing Standards Publication 113, US Department of Commerce/N.I.S.T.,
May 30, 1985. Available from http://csrc.nist.gov/.”
[2] R. Housley, D. Whiting, N. Ferguson, Counter with CBC-MAC (CCM),
submitted to N.I.S.T., June 3, 2002. Available from
http://csrc.nist.gov/encryption/modes/proposedmodes/.
[3] J. Jonsson, On the Security of CTR + CBC-MAC, in Proceedings of
Selected Areas in Cryptography – SAC 2002, K. Nyberg, H. Heys, Eds.,
Lecture Notes in Computer Science, Vol. 2595, pp. 76-93, Berlin: Springer,
2002.
[4] J. Jonsson, On the Security of CTR + CBC-MAC, NIST Mode of Operation
– Additional CCM Documentation. Available from
http://csrc.nist.gov/encryption/modes/proposedmodes/.
[5] P. Rogaway, D. Wagner, A Critique of CCM, IACR ePrint Archive
2003-070, April 13, 2003.
"Johnston, Dj"
<dj.johnston@inte
l.com> To
Sent by: "Leech, Marcus
owner-stds-802-li (EXCHANGE:FITZ:8M86)"
nksec@majordomo.i <mleech@NORTELNETWORKS.COM>,
eee.org <stds-802-linksec@ieee.org>
cc
09/03/2003 02:49 Subject
PM RE: [LinkSec] Preliminary view of
header format
Marcus,
The birthday limit is not a problem with CCM. The MIC is encrypted, so
passive collision farming is prevented.
An active attacker is forced to guess MICs and try them, so they don't
have the advantage of the birthday paradox, they need to try 2^64
attempts to expect a packet to be received with a valid MIC, but the
attacker would have no control over the contents and the victim might be
expected to notice 2^64 MIC violations coming in and rekey ahead of
time.
This is why the PN/IV length can be greater than n/2 bits where the MIC
length is n bits.
I haven't looked at the details but the same argument seems to apply to
OCB.
And yes, I did ask a cryptographer before sending this.
DJ
David Johnston
Intel Corporation
Chair, IEEE 802 Handoff ECSG
Email : dj.johnston@intel.com
Tel : 503 380 5578 (Mobile)
Tel : 503 264 3855 (Office)
> -----Original Message-----
> From: Leech, Marcus (EXCHANGE:FITZ:8M86)
> [mailto:mleech@NORTELNETWORKS.COM]
> Sent: Tuesday, September 02, 2003 12:38 PM
> To: stds-802-linksec@ieee.org
> Subject: [LinkSec] Preliminary view of header format
>
>
>
> Here's a preliminary view:
>
> SAID|IV|PAYLOAD|MIC
>
> SAID = 4 bytes Security Association Identifier
> IV = Initialization Vector, 4-16 bytes, depending on ciphersuite
> PAYLOAD = variable length
> MIC = Message Integrity Code, 8-16 bytes, depending on ciphersuite
>
>
> The SAID could be compressed to a single octet if there is
> other implicit context
> "lying around" that can uniquely identify this security
> association. It's not
> clear to me that is possible across all technologies we're
> talking about here,
> so making it 4 bytes (32-bits) would be consistent with
> 802.10, and IPSec.
>
> Given the birthday paradox, I'm inclined to conservatism, and
> perhaps that
> 8-16 bytes for MIC should be 10-16 bytes. It would
> probably be prudent
> to make a statement in each ciphersuite that negotiation of new keys
> (and consequent SAID) should begin when 2**((N/2)-1)
> messages have been
> transmitted under the current key, where N is the MIC size in bits.
>
> --
> ----------------------------------------------------------------------
> Marcus Leech Mail:
> Advisor Phone: (ESN)
> 393-9145 +1 613 763 9145
> Security Architecture and Planning Fax: (ESN)
> 393-2754 +1 613 763 2754
> Nortel Networks mleech@nortelnetworks.com
> -----------------Expressed opinions are my own, not my
> employer's------
>