Re: Last Call: draft-dharkins-siv-aes (SIV Authenticated Encryption using AES) to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>  - 'SIV Authenticated Encryption using AES '
>    <draft-dharkins-siv-aes-02.txt> as a Proposed Standard
> 
>  The IESG plans to make a decision in the next few weeks, and solicits
>  final comments on this action.  Please send substantive comments to the
>  ietf@xxxxxxxx mailing lists by 2008-06-10.

It looks like there are couple of small errors in the draft that can
result in incorrect interpretation of the design:

2.2.  Overview

   SIV-AES uses AES in counter mode (CTR) and in CMAC mode (S2V).  SIV-
   AES takes either a 256, 384, or 512 bit key (which is broken up into
   two equal-sized keys, one for CTR and the other for S2V), a variable

While this is not strictly speaking incorrect statement, it would be
clearer to swap the order of CTR and S2V in the description of the keys
here since the first half of the key is actually used for S2V as
specified in more formal description later in the draft.


2.5.  CTR
   Before beginning counter mode the 32nd and 64th bits (where the
   rightmost bit is the 0th bit) of the counter are cleared.  This

2.6.  SIV Encrypt
   SIV-ENCRYPT(K, P, AD1, ..., ADn) {
     Q = V xor (1^64 || 0^1 || 1^31 || 0^1 || 1^31)

2.7.  SIV Decrypt
   SIV-DECRYPT(K, Z, AD1, ..., ADn) {
     Q = V xor (1^64 || 0^1 || 1^31 || 0^1 || 1^31)

The description of pre-processing for the counter is in conflict here.
Chapter 2.5 clears two bits while the SIV-ENCRYPT and SIV-DECRYPT
algorithms are actually swapping lots of bits and not changing the bits
that should have been cleared. It looks like the 'xor' in these
algorithms was supposed to be 'and' which would achieve the desired
clearing of the two bits as defined in 2.5. In addition to this change,
'and' should be added into chapter 2.1 with similar description to 'xor'
since this is the first use of 'A and B' notation in the draft.


A.2.  Nonce-based Authenticated Encryption Example

   Plaintext:
           74686973 20697320 74686520 706c6169
           6e746578 7420746f 20656e63 72797074
           20757369 6e672053 49562d41 4553

   xorend:
           74686973 20697320 736f6d65 20706c61
           696e7465 78742074 6f20656e 63727966
           2d0c6201 f3341575 342a3745 f5c625

   ciphertext:
           cb900f2f ddbe4043 26601965 c889bf17
           dba77ceb 094fa663 b7a3f748 ba8af829
           ea64ad54 4a272e9c 485b62a3 fd5c0d

There seems to be a typo here in the second test vector. The lengths of
the plaintext, xorend, and ciphertext should be the same. However, the
described plaintext is one octet shorter than xorend/ciphertext. Based
on the ASCII presentation of the plaintext and beginning of xorend
value, it looks like the plaintext value should start "this is some
plaintext", not "this is the plaintext" in order to end up with the
described output of the test case. In other words, the Plaintext for A.2
should be changed to:

   Plaintext:
           74686973 20697320 736f6d65 20706c61
           696e7465 78742074 6f20656e 63727970
           74207573 696e6720 5349562d 414553


With the changes described above, I can reproduce matching results for
the test vectors.

-- 
Jouni Malinen                                            PGP id EFC895FA
_______________________________________________
IETF mailing list
IETF@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]