Aloha! I’ve spent a couple of hours reading RFC 3394 specifying AES Key Wrap, and RFC 5649 specifying a version of RFC 3394 with padding to handle data/plaintext that is not a multiple of 64 bits.
The core of the Key Wrap algorithm as described in RFC 3394, section 2.2.1 on
page 5 is this:
For j = 0 to 5
For i=1 to n
B = AES(K, A | R[i])
A = MSB(64, B) ^ t where t = (n*j)+i
R[i] = LSB(64, B)
Where R[i] contains the plaintext divided into 64-bit blocks and A is a 64-bit
authenticator state register. Basically we loop over all blocks six times,
updating the blocks as well as the authenticator state each time.
Building this in HW is not hard. What it would require is a data buffer able to
handle the size of the plaintext, info about the size of the plaintext and the
wrapping key. The resulting wrapped text (the ciphertext) will be available in
the buffer after processing.
For larger plaintext - a 4096 bit RSA key for example. Having the wrapping
functionality in HW instead of in SW should cut down the number of times a
given 64 bit data block would be sent over the FMC bus to and from the AES core
quite a lot. And the HW would be able to use the AES core much faster than the
SW waiting for the AES core signalling it being ready via the FMC. So, I think
there is a good opportunity to speed key wrap/unwrap.
The key issue I see is how key wrapping is used in the Alpha. Are we
wrapping/unwrapping single keys? Or are wrapping/unwrapping performed on a
bunch of keys as they belong to the same plaintext? If we do wrap/unwrap on
per-key basis the size of the processing buffer will not be that big, and we
can implement this with the block memories in the FPGA without any problems.
8192 bits for example should be no problem.
Rob, what are your thoughts?
—
Med vänlig hälsning, Regards,
Joachim Strömbergson - Assured AB
=================================
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Tech mailing list [email protected] https://lists.cryptech.is/listinfo/tech
