- '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@ietf.org 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 MalinenPGP id EFC895FA
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
