-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Encryption limits are too long for SN encryption #167
Comments
Not sure that I'm following. Record number encryption runs 2^48 block operations of the block cipher with an identical input (it's ECB, so it's not a nonce). We don't account for this in terms of the limits on key usage, so yes, it would benefit from some analysis. I don't think that this is a risk in that we are not using that key so much, and the sample - 128 bits - is large enough that we don't get near the birthday bound. Neither protection model uses 96-bit inputs. If we model the underlying block cipher as an ideal PRP (as the papers I've read do), then we only need to worry about collision risk, which isn't so bad. The advantage reduces to approximately With a collision, the attacker gains the ability to derive the XOR of two record sequence numbers (in QUIC, this includes a little more stuff). This likely allows the attacker to confirm what the values of both values are. It might also allow them to confirm a guess that two records sent on different paths (with different connection IDs) are for the same connection. Multi-user analysis could be interesting here to, but I think that it turns into a This is pretty rough, but I don't think that it's particularly exciting. I'd support adding a note saying that we don't know the confidentiality bounds are for multiple applications of RNE. |
You're right. I thought we were using the low 32 as a counter. So it is a 128-bit sample. Would like to hear from @prosecco |
Did that happen/do we expect it to happen? |
The RNE nonce is effectively 96 bit and for ChaCha20 we allow up to the sequence number which is 48 bits, so very close to the birthday limit for the record number. Also a potential issue for QUIC @martinthomson
The text was updated successfully, but these errors were encountered: