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

[Joachim Strömbergson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Aloha!

Rob Austein wrote:
> 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.

Lack of communication. But I did create a ticket for keywrap about two
months ago.

> 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.

Good points. I spent a few hours looking at RFC 3394 and this code:

https://reaver-wps.googlecode.com/svn-history/r3/trunk/src/crypto/aes-wrap.c

The number of 64-bit blocks part of it scares me since the code in RFC
3394 (and the code) seems to suggest that you need to allocate n blocks
of data in order to process a message of n blocks. This would require
the HW to have an upper limit of how big the message (key) we could
wrap. 4096 bits etc.

The second, SW targeted version in RFC 3394 actually looks better from a
HW point of view too.

But I need to look at RFC 5649 and you models.


> 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.

Lets start with these. Really, really good to have these test vectors
and your models. If there isn't yet a way to make the models dump
internal values during processing I would appreciate having it.

That would include what is returned from AES for a given block, the
state of A, i, j, n, C, P, LSB, MSB operands.

- -- 
Med vänlig hälsning, Yours

Joachim Strömbergson - Alltid i harmonisk svängning.
========================================================================
 Joachim Strömbergson          Secworks AB          joachim at secworks.se
========================================================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJVR2RIAAoJEF3cfFQkIuyNntYP/2GTk3GK2KpQtohY0yoFXFaQ
NYzCP6SMVvBpcWYzK6YgyKpKCOboxkJJ8yCp7PZhgsCES4qIuetzojiOv6Z0QNo7
tZdh3kZ8xawc1KLhzPZiMzdk+0RZS3sd+ROHlq6GMPNmw6f4Is3MKJATTjPebAdI
XDO8qm96mAzqR5zikzs1o8Znp8Nb40vOw5Fz5QxeCx4toHQ1gaGFWPwb7TnmfH2Y
Uc9r3C0PdPtJse4BQcuTezsuVMMGGVAxp3yiC5CoVzKsGNqrMXy0ZmNuJvTQI3Pl
qbIPBhisBTK/hvcknkrIZn50D97gq37i2cXKJu+6Eugej7WUjs1B/CYQDeTgwZka
zwLMZdBggMjZtBgXeJQGB867HAjj/T4o96Jzh32NpheVE1XGN45IVBeelZ4lZxka
ylVBXfnyaE6xjJ1THSilOOiNq4V8BxG7UTN40ap4W+k91rKjbLn92I27G89LbAfc
m+z7zAIpGhww719jOMT5rtqa3qnVpvgS30Q9tW6MMp5derzIAdGmf6r5IDQUpOeV
KtmgM/Ezfnkyr0VPFiFEZlh7vjb0Mesm+vOXHyDWhIFPp5g4eMNPeuDtu7hle9ds
55CtDHVNuplFryXWPWC8h7UbULkMDM5zJ+RAI0phCFoqBcWHk2V+dubfuHHCDtDr
YhRbAso04yCNR9o33CrC
=NrDo
-----END PGP SIGNATURE-----