Open jedisct1 opened 1 year ago
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>)
?
Oh, right, we definitely need <options_handle>
here.
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).
Good idea.
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 ?