-
Notifications
You must be signed in to change notification settings - Fork 159
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
HKDF label budget in 7.1 is off by 9 #1365
Comments
Actually, we can fix this in 8446-bis. @ilaril can you double check this before we change it? |
The budget calculation in #964 forgot to account overheads from SHA-256 itself, and is thus off by 9 bytes. The issue mentions ML discussion and there is corrected calculation in ML messages. The maximum Label (i.e., not including the "tls13 " prefix) length that avoids extra block in Derive-Secret is indeed 12 bytes. In this case, the layout of the inner HMAC input is:
This fills 2 SHA-256 blocks (128 bytes), which is the minimum possible for HKDF-SHA256-Expand. The note is somewhat confusing tho:
Checking other hash functions used by various cipher suites (SHA-384, SHA-512, GOST R 34.11-2012, and SM3) all seem to be able to accommodate 12 byte Label without extra block. |
Agreed, I neglected the SHA-256 pad and length trailer when checking the original budget calc in #964, and was thrown by the coincidental arithmetic in "TLS1.3, " (9) + "tls ..." (18) -> "tls13 " (6) + published limit (12). |
This is editorial, and the doc is somewhere between done and published, but it's haunting my notes...
In 7.1, "any label longer than 12 characters" should be "any label longer than 21 characters".
This off-by-nine appears to be due to something getting lost in the wash during #964 between @ilaril's budget calculation, @ekr's post of the new set of "tls13 ..." labels, and subsequent removal of "tls13 " from those label names to replace the "TLS1.3, " in HkdfLabel.
The text was updated successfully, but these errors were encountered: