On Sat, 19 May 2018 01:38:37 -0400, Joachim Strömbergson wrote: ... > I can build a modified version of the AES core with 16 Sboxes. This > should cut those 98 seconds to 25 or so. That is fairly easy to do and I > can start doing that on Tuesday. Ok?
Sure. > One thing I haven't considered is how key expansion is done. Today the > key expansion is triggered when performing an "init" of the core. Since > the core is ECB you should only need to do "init" when you really are > changing keys in the keywrap. > > Can you check when and how often you pull "init"? When we first load the KEK, and only then. > BTW: My memory fails me, which keywrap are we using - SIV och NIST > AES-keywrao SP 800-38F (also in RFC 3394, if I'm not mistaken)? "AES Keywrap With Padding", RFC 5649. See hal_aes_keyunwrap() in git.cryptech.is/sw/libhal/aes_keywrap.c. AESKeyWrapWithPadding in git.cryptech.is/sw/libhal/unit-tests.py implements the same logic (using PyCrypto's AES implementation for the underlying AES-ECB transformation), in case that's easier to read. On Sat, 19 May 2018 02:13:05 -0400, Joachim Strömbergson wrote: > > Another thing we could consider is adding a streaming interface to > the AES core. This would allow you to push words and the core would > processing them as fast as possible as soon as there is a whole > block. We could even combine this with a FIFO. Don't think it would help all that much in this case, but feel free to read the C code yourself and tell me I'm wrong about this. > But right now I know to little about how your keywrap code use the > AES core Rob. You need to say if this would would reduce the wait > states. At the high level, everything we currently do with AES Keywrap is basically just PKCS #8. The wrapped keys used in the HSM backup and restore functions are the full PKCS #8 EncryptedPrivateKeyInfo format; the wrapped keys in the internal keystore(s) are just the wrapped PrivateKeyInfo (ie, for the internal keystore(s) we currently store just the encrypted blob which would go in the OCTET STRING of the EncryptedPrivateKeyInfo wrapper). Given a reason (like needing to record the length data) we could trivially add the outer wrapper since we already have the code, so other than wasting a few bytes on the mostly invariant header we'd never notice the difference. The rest of the HSM doesn't really give a hoot what algorithm we use here. We settled on AESKeyWrapWithPadding via the usual rough consensus process; in this case the outliers were a bit more vocal than usual, but everybody agreed to go along with it. _______________________________________________ Tech mailing list Tech@cryptech.is https://lists.cryptech.is/listinfo/tech