Subject: Re: [Cfrg] Future applications of PAKEs

From: Станислав Смышляев <[email-masked]>
Date: Sun, 31 Jul 2016 20:55:41 +0300

An adversary just makes a ECDHE exchange with Alice and then gets a key-related information (during key confirmation or encryption process if he knows plaintext), which is the function of PW, one-time shared key and KDF salt. The only value which he does not know is PW - and the adversary now has a criterion to bruteforce it (passively).

От: Станислав Смышляев

Отправлено: воскресенье, 31 июля 2016 г., 20:52

Кому: StJohns, Michael; Watson Ladd

Копия: Robert Moskowitz; [email-masked]; Schmidt, Jörn-Marc; Alexey Melnikov; Paterson, Kenny; Mike Hamburg; 辛星漢; Stephen Farrell

Тема: Re: [Cfrg] Future applications of PAKEs

An adversary just makes a ECDHE exchange with Alice and then gets any key-related information, which is the function of PW, one-time shared key and KDF salt. The only value which he does not know os PW - and the adversary now has a criterion to bruteforce it (passively).

От: StJohns, Michael

Отправлено: воскресенье, 31 июля 2016 г., 20:48

Кому: Watson Ladd

Копия: Robert Moskowitz; Станислав Смышляев; [email-masked]; Schmidt, Jörn-Marc; Alexey Melnikov; Paterson, Kenny; Mike Hamburg; 辛星漢; Stephen Farrell

Тема: Re: [Cfrg] Future applications of PAKEs

Go for it.  I'm actually curious what you mean by not secure and what you mean by break.

On Sunday, July 31, 2016, Watson Ladd <[email-masked]> wrote:

On Sun, Jul 31, 2016 at 10:19 AM, StJohns, Michael

<[email-masked]> wrote:

> I've been finding the following construct useful and secure:

> 1) use ecdhe to derive a one-time shared secret

> 2) prepend your password to the shared secret

> 3) use that concatenated value as the master key for your KDF function.

> The derived keys will only match if both sides input the exact same password

> value gang you the authentication piece.

This is not secure. I leave it as an exercise to the reader to break.

> Mike

> On Friday, July 29, 2016, Robert Moskowitz <[email-masked]> wrote:

>> I have an IoT vendor that has an ECDH KE embedded in their protocol.  They

>> have asked me to enhance this with a password.  Actually I have TWO such

>> vendors (different industries so no conflict of interest).  I cannot provide

>> details of what they do beyond there is an ECDH KE.

>> So I need to turn their ECDH KE into a PAKE.

>> I recognize that this is not directly an IETF problem, but if I point to

>> an IETF protocol, they will be more willing to adopt change.

>> Choices, choices...

>> I would like to have a draft that provides the differences between the

>> various proposed PAKEs.

>> On 07/24/2016 08:24 AM, Станислав Смышляев wrote:

>> Good afternoon, dear colleagues!

>> We've had a very fruitful discussion with Watson Ladd and have both

>> understood that to continue a productive work on PAKEs in CFRG (not only on

>> SESPAKE and SPAKE2 drafts) it will be better if all of us now decide which

>> PAKEs applications to consider as primary ones for IETF.

>> The concrete questions that depend on this decision are more specific than

>> the ones considered in the requirements draft (which is quite ready to be

>> followed now)‎ - they are about how the defined protocols are to be

>> integrated. For instance, if we need a PAKE to be ready for integration in

>> some IoT initialization protocol (as we discussed with Hannes Tschofenig) or

>> to be used separately for specific needs as securing channel between a key

>> container and a CSP (as it is used in my company), we have to define a wise

>> key confirmation part and surroundings (like the way of obtaining Q_PW in

>> SESPAKE draft or the final key K' in Watson's SPAKE2 draft). Otherwise, if

>> we primarily think about TLS or IKE, for example, we don't need to define

>> anything except the core key exchange mechanism now - and leave all other

>> important questions like the countermeasures against online password

>> guessing until the future work on a corresponding TLS(/IKE/SSH/etc)-related

>> draft.

>> Kindest regards,

>> Stanislav Smyshlyaev

>> _______________________________________________

>> Cfrg mailing list

>> [email-masked]

>> https://www.irtf.org/mailman/listinfo/cfrg

--

"Man is born free, but everywhere he is in chains".

--Rousseau.