Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [P1619-2] EME-2 additional test vector



> I think that test cases 9 & 10 are still useful in their own right because they check tricky edge conditions
> that are not necessarily handled for larger lengths.
 
Which "tricky edge condition" would that be then? Neither of these test anything that the 4129 byte vector doesn't, since 2065 and 4129 bytes are both N>128 blocks plus 1 byte, so both test the same middle layer special case, and the same final block handling. If one was looking for really comprehensive test vector coverage, you would test all byte ending positions too, ie N blocks + 1..15 bytes, but this would only need to be done once with a small N value.
 
Colin.

-----Original Message-----
From: Matt Ball [mailto:matthew.v.ball@xxxxxxxxx]
Sent: 02 March 2010 15:58
To: Colin Sinclair
Cc: P1619-2@xxxxxxxxxxxxxxxxx
Subject: Re: [P1619-2] EME-2 additional test vector

Thank you Colin for producing this case.

I think that test cases 9 & 10 are still useful in their own right because they check tricky edge conditions that are not necessarily handled for larger lengths.

Are there any volunteers who can cross-check these test vectors?  Most notably, we'll want someone to extract and verify the test vectors as they appear in the draft, so that we can identify transcription errors.  We have caught errors this way in both the P1619 and P1619.1 standards, so I think it is a valuable exercise.

Thanks!
-Matt

On Tue, Mar 2, 2010 at 8:44 AM, Colin Sinclair <colin@xxxxxxxxxxxxxx> wrote:
I've just created a longer EME2 test case (4129 bytes) using Brian Gladman's current EME code (4 Nov 2008) and GENTEST program.
 
It passes on my implementation, but ideally someone else should verify this before it goes into the standard!
 
Attached is file in same "C-code" format used in Annex C.2 of the specification.
 
Note: I've called this test case 11, but actually I feel test cases 9 & 10 could be dropped in lieu of this new one. Although 9 & 10 are long (2064 & 2065 bytes), they provide only a little extra coverage over test case 8 (520 bytes), whereas this new case provides valuable coverage of the mask updating at blocks 128 and 256. I'll leave this up to the editor/group to decide, but personally I'd rather have fewer more valuable vectors!
 
Cheers,
Colin.
-----Original Message-----
From: Matt Ball [mailto:matthew.v.ball@xxxxxxxxx]
Sent: 04 February 2010 19:26
To: Colin Sinclair
Cc: P1619-2@xxxxxxxxxxxxxxxxx; Laszlo Hars
Subject: Re: [P1619-2] EME-2 definition/choice of M1 in middle layer mask update

Colin, I have submitted these two comments for the recirculation sponsor ballot under your name.

Laszlo, feel to free to also submit a sponsor-ballot comment if you feel there needs to be a correction/clarification concerning the issue you raised.

Still looking for a volunteer to create a new EME2 test case. 

Thanks,
-Matt

On Thu, Feb 4, 2010 at 11:48 AM, Colin Sinclair <colin@xxxxxxxxxxxxxx> wrote:
Summary:
 
1. Use of M1 (*always*) in middle mixing layer 129th block needs to be clarified on Figure 2. The psuedo-code is however correct.
 
2. Need one additional test vector of length at least 4129 bytes to ensure correct Mi computation for i >= 2.
 
I guess I could verify a new vector... now that I have corrected my understanding!
 
Cheers,
Colin.
-----Original Message-----
From: Matt Ball [mailto:matthew.v.ball@xxxxxxxxx]
Sent: 04 February 2010 17:39
To: P1619-2@xxxxxxxxxxxxxxxxx
Subject: Re: [P1619-2] EME-2 definition/choice of M1 in middle layer mask update

We need to make sure that these comments are included in the outstanding sponsor ballot before it closes.  I can submit these comments as 'Rogue Comments', unless someone else in the sponsor ballot pool would like to submit them instead.  Can someone summarize the issues into a brief list?

The other issue is that if we decide to create additional test vectors, we need a volunteer to produce such test vectors, and another volunteer to independently verify.  Are there any takers for producing the test vectors?

Thanks!
-Matt

On Thu, Feb 4, 2010 at 9:52 AM, Shai Halevi <shaih@xxxxxxxxxxxx> wrote:
> Finally, I'll just reiterate that, from a standards viewpoint, the test
> vector coverage is not good enough, because the longest 2065 bytes vector
> does not test Mi computation or usage for i >= 2, which is different to
> the i=1 computation. It is /necessary/ to have a 258.x block vector to
> get full coverage of the branches of the algorithm.

I agree. -- Shai



--
Thanks!

Matt Ball, Chair, IEEE P1619 Security in Storage Working Group
Staff Engineer, Sun Microsystems, Inc.
500 Eldorado Blvd, Bldg #5 BRM05-212, Broomfield, CO 80021
Work: 303-272-7580, Cell: 303-717-2717



--
Thanks!

Matt Ball, Chair, IEEE P1619 Security in Storage Working Group
Staff Engineer, Sun Microsystems, Inc.
500 Eldorado Blvd, Bldg #5 BRM05-212, Broomfield, CO 80021
Work: 303-272-7580, Cell: 303-717-2717



--
Thanks!

Matt Ball, Chair, IEEE P1619 Security in Storage Working Group
Principal Software Engineer, Oracle USA, Inc.
500 Eldorado Blvd, Bldg #5 BRM05-212, Broomfield, CO 80021
Work: 303-272-7580, Cell: 303-717-2717