[Cryptech Tech] [Cryptech-Commits] [user/sra/aes-keywrap] 01/01: Initial commit of AES Key Wrap implementation.

[Rob Austein]

At Mon, 04 May 2015 08:43:06 +0200, Joachim Strömbergson wrote:
> 
> Good to see a model for the keywrap. I didn't know you were going to do
> one though Rob.

Nor I you.

> I started working on a keywrap HW implementation and looked for a
> model (I started writing a Python model too). Now I have something
> to work against. ;-)

Cool.

Randy, Basil, and I talked with Russ about this algorithm at the
Dallas IETF meeting.  A few points that may not be obvious:

1) You just want the RFC 5649 version.  This pulls in portions of RFC
   3394 by reference, but you just want those parts, not full RFC 3394
   or the original variable-length variation that preceded RFC 5649.

2) For the portions that do come from RFC 3394, be warned that RFC
   3394 specifies the steps in two different ways, one intended for
   software, the other (perhaps) better suited for hardware.  I did
   the software version, you will probably want to evaluate which path
   is better for your purposes.

3) My test cases include the two test vectors from RFC 5649, a few
   deliberately broken cases (altered KEK, truncated or extended
   wrapped data), and some arbitrary strings to check for silly
   length-related bugs, etc.  Note that all of the deliberately broken
   cases produce the same error (magic number mismatch).  I have not
   thought of a way to write test cases for the other checks required
   in the unwrap phase other than by writing a deliberately broken
   wrap implementation (ie, I would have to deliberately encode the
   wrong m or padding value before encrypting).  Let me know if you
   want me to whack together test vectors for those cases.