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#SECTION00040000000000000000
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
