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

[Rob Austein]

At Fri, 08 May 2015 09:24:27 +0200, Joachim Strömbergson wrote:
> 
> Yes, I think it is hard to avoid the looping there. The
> rotation/movement of words in R should be possible to replace by simple
> index increment. But I don't see a way to avoid receiving the complete P
> before processing. This means that we need to define a max size of P in
> number of 64-bit words.
> 
> What would be the proper size? 4096 kbits, 8192, 16384?

Someone needs to do a bit of arithmetic to figure that one out.  It
needs to be big enough to hold the largest private key we want to be
able to handle, which presumably means RSA as EC keys are smaller.
But it's the private key, so it's a bunch of components in some
representation or another, basically a sequence of unsigned bignums.

Exactly which bignums you need depends on how you implement RSA, and
how long they are is (obviously) related to the key size but it may
take a few minutes thought to figure out the exact relationship.
The list of potentially interesting components is in the PKCS #11
spec, among other places, but you can also just look at Cryptlib's
CRYPT_PKCSINFO_RSA typedef or the output of

$ openssl genpkey -algorithm rsa -text

One can do the basic operations with just the modulus and the public
and private exponents, the rest are for optimizations and may or may
not be relevant given how our Verilog code works -- or may become
useful later if and when we change the Verilog code, etc.

So I'm pretty sure we can compute a numerical answer to your question,
but I can't do it on the back of this envelope. :)

> The same memory would then be used as output buffer.

Right.  I'd be fine with requiring that the calling code know to
offset one block when reading and writing the plaintext, if that makes
things any easier for you.

> The interface would then look something like:
> 
> (1) Write n number of words to the keywrap buffer memory.
> (2) Write n to the MESSAGE_SIZE register.
> (3) Write 0x01 to the control register
> (4) Wait for ready bit in status reg to be set.
> (5) Read out the result from the buffer memory.
> 
> Looks ok?

Yep.

Need to figure out who does the error checks on decrypt, I would
assume software but you tell me.