Skip to content
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

Closed
ekr opened this issue Dec 6, 2020 · 3 comments
Closed

Encryption limits are too long for SN encryption #167

ekr opened this issue Dec 6, 2020 · 3 comments

Comments

@ekr
Copy link
Collaborator

ekr commented Dec 6, 2020

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

@martinthomson
Copy link
Contributor

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 q^2/2^128 then, which is 2^-32 for DTLS after all record numbers are used. Even QUIC avoids hitting 0.5 on that basis, though I'll concede that it comes closer than might be ideal, but that's a lot of packets to cross-match.

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 q^2/2^(k + n) formula as a result, which would even less of a worry.

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.

@ekr
Copy link
Collaborator Author

ekr commented Dec 7, 2020

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

@ekr ekr closed this as completed Dec 10, 2020
@kaduk
Copy link
Contributor

kaduk commented Dec 10, 2020

I'd support adding a note saying that we don't know the confidentiality bounds are for multiple applications of RNE.

Did that happen/do we expect it to happen?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants