[Cryptech Tech] Happier RSA timing numbers

[Rob Austein]

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.