Re: [CFRG] Questions regarding draft-irtf-cfrg-spake2-15.txt

[Watson Ladd <[e-mail]>]

This weekend I will upload a revised version that clarifies the usage
of the KDF and addresses RFC 2104.

On Fri, Dec 18, 2020 at 3:42 AM Лилия Ахметзянова <[e-mail]> wrote:
>
> Hello Watson!
>
> Thank you for your clarifications! I have no additional questions, just a minor comment regarding key schedule and ciphersuites: it would be great if the arguments you mentioned were added in Security Considerations.
>
> Best wishes,
> Liliya
>
> вс, 6 дек. 2020 г. в 23:08, Watson Ladd <[e-mail]>:
>>
>> On Sun, Dec 6, 2020 at 11:44 AM Лилия Ахметзянова <[e-mail]> wrote:
>> >
>> > Hello CRFG, Watson and Benjamin,
>> >
>> > Recently, I’ve interested in the draft https://tools.ietf.org/html/draft-irtf-cfrg-spake2-15.  I have come up with several thoughts and comments (hope I'm not late).
>> >
>> > Considerations on key schedule:
>> > In section 4 the following key schedule is defined:
>> >
>> > Both parties use TT to derive shared symmetric secrets Ke and Ka as Ke || Ka = Hash(TT), with |Ke| = |Ka|.
>> >
>> > A and B compute them as KcA || KcB = KDF(nil, Ka, "ConfirmationKeys" || AAD)
>> >
>> >
>> > 1. If one chooses a ciphersuite, e.g., with P-256 and SHA-512 to produce keys Ke and Ka of length 256 bits, then the SHA-512 function seems to be used here as a PRG function. However, as far as I know, it is not the standard properties of the hash functions. It seems better to directly use the extract and expand concept to produce Ke, KcA, KcB. Could you explain, what caused the keys to be produced in such a way?
>>
>> In most applications where the scheme is used the higher level
>> protocol will derive keys and hash the transcript itself. Hashing the
>> transcript and key works fine and I don't think there were any
>> questions about not using HMAC during RGLC or the reviews as part of
>> the PAKE selection process.
>>
>> >
>> > 2. The keys KcA, KcB can be used as a key input for HMAC(SHA-256). If HKDF(SHA-256) was used for producing these keys, then |KcA| = |KcB| = 128 bits. However, RFC 2104 points out the following recommendation: In any case the minimal recommended length for K is L bytes (as the hash output length).  Does using these ciphersuites contradict the document RFC 2104?
>>
>> The text of RFC 2104: " The key for HMAC can be of any length (keys
>> longer than B bytes are first hashed using H).  However, less than L
>> bytes is strongly discouraged as it would decrease the security
>> strength of the function." But we don't need the mac to be 256 bits
>> long. 128 would be fine in that case.
>>
>> >
>> > Considerations on Key confirmation
>> > For key confirmation the following procedure is used:  F = MAC(KcA, TT). Here tag is computed for data TT that contains the D-H key K. This may complicate the implementation of the protocol since many secure API does not allow to use “naked” keys in such a way. Is adding the K value crucial for the security here?
>>
>> No, but it's easier to have one transcript versus 2.
>>
>> >
>> > And a few editorial comments:
>> > 1. The words that one needs to check points for belonging to a group are specified in Security Consideration. It seems important to indicate these checks directly when describing the protocol.
>> > 2. Page 3, in the sentence "Common choices for H are SHA256 or SHA512 [RFC6234]", H should be replaced with Hash.
>> > 3. During the document. the following KDF interface is used:
>> >             KDF (salt, IKM, info)
>> > -- It seems better to swap salt and IKM, because now it looks a little unnatural.
>> > -- It seems better to write the length L as the fourth parameter everywhere (since it was introduced in the introduction)
>>
>> Thanks for your comment. This seems like the sort of minor
>> nonsubstantive fix I can apply easily, and is something I noticed when
>> coding the test vector generation.
>>
>> >
>> >
>> > Best wishes,
>> > Liliya Akhmetzyanova
>>
>>
>>
>>
>> --
>> Astra mortemque praestare gradatim



-- 
Astra mortemque praestare gradatim