Re: [Cfrg] Key-Derivation Scheme

[Paul Lambert <[e-mail]>]

The following is a quote from section 1 of the J-PAKE draft (http://tools.ietf.org/html/draft-hao-jpake-01):


   There are a few factors that may be considered in favor of J-PAKE
   over others.  First, J-PAKE has security proofs, while equivalent
   proofs are lacking in EKE, SPEKE and SRP-6.  Second, J-PAKE is not

   patented.  It follows a completely different design approach from all
   other PAKE protocols, and is built upon a well-established Zero
   Knowledge Proof (ZKP) primitive: Schnorr NIZK proof [I-D-Schnorr<http://tools.ietf.org/html/draft-hao-jpake-01#ref-I-D-Schnorr>].

If this is indeed the case, then we do have a PAKE with a proof and no patents.

Would be very nice if true, while not patented some investigation by interested parties would be useful.
Also … quick skim of the references it looks like there is some possible clean-up work depending on goals:
 - better clarification of operation (e.g. Use and necessity of  “UserId”)
 - clarification of protocol formats associated with algorithm
 - translation to ECC and clear identification of default curves
 - … Etc



Paul



Regards,
 Rifaat



On Mon, Jun 9, 2014 at 11:57 AM, Paul Lambert <[e-mail]<mailto:[e-mail]>> wrote:


On 6/9/14, 5:00 AM, "Watson Ladd" <[e-mail]<mailto:[e-mail]>> wrote:

>On Mon, Jun 9, 2014 at 4:35 AM, Simon Josefsson <[e-mail]<mailto:[e-mail]>>
>wrote:
>> "Dan Harkins" <[e-mail]<mailto:[e-mail]>> writes:
>>
>>>   A much better solution to your problem is to use a
>>>password-authenticated
>>> key exchange based on a zero knowledge proof. That way, not only does
>>> the password not cross the wire/ether, neither does password-derived
>>> data.
>>
>> I think most people agree would agree with that -- but as far as I know
>> existing zero-knowledge authentication password mechanisms have other
>> serious problem (e.g., servers knowing password, lack of security proof,
>> or patent issues).  Given that, I think it is wortwhile to improve the
>> practical but theoretically less optimal solutions.
>
>Socialist Millionaires Protocol was published in 1996. Any patents
>expire in 2016 if any were filed for: a quick search finds none.
>It can be made to work over any group.
>
>PAKE (the original) has a patent expiring in 2016. It has optimal
>security with a proof done in 2001.

The Dragonfly key exchange was adopted by IEEE 802.11s in 2009. This
key exchange has no identified patent issues.  The protocol
(called SAE in the IEEE) will be adopted for other wireless applications
and will be deployed in a large number of consumer
devices in the future (IMO).

The key exchange has been documented for use in applications that include:
IEEE 802.11, IEEE 802.15.9, IPsec and TLS.

The protocol has no identified security issues, but it¹s
structure is less amenable to the development of a security proof.
No formal proof has been developed at this time.

So the options are:
 1 - pake      proof         patents (until after at least 2016)
 2 - pake      no-proof      no-patents (now)
 3 - no-pake   same-old less optimal solutions  no-patents (now)

I¹d rather have a pake now with no proof than continue the same-old
suboptimal solutions.

Paul




>
>SIncerely,
>Watson Ladd
>>
>
>
>--
>"Those who would give up Essential Liberty to purchase a little
>Temporary Safety deserve neither  Liberty nor Safety."
>-- Benjamin Franklin
>
>_______________________________________________
>Cfrg mailing list
>[e-mail]<mailto:[e-mail]>
>http://www.irtf.org/mailman/listinfo/cfrg

_______________________________________________
Cfrg mailing list
[e-mail]<mailto:[e-mail]>
http://www.irtf.org/mailman/listinfo/cfrg