[quicwg/base-drafts] Encrypting Retry token (#3274)

[Martin Thomson <[e-mail]>]

In Singapore, we reached an impasse regarding the use of encryption on Retry.

>From that discussion, there were two outcomes considered:

* "encrypt" using a fixed key and nonce and don't encrypt the token; put the original destination connection ID in the AAD along with the entire packet

* encrypt the token using the fixed key and a nonce that takes the first 8 bytes of the original destination connection ID; the AAD only includes the connection IDs and version

The first can be reduced to running GHASH with a fixed XOR on the final tag if you really want to save effort.  I've implemented and measured that.

The second can be implemented naively, just by building a new AES key for every record.  That's not terribly slow at 2.8x slower.  With some nasty tricks, I was able to get the AES version under 1.7x slower.  Given the relative cost of these functions, I think that this is an acceptable cost.

There's no guarantee that this is correct - I haven't even checked that these programs produce the right output, but the count of operations is approximately right, so I'm posting this issue.  My code can be found at [martinthomson/quic-retry-tag](https://github.com/martinthomson/quic-retry-tag/blob/master/bench.c) in case reproduction or validation thrills you.

Here's the output of a sample run on my old machine with about 1Mb of Retry packets fed through the different implementations, which takes about 32 seconds to complete:

```
Measuring best of 1000 iterations
ghash:          22450242
aes_gcm_slow:   60070152
aes_gcm_fast:   35240211
```

Now, obviously this is a microbenchmark.  The rest of the cost will be elsewhere, but I tried to isolate the variable.  Hopefully this helps the decision-making process.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3274