A naive question: is HKDF implemented placing secret in the "salt" argument, and label in the "key" argument, as NIST 800-56B says? Or putting label into "salt" and secret into "key"?
Regards, Uri Sent from my iPhone > On Mar 31, 2019, at 09:46, Ilari Liusvaara <[email protected]> wrote: > >> On Sun, Mar 31, 2019 at 08:38:47PM +0800, M K Saravanan wrote: >> Hi, >> >> https://tools.ietf.org/html/rfc8446 >> ============ >> 7.1. Key Schedule >> >> The key derivation process makes use of the HKDF-Extract and >> HKDF-Expand functions as defined for HKDF [RFC5869], as well as the >> functions defined below: >> >> HKDF-Expand-Label(Secret, Label, Context, Length) = >> HKDF-Expand(Secret, HkdfLabel, Length) >> >> Where HkdfLabel is specified as: >> >> struct { >> uint16 length = Length; >> opaque label<7..255> = "tls13 " + Label; >> opaque context<0..255> = Context; >> } HkdfLabel; >> ============ >> >> In this struct, what is the value of label<0..6>? > > The syntax "opaque label<7..255>" means that label is octet string of > at least 7 and at most 255 octets, and that its length is encoded using > 1 octet. The string "tls13 " is 6 octets long, so that impiles that > Label is at least 1 octet and at most 249 octets long. > > So for example if Label is "s hs traffic", then the label (including > the length field) is: > > \x12 "tls13 s hs traffic" > > The \x12 is the octet with value 18 (which happens to be ASCII DC2) > because the remainder is 18 octets. > > And as another example if Label is "c e traffic", then the label > (again including length field is: > > \x11 "tls13 c e traffic" > > The \x11 is the octet with value 17 (which happens to be ASCII DC1) > because the remainder is 17 octets. > > > In the first case, if the ciphersuite has SHA-256 hash, then the > whole HkdfLabel looks like the following (in hex): > > 00 20 #32 octets of output (2 octets) > 12 #18 octets label length (1 octet) > "tls13 s hs traffic" #The actual label (18 octets) > 20 #32 octet transcript input (1 octet). > hash(client_hello+server_hello) #Transcript (32 octets). > > In total, this is 54 bytes (64 bytes after adding HKDF and SHA-256 > internal overhead). There is only one output block, and the input > fits into one block so evaluating the HKDF-Expand takes 4 SHA-256 > block operations. > > > The one ciphersuite using SHA-384 would instead give (in hex): > > 00 30 #48 octets of output (2 octets) > 12 #18 octets label length (1 octet) > "tls13 s hs traffic" #The actual label (18 octets) > 30 #48 octet transcript input (1 octet). > hash(client_hello+server_hello) #Transcript (48 octets). > > In total, 70 bytes. Again, only one output block and only one input > block, so evaluation takes 4 SHA-384 block operations. > > > > -Ilari > > _______________________________________________ > TLS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tls
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
