Re: [Cfrg] OCB test vectors reusing nonces

[Ted Krovetz <[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.

-Ted

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
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> http://www.irtf.org/mailman/listinfo/cfrg