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

[Лилия Ахметзянова <[e-mail]>]

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
>