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 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 ?