Re: [Cfrg] OCB test vectors reusing nonces

["Manger, James" <[e-mail]>]

> From: Ted Krovetz [mailto:[e-mail]]
> 
> Thanks James for verifying the vectors.
> 
> I'm reluctant to modify the draft this substantially at this point in
> the process. Such a change might significantly delay its progress.
> 
> Although I agree that your selection of tests is probably better than
> those in the draft, I also believe that the vectors in the draft along
> with reference implementations is sufficient to produce a correct
> implementation.


8 of the ciphertexts in appendix A start identically (BEA5E8798DB...) and 2 others start identically (92B657130A7...).
This does not look good. It causes confusion.
That is exactly the sort of behaviour that is supposed to be prevented by the provable security OCB enjoys.

OCB has a nice design feature that allows the AES operation applied to the nonce to be avoided 63 out of 64 times, if using incrementing nonces.
It is far more likely that this design feature will be tested if appendix A uses incrementing nonces (particularly for the 385 operations in each of the last tests).

For the above two reasons I think it would be worth updating the test vectors, despite some risk of causing a slight delay. Surely the draft doesn’t have to repeat much of the vetting process if only sample results change. I am willing to confirm new test vectors quickly.


Earlier I suggested nonces such as:
  N = zeros(80) || num2str(i,8) || num2str(1,8) 
  N = zeros(80) || num2str(i,8) || num2str(2,8) 
  N = zeros(80) || num2str(i,8) || num2str(3,8) 

If you do make a change, it would be even better for the nonces to be:
  N = num2str(3*i+1,96)
  N = num2str(3*i+2,96)
  N = num2str(3*i+3,96)

Or phrase it as:
  N = zeros(96)      // incremented before each use
  for i = 0 to 127 do
     S = zeros(8i)                   // i bytes of zeros
     N = N + 1
     C = C || OCB-ENCRYPT(K,N,S,S)
     N = N + 1
     C = C || OCB-ENCRYPT(K,N,<empty string>,S)
     N = N + 1
     C = C || OCB-ENCRYPT(K,N,S,<empty string>)
  end for
  N = N + 1          // 00...0181 after 385 increments
  Output : OCB-ENCRYPT(K,N,C,<empty string>)

--
James Manger



> On Jan 22, 2014, at 10:13 PM, Manger, James
> <[e-mail]> wrote:
> 
> > I have implemented OCB authenticated encryption as per draft-irtf-
> cfrg-ocb-05.
> > I concur with the sample results in Appendix A.
> >
> > The sample results include 16 { aad, plaintext, ciphertext} tuples,
> but they are all for a tag length of 128.
> > It would be nice to include 1 similar sample with another tag length
> (in addition to the final section of Appendix A that does include
> results for other tag lengths, but only after a more complex
> combination of 385 encryptions).
> >
> > The first 16 samples all use the same key and nonce.
> > The last 9 samples involve reusing key & nonce pairs 3 times.
> > A crucial feature of OCB is that a key & nonce pair MUST NOT be
> reused.
> > The sample results should not violate this crucial condition.
> > The samples might actually be hard to run in some implementations
> that take strong measures to prevent nonce reuse.
> >
> > I suggest using incrementing nonces for the samples:
> > OLD
> >    Each of the following (A,P,C) triples show the ciphertext C that
> >    results from OCB-ENCRYPT(K,N,A,P) when K and N are fixed with the
> >    values
> >
> >    K : 000102030405060708090A0B0C0D0E0F
> >    N : 000102030405060708090A0B
> >
> >
> >    An empty entry indicates the empty string.
> >
> >      A:
> >      P:
> >      C: 197B9C3C441D3C83EAFB2BEF633B9182
> >
> >      A: 0001020304050607
> >      P: 0001020304050607
> >      C: 92B657130A74B85A16DC76A46D47E1EAD537209E8A96D14E
> >    ...
> >
> > NEW
> >    Each of the following (N,A,P,C) tuples show the ciphertext C that
> >    results from OCB-ENCRYPT(K,N,A,P) when K is fixed with the
> >    value
> >
> >    K : 000102030405060708090A0B0C0D0E0F
> >
> >
> >    An empty entry indicates the empty string. The nonces are
> incrementing.
> >
> >      N: BBAA99887766554433221100
> >      A:
> >      P:
> >      C: 785407BFFFC8AD9EDCC5520AC9111EE6
> >
> >      N: BBAA99887766554433221101
> >      A: 0001020304050607
> >      P: 0001020304050607
> >      C: 6820B3657B6F615A5725BDA0D3B4EB3A257C9AF1F8F03009
> >    ...
> >
> > OLD
> >    K = zeros(KEYLEN)                  // Keylength of AES in use
> >    C = <empty string>
> >    for i = 0 to 127 do
> >       S = zeros(8i)                   // i bytes of zeros
> >       N = zeros(88) || num2str(i,8)   // 11 byte zero then 1 byte i
> >       C = C || OCB-ENCRYPT(K,N,S,S)
> >       C = C || OCB-ENCRYPT(K,N,<empty string>,S)
> >       C = C || OCB-ENCRYPT(K,N,S,<empty string>)
> >    end for
> >    N = zeros(96)
> >    Output : OCB-ENCRYPT(K,N,C,<empty string>)
> >
> > NEW
> >    K = zeros(KEYLEN)                  // Keylength of AES in use
> >    C = <empty string>
> >    for i = 0 to 127 do
> >       S = zeros(8i)                   // i bytes of zeros
> >       N = zeros(80) || num2str(i,8) || num2str(1,8)
> >       C = C || OCB-ENCRYPT(K,N,S,S)
> >       N = zeros(80) || num2str(i,8) || num2str(2,8)
> >       C = C || OCB-ENCRYPT(K,N,<empty string>,S)
> >       N = zeros(80) || num2str(i,8) || num2str(3,8)
> >       C = C || OCB-ENCRYPT(K,N,S,<empty string>)
> >    end for
> >    N = zeros(96)
> >    Output : OCB-ENCRYPT(K,N,C,<empty string>)
> >
> >    ...and change the results accordingly...
> >
> >
> > Other than these tweak to the samples, the OCB spec looks great.
> >
> > --
> > James Manger