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
Currently when verifying the ghash mac tag for decryption, it is necessary for both parties to commit to their tag before opening it.
This is necessary because in decryption the server provides the correct tag and a rushing adversary who knows the server tag and the other party's tag share would be able to adjust his tag share to trick the other party into accepting his share as being correct. The downside of this is that we have a full roundtrip overhead for every TLS record. So for example when there is 1MiB (2^20 B) of traffic and having a TLS record size of 16 KiB (2^14 B), this would be 2^6=64 extra roundtrips.
A possible solution for this would be to send the MAC decommitments in a batch at the end of a TLS session, which would effectively mean to delay tag verification to the end of the TLS session. Currently the extra roundtrips we incur from the verification right away for every record are not too bad, because we only notarize fractions of a MiB, but since this effect scales with traffic size it could be a worthwhile enhancement at some point.
The text was updated successfully, but these errors were encountered:
Currently when verifying the ghash mac tag for decryption, it is necessary for both parties to commit to their tag before opening it.
This is necessary because in decryption the server provides the correct tag and a rushing adversary who knows the server tag and the other party's tag share would be able to adjust his tag share to trick the other party into accepting his share as being correct. The downside of this is that we have a full roundtrip overhead for every TLS record. So for example when there is 1MiB (2^20 B) of traffic and having a TLS record size of 16 KiB (2^14 B), this would be 2^6=64 extra roundtrips.
A possible solution for this would be to send the MAC decommitments in a batch at the end of a TLS session, which would effectively mean to delay tag verification to the end of the TLS session. Currently the extra roundtrips we incur from the verification right away for every record are not too bad, because we only notarize fractions of a MiB, but since this effect scales with traffic size it could be a worthwhile enhancement at some point.
The text was updated successfully, but these errors were encountered: