Work-item: generic test-suite for new abstract.Cipher interface about kyber HOT 14 CLOSED

Initial work can be found here https://github.com/davidiw/crypto/tree/ciphertest

from kyber.

Added a few more (Partial and PRNG) here https://github.com/bogiebro/crypto/tree/ciphertest

from kyber.

Great, could you cherry pick your changes onto my new ciphertest branch? I
hadn't realized you had already started coding, so I just merged my commits
into a single commit. If nothing else, pull in and merge with my current
branch so that you get the right tests and the fix to cipher/stream.go

Cheers,
David

On Sat, Feb 7, 2015 at 11:22 AM, Sam Anklesaria [email protected]
wrote:

Added a few more (Partial and PRNG) here
https://github.com/bogiebro/crypto/tree/ciphertest

—
Reply to this email directly or view it on GitHub
#24 (comment).

from kyber.

Whoops- didn't see this. I think everything's merged in now.

from kyber.

Any update on this? Is there a branch somewhere with the current test code, even if still incomplete?

from kyber.

Seeing as how there hasn't been pull requests on this in 2 weeks, but I want tests , I'm making a pull request with where I left off. I hope that others who have taken this task follow up and push upwards there changes soon :).

from kyber.

I have all of David's changes in a local branch but I can't see the changes made by @bogiebro; for some reason the link you posted above isn't working anymore and I don't see the Partial or PRNG tests anywhere.

I wrote my own PRNG test and I'm trying to write the Partial tests but I'm a little confused about how cipher.Partial works. In particular, if I'm splitting up a 1MB message into 1KB chunks, does that mean I should call:

cipher.Partial(dst[:1024], src[:1024], key[:(keysize/1024)]

and then iterate through every division of the dst, src, and key? My biggest confusion is about the key specifically; as I understand it, the value returned by cipher.KeySize() depends only on the cipher itself, so it might be much smaller than a 1MB input string. Is the general approach still to subdivide the key into as many equal parts as you're dividing the input text into?

from kyber.

What is 'key' supposed to mean in this context? What are you trying to test in this particular test-case? If it's an "unkeyed PRNG" test, then the 'key' argument to cipher.Partial should simply be null. If you're doing a keyed PRNG test, then you should first call cipher.Message(nil, nil, key) to absorb the key/seed material, and then call cipher.Partial(dst, src, nil) any number of times to obtain pseudorandom bits from the cipher. You have to key the cipher first, then get the output bits. Make sense?

from kyber.

Sorry; my question was unclear, but I think your answer gives me the information I need anyway.

This is not for the PRNG test. I was trying to test the invariant that encrypting a message all at once with cipher.Message(dst, src, key) is equivalent to encrypting the message in chunks with multiple calls to cipher.Partial, where the parameters I pass to cipher.Partial are divisions of the total dst and src arrays. My question was if I'm dividing the message up into chunks like that then should I also divide the key up in a corresponding way, but now I realize that that makes no sense.

I'm assuming the correct method is to call cipher.Message(nil,nil,key) to absorb the key and then call cipher.Partial many times to absorb the message incrementally, and then once the full message is absorbed the final ciphertext should be equal to the ciphertext produced by a single call of the form cipher.Message(dst,src,key).

Is that correct?

from kyber.

Actually, if you're testing for the equivalence between multiple Partial calls vs one Message calls, then that equivalence should hold for any values of any of the arguments, and you should be testing all of them: i.e., with or without dst, src, and/or key slices. In particular, Message and Partial may be called with all of dst, src, and key slices (which is used in authenticated encryption), and in that case you should be calling Partial with the same number of bytes passed in each slice argument, until you "run out of bytes" in any of the argument slices.

Ideally, you should also have a TestPartial function that takes a Cipher and three slices - dst, src, and key - all of which can be of different lengths, and checks that Message(dst, src, key) behaves the same as Message(dstpad, srcpad, keypad) where the '*pad' slices are the same as the corresponding ones but allocated to each be of size max(dst,src,len) and padded with zero bytes at the end. And from that, you should be able to test that breaking those dstpad/srcpad/keypad slices into smaller chunks and passing them to Partial in pieces also produces the same result.

Make sense?

from kyber.

Is this done in https://github.com/dedis/kyber/pull/23/files ? Is it still relevant ?

from kyber.

No idea !?! Perhaps make a list of old Bryan-issues and look if we have time Wednesday?

from kyber.

abstract.Cipher is gone, and the replacement is well enough tested.

from kyber.

Awesome, congrats on the successful weed-whacking job and thanks for all the hard work! :)

from kyber.