Re: [Cfrg] small editorial error in and question on draft-irtf-cfrg-dragonfly-01 (was: Re: CFRG meeting at IETF 87)

[Rene Struik <[e-mail]>]

Hi Dan:

Thanks. Perhaps, it would have some merit generalizing the draft to cover the tls-pwd draft as well (include salt, but also potentially nonces).

Is there any technical benefit for "refreshing" the password-derived base point (PE element) from one password-based scheme invocation to the next? I do not see how, e.g., mixing in nonces or other public parameters would prevent offline dictionary attacks in the event that one somehow learns the ephemeral private key during a protocol run, but perhaps I am missing something or there is another benefit. Down-side is that one has to recompute those base points online, thereby potentially exposing this to side channel attacks.

Best regards, Rene

==

In TLS-pwd the base, which is a function of the salt and the password,
is fixed
throughout the lifetime of the password/parties pair. The nonces passed by
the two
parties are mixed into the "PE element" calculation so that will be
different with
each run of the protocol.

The specification of dragonfly in the draft in question is general and
is intended to also work in a peer-to-peer protocol. It is impossible to
use salt in that case. That said, I think it might be a good idea to add
a section mentioning that if you are instantiating the key exchange in a
protocol that is strictly client-server then the server can salt stored
passwords as long as there's a way in the protocol for the server to tell
the client what the salt is.



On 7/29/2013 3:23 AM, Dan Harkins wrote:
>    Hi Rene,
>
> On 7/26/13 4:05 PM, "Rene Struik" <[e-mail]> wrote:
>
>> Hi Dan:
>>
>> I just quickly revisited the "password to point" mapping for elliptic
>> curves in draft-irtf-cfrg-dragonfly-01 (Section 3.2.1) and noticed a
>> small error: the seed is recursively defined. Fortunately, this is easy
>> to fix, as follows:
>>
>> was:
>>
>> base = H(max(Alice,Bob) | min(Alice,Bob) | password | counter)
>> seed = KDF-n(seed, "Dragonfly Hunting And Pecking")
>>
>>
>> suggested change:
>>
>> base = H(max(Alice,Bob) | min(Alice,Bob) | password | counter)
>> seed = KDF-n(base, "Dragonfly Hunting And Pecking")
>    Thank you for catching that! I'll include the fix in the next
> revision of the draft.
>
>> On a more general note, with the draft rev1 version, the found point Q is
>> a function of the password itself and the presumed key sharing parties
>> Alice and Bob. In other words, the password-derived generator of the
>> curve "PE Element" is fixed throughout the
>> lifetime of the pair (password, key sharing parties). With
>> draft-harkins-tls-pwd-03, a similar procedure is proposed, but there a
>> "salt" is mixed in as well. Just curious: why the difference?
>> <http://tools.ietf.org/pdf/draft-harkins-tls-pwd-03.pdf>
>    In TLS-pwd the base, which is a function of the salt and the password,
> is fixed
> throughout the lifetime of the password/parties pair. The nonces passed by
> the two
> parties are mixed into the "PE element" calculation so that will be
> different with
> each run of the protocol.
>
>    The reason salt was added to TLS-pwd is because the TLS is a
> client-server
> protocol and there was consensus in the WG that support should be added to
> support the many deployed password databases that salt the password.
>
>    The specification of dragonfly in the draft in question is general and
> is intended to also work in a peer-to-peer protocol. It is impossible to
> use salt in that case. That said, I think it might be a good idea to add
> a section mentioning that if you are instantiating the key exchange in a
> protocol that is strictly client-server then the server can salt stored
> passwords as long as there's a way in the protocol for the server to tell
> the client what the salt is.
>
>    Thanks for your input.
>
>    regards,
>
>    Dan.
>
>> Best regards, Rene
>>
>>
>>
>> On 7/26/2013 5:50 PM, David McGrew wrote:
>>
>>
>> Hi,
>>
>> here is the agenda for our upcoming meeting; we are looking forward to
>> seeing you there.
>>
>> David and Kevin
>>
>> ---
>>
>> Crypto Forum Research Group at IETF 87
>> Monday, July 29, 2013
>> 1510-1610  Afternoon Session II
>> Room: Tiergarten 1/2
>>
>> Agenda Bashing
>>
>> Randomized Hashing (as described in NIST SP-800-106/107) - Quynh Dang
>>
>> Updates on active drafts
>>
>> - OCB Mode of Operation, draft-irtf-cfrg-ocb-03
>>
>> - Dragonfly Key Exchange, draft-irtf-cfrg-dragonfly-01
>>
>> - Hash-Based Signatures, draft-mcgrew-hash-sigs-00
>>
>> "Selection of Future Cryptographic Standards", Sheffer, Grieco, McGrew.
>> draft-mcgrew-standby-cipher-00
>>
>> Discussion on other crypto work
>>   Salsa20
>>   DTLS In Constrained Environments (DICE)
>>   CAESER
>>
>>
>> _______________________________________________
>> Cfrg mailing list
>> [e-mail]://www.irtf.org/mailman/listinfo/cfrg
>>
>>
>>
>> -- 
>> email: [e-mail] | Skype: rstruik
>> cell: [phone] | US: [phone]


-- 
email: [e-mail] | Skype: rstruik
cell: [phone] | US: [phone]