Re: J-PAKE (was Re: Usage of FreeBL and FreeBL/mpi through JavaScript in Firefox 4 Sync)
Jean-Marc Desperrier wrote: The reference I gave before shows that there is now a widely accepted opinion that SRP does not infringe on patent more than J-PAKE (even if there was indeed that doubt a few years ago). A patent that covers SRP might be found, but it does not appear today to be more likely than it is for J-PAKE. It is hard for most of the people on the mailing list to participate in a meaningful discussion of patents for a variety of reasons, so I'm just going to focus on the technical reasons for implementing J-PAKE instead of SRP. Balanced vs augmented does not matter for Sync's usage because the user is at both end points. If you don't need augmented security, J-PAKE makes more sense. Actually, what I wrote above isn't correct. A balanced scheme is actually better for Sync because we are asking the user to read a code from the screen of device 1 and type it into device 2. Both devices need the same psssword/PIN. I'm now reading here http://www.mail-archive.com/cryptogra...@metzdowd.com/msg09739.html that J-PAKE is *proven* to be no weaker than the algorithms it relies on. I am very interested in hearing what people think about the validity of the proofs in the J-PAKE paper and whether any security considerations have been overlooked. FWIW, I am pretty sure that we will be having a discussion about SRP and other solutions to the problems that SRP solves when we do planning for post-FF4 releases. Implementing J-PAKE now for this one Sync use case doesn't mean that we will prefer J-PAKE for solving those other problems, and it doesn't mean that we've decided to avoid implementing SRP. Cheers, Brian -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: J-PAKE (was Re: Usage of FreeBL and FreeBL/mpi through JavaScript in Firefox 4 Sync)
Brian Smith wrote: A balanced scheme is actually better for Sync because we are asking the user to read a code from the screen of device 1 and type it into device 2. Both devices need the same psssword/PIN. The augmented scheme of SRP can be degraded to a balanced scheme if you need. It's trivial to regenerate the verifier from the password when needed, instead of just getting it out of the storage. I am very interested in hearing what people think about the validity of the proofs in the J-PAKE paper and whether any security considerations have been overlooked. IMO the trouble with J-PAKE is that it's probably an order of magnitude or more less used than SRP. It means less eyes on it to see the defaults, and that in princip is a problem. I've found the initial proof of security for SRP : http://srp.stanford.edu/ndss.html#SECTION0004 That's the v3 version of 1997. While the proofs have not been repudiated, some minor problems have been found and the v6 version has been issued to solve them as described here : http://srp.stanford.edu/srp6.ps FWIW, I am pretty sure that we will be having a discussion about SRP and other solutions to the problems that SRP solves when we do planning for post-FF4 releases. Implementing J-PAKE now for this one Sync use case doesn't mean that we will prefer J-PAKE for solving those other problems, and it doesn't mean that we've decided to avoid implementing SRP. I think it would be dead-code to have an implementation for both. By versionning the protocol, you can go with J-PAKE now, and use only SRP later. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: J-PAKE (was Re: Usage of FreeBL and FreeBL/mpi through JavaScript in Firefox 4 Sync)
Brian Smith wrote: Jean-Marc Desperrier wrote: Why are you choosing J-PAKE instead of SRP ? The J-PAKE authors claim they developed J-PAKE to avoid patents that cover other algorithms, and they claim they won't patent it. I don't know if either claim is true or not. The reference I gave before shows that there is now a widely accepted opinion that SRP does not infringe on patent more than J-PAKE (even if there was indeed that doubt a few years ago). A patent that covers SRP might be found, but it does not appear today to be more likely than it is for J-PAKE. [...] Balanced vs augmented does not matter for Sync's usage because the user is at both end points. The end-user is establishing a secure channel from one of his/her devices to another one of his/her devices that are in the same location. Also, there is a new PIN (password) for every transaction. See https://wiki.mozilla.org/Services/Sync/SyncKey/J-PAKE If you don't need augmented security, J-PAKE makes more sense. I'm now reading here http://www.mail-archive.com/cryptogra...@metzdowd.com/msg09739.html that J-PAKE is *proven* to be no weaker than the algorithms it relies on. I don't know have exact references but I doubt that version 6 of SRP doesn't have an equivalent security proof, given the number of standards that rely on it. Wikipedia says even if one or two of the cryptographic primitives it uses are attacked, it is still secure but doesn't give a direct link that shows that (they are reference to it resisting to collision attacks on SHA1). Given the number of protocols that include SRP (SSL/TLS, EAP, SAML), given that there's already a proposed patch for NSS (bug 405155, bug 356855), a proposed patch for openssl ( http://rt.openssl.org/Ticket/Display.html?id=1794user=guestpass=guest ), I still think SRP is the better choice since the effort to implement it would be much more widely useful than with J-PAKE. On the long term, I wouldn't be surprised if at some point you'll add another scenario where augmented security would be useful, and you will in all likehood stay the only users of J-PAKE, I believe SRP will certainly end up being included, and it will be a little stupid to have 2 functionally equivalent algorithms. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
J-PAKE (was Re: Usage of FreeBL and FreeBL/mpi through JavaScript in Firefox 4 Sync)
Jean-Marc Desperrier wrote: Why are you choosing J-PAKE instead of SRP ? The J-PAKE authors claim they developed J-PAKE to avoid patents that cover other algorithms, and they claim they won't patent it. I don't know if either claim is true or not. http://rdist.root.org/2010/09/08/clench-is-inferior-to-tlssrp/#comment-5993 JPAKE and SPEKE are balanced schemes and thus have the same problem as Clench. However, SRP does not. SRP is an augmented scheme Balanced vs augmented does not matter for Sync's usage because the user is at both end points. The end-user is establishing a secure channel from one of his/her devices to another one of his/her devices that are in the same location. Also, there is a new PIN (password) for every transaction. See https://wiki.mozilla.org/Services/Sync/SyncKey/J-PAKE Cheers, Brian -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
