You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Intel folks noticed that in order to encrypt/decrypt a new message, a new symmetric state had to be created.
However, with AES-GCM, setting up a new key is slow, because it requires doing some precomputations.
If the same key is used multiple times, we could reuse these precomputations for a slight speedup.
One way to address this would be to introduce a symmetric_state_reset(<state handle>, <key handle>) hostcall.
If the key handle is the same as the previous one, it doesn't do anything except clear the nonce (or create a new one if it can be randomized).
If the key is different, it's equivalent to creating a new state, but without creating a new handle.
If the key doesn't change, this allows implementations to reuse the precomputations. This is optional (just a performance enhancement) and only for AES-GCM, or possibly future ciphers that have a slow key setup.
When encrypting/decrypting multiple messages with the same key, using AES-GCM for example, the nonce needs to be updated for each message. Today the nonce is passed as part of the options parameter when opening the state. With the symmetric_state_reset() proposal, how does the nonce (or options in general) get updated on the 'reset' state? Should it be: symmetric_state_reset(<state handle>, <key handle>, <options_handle>)?
symmetric_state_reset() has another advantage: we can check that the previous nonce was not reused (at least when it matters; for AES-GCM-SIV, that would be fine).
The Intel folks noticed that in order to encrypt/decrypt a new message, a new symmetric state had to be created.
However, with AES-GCM, setting up a new key is slow, because it requires doing some precomputations.
If the same key is used multiple times, we could reuse these precomputations for a slight speedup.
One way to address this would be to introduce a
symmetric_state_reset(<state handle>, <key handle>)
hostcall.If the key handle is the same as the previous one, it doesn't do anything except clear the nonce (or create a new one if it can be randomized).
If the key is different, it's equivalent to creating a new state, but without creating a new handle.
If the key doesn't change, this allows implementations to reuse the precomputations. This is optional (just a performance enhancement) and only for AES-GCM, or possibly future ciphers that have a slow key setup.
What do you think @sonder-joker ?
The text was updated successfully, but these errors were encountered: