Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Re: J-PAKE (was Re: Usage of FreeBL and FreeBL/mpi through JavaScript in Firefox 4 Sync)

99 views
Skip to first unread message

Brian Smith

unread,
Oct 25, 2010, 2:02:23 AM10/25/10
to mozilla's crypto code discussion list
"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/crypto...@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

Brian Smith

unread,
Oct 27, 2010, 1:08:56 PM10/27/10
to mozilla's crypto code discussion list
"Jean-Marc Desperrier" wrote:

> 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.

If there is a flaw or some problem with J-PAKE, then Sync would have to
use something else such as SRP. But, switching now would likely result in
a delay--perhaps a very long one--that would be very painful. So, I think
arguments against J-PAKE or for a different scheme have to be very
compelling in order to affect change.

> > 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.

Yes, this is something that lots of people are concerned about. On one
hand, the paper has proofs. On the other hand, it looks like the paper
hasn't been reviewed very thoroughly in the cryptography community
and also nobody else is using J-PAKE. That is one reason I am trying to
explain what we are doing with J-PAKE; I am hoping to get more attention
on J-PAKE itself so that problems we overlooked during the J-PAKE review
may be found by others.

> > 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.

I think we cannot say that unless/until we decide to implement SRP. And,
AFAICT, decisions about SRP should wait until after FF4.0 ships unless
there's some reason we can't use J-PAKE. But, if there is some problem
with J-PAKE then suddenly SRP would become very interesting.

Cheers,
Brian

Jean-Marc Desperrier

unread,
Feb 28, 2011, 11:20:39 AM2/28/11
to mozilla-dev...@lists.mozilla.org
For context, from a message I wrote in last October :
> 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=1794&user=guest&pass=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.

So the end result : I see that J-PAKE code got included inside NSS
https://bugzilla.mozilla.org/show_bug.cgi?id=609076 with a layer to
access it from js (bug 601645). This was not announced here, and even if
it looked like Sync Would keep J-PAKE, I did not imagine it would be
included as a new mechanism in NSS, I thought it would stay inside an
external layer.

I really, really regret I gave up on that dead-end discussion about
J-PAKE and did not follow what happened exactly after that.
It would have been just functionally equivalent for Sync to use SRP
instead of J-PAKE in Sync, but so much more useful for everyone else,
especially for all those who would love to be able to use SRP with TLS.

Robert Relyea

unread,
Feb 28, 2011, 6:50:15 PM2/28/11
to mozilla's crypto code discussion list, Jean-Marc Desperrier
On 02/28/2011 08:20 AM, Jean-Marc Desperrier wrote:
> For context, from a message I wrote in last October :
>> 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=1794&user=guest&pass=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.
>
> So the end result : I see that J-PAKE code got included inside NSS
> https://bugzilla.mozilla.org/show_bug.cgi?id=609076 with a layer to
> access it from js (bug 601645). This was not announced here, and even
> if it looked like Sync Would keep J-PAKE, I did not imagine it would
> be included as a new mechanism in NSS, I thought it would stay inside
> an external layer.
It's a crypto authentication mechanism. It involves keys. I needs to be
in NSS if we are to support it at all. (which is why it's there;).

bob

Jean-Marc Desperrier

unread,
Mar 1, 2011, 11:39:54 AM3/1/11
to mozilla-dev...@lists.mozilla.org
Robert Relyea wrote:
>> > So the end result : I see that J-PAKE code got included inside NSS
>> > https://bugzilla.mozilla.org/show_bug.cgi?id=609076 with a layer to
>> > access it from js (bug 601645). This was not announced here, and even
>> > if it looked like Sync Would keep J-PAKE, I did not imagine it would
>> > be included as a new mechanism in NSS, I thought it would stay inside
>> > an external layer.
> It's a crypto authentication mechanism. It involves keys. I needs to be
> in NSS if we are to support it at all. (which is why it's there;).

It involves no key, in the usual meaning of a secret permanent key,
which makes it *possible* to implement it externally.
I notice the committed code extracts the generated shared symmetric key
up to the javascript level, so takes no real advantage from having
generated it inside NSS (I'd expect it instead to leave the AES256 key
inside NSS and just get back the handle to it to encrypt what it needs
later. It seems they believe they *must* be able to extract the key, but
I don't really understand why).

Now it's certainly the most sensible things to do to have all crypto be
handled by NSS.

But I thought J-PAKE was intended as an as quick as possible hack, which
is why the Sync team was so reluctant to switch to using SRP (unless it
was proven J-PAKE was cryptographically weak), despite SRP being much
more widely used (and having already several open bugs, with patch even,
requesting it's inclusion in NSS/Firefox).

Seeing the J-PAKE patch, it would be quite fast to rewrite it using SRP
instead of J-PAKE using the existing SRP patch
(CKM_NSS_JPAKE_ROUND1-ROUND2_SHAxxx/CKM_NSS_JPAKE_FINAL_SHAxxx would
change to CKM_NSS_SRP_SERVER_KEY_PAIR_GEN/CKM_NSS_SRP_DERIVE, etc.),
it's totally equivalent functionally, we'd just add a small step where
the server, before deriving the shared key, make a call to generate the
password verifier from the password.

BTW, it's a bit disappointing to see the javascript so entangled with
the specificities of J-PAKE, when the P11 layer below maps it to generic
PK11_KeyGenWithTemplate / PK11_DeriveWithTemplate / PK11_Derive operations.

Brian Smith

unread,
Mar 4, 2011, 9:07:31 PM3/4/11
to mozilla's crypto code discussion list, Philipp von Weitershausen, mozilla-dev...@lists.mozilla.org, bwa...@mozilla.com
"Jean-Marc Desperrier" wrote:
> I notice the committed code extracts the generated shared symmetric
> key up to the javascript level, so takes no real advantage from
> having generated it inside NSS (I'd expect it instead to leave
> the AES256 key inside NSS and just get back the handle to it to
> encrypt what it needs later. It seems they believe they *must* be
> able to extract the key, but I don't really understand why).

This was done this way because of the desire to change the JavaScript parts of Sync as little as possible. The kind of improvement you described above will be made to resolve Bug 443386 and/or Bug 638966.

> BTW, it's a bit disappointing to see the javascript so entangled with
> the specificities of J-PAKE, when the P11 layer below maps it to
> generic PK11_KeyGenWithTemplate / PK11_DeriveWithTemplate /
> PK11_Derive operations.

We don't intend to expose J-PAKE to anything except Sync. The resolution of Bug 443386 will change that interface in a non-backward-compatible way (except for Sync, which will get modified to use the new interface in lockstep). Also, I am hoping to move *all* of the lower-level Sync crypto stuff from Javascript into its own native-code implementation exposed with more Sync-specific APIs. See Bug 636309.

I am very interested in what you want to use SRP for (especially other than Sync). Maybe there is some way to get your SRP-based ideas working in Firefox without waiting around for us to take some action on it. Lets start a new thread (privately or on this mailing list) about that.

- Brian

Brian Smith

unread,
Mar 4, 2011, 9:07:31 PM3/4/11
to mozilla's crypto code discussion list, Philipp von Weitershausen, mozilla-dev...@lists.mozilla.org, bwa...@mozilla.com

Jean-Marc Desperrier

unread,
Mar 7, 2011, 1:34:13 PM3/7/11
to mozilla-dev...@lists.mozilla.org
Brian Smith wrote:
> "Jean-Marc Desperrier" wrote:
>> [...] (I'd expect it instead to leave

>> the AES256 key inside NSS and just get back the handle to it to
>> encrypt what it needs later. [...]).

>
> The kind of improvement you described above will be made to resolve
> Bug 443386 and/or Bug 638966.

I think Bug 638966 is slightly different, it's about permanently storing
the secret keys in the NSS db (I don't know if that's really possible,
typically the db only stores privates keys).

Doing this could solve bug 443386 except that SRP is not a FIPS approved
algorithm so I'm sure if the module ought to still be able to do SRP
when in FIPS mode.

> [...] The


> resolution of Bug 443386 will change that interface in a
> non-backward-compatible way (except for Sync, which will get modified
> to use the new interface in lockstep).

You are considering to remove PBKDF2 ? If so, the encrypted result will
be incompatible before/after the move ?

> I am very interested in what you want to use SRP for (especially
> other than Sync).

If I need SRP, I can have it in an extension, it's just a pity to not
get it from NSS.

But Curl, that supports secret keys from version 7.21.4, with GnuTLS
only at the moment but is pushing hard to get in in Openssl also,
apparently has simply given up about having TSP-SRP support when
compiled with NSS.

I see in an old doc that Johnathan was considering SRP support in
Firefox for 3.next ( https://wiki.mozilla.org/Firefox/3.next/hitlist ).

Brian Smith

unread,
Mar 7, 2011, 9:50:43 PM3/7/11
to mozilla's crypto code discussion list
"Jean-Marc Desperrier" wrote:
> Brian Smith wrote:
> > The kind of improvement you described above will be made to resolve
> > Bug 443386 and/or Bug 638966.
>
> I think Bug 638966 is slightly different, it's about permanently
> storing the secret keys in the NSS db (I don't know if that's
> really possible, typically the db only stores privates keys).

Softoken may have to be enhanced to support storing Sync (or generic) keys for this to work.

> Doing this could solve bug 443386 except that SRP is not a FIPS
> approved algorithm so I'm sure if the module ought to still be
> able to do SRP when in FIPS mode.

See https://bugzilla.mozilla.org/show_bug.cgi?id=443386#c19 (comment 19). The same would apply to SRP.

> You are considering to remove PBKDF2 ? If so, the encrypted result
> will be incompatible before/after the move?

PBKDF2 was already replcaed with HKDF.

- Brian

Brian Smith

unread,
Mar 7, 2011, 10:21:56 PM3/7/11
to mozilla's crypto code discussion list
Jean-Marc Desperrier wrote:
> But Curl, that supports secret keys from version 7.21.4, with GnuTLS
> only at the moment but is pushing hard to get in in Openssl also,
> apparently has simply given up about having TSP-SRP support when
> compiled with NSS.
>
> I see in an old doc that Johnathan was considering SRP support in
> Firefox for 3.next ( https://wiki.mozilla.org/Firefox/3.next/hitlist
> ).

An augmented PAKE user authentication protocol might be very useful for some things, but TLS-SRP seems very troublesome. IIRC, there are at least four deal-breaking problems with TLS-SRP as a substitute for PKI:

1. The user's username is sent in the clear. The user's username should be protected.

2. The strength of the authentication of the website to the user is a function of the strength of that user's password; that is, a user with a weak password will have a very weak assurance of the server's identity. (I don't remember if this is exactly correct, but I think so.)

3. The user cannot verify the identity of the server until after the password has been entered. However, we've trained users to enter their passwords only after verifying the server's identity.

4. You cannot identify the server until after you've created a username/password on that server. But, account creation usually requires giving the server personally identifying information that should be protected by encryption and only sent after the server has been authenticated.

Using the TLS_SRP_SHA_RSA_* cipher suites avoids problems #2 and #3 and using a non-SRP ciphersuite for account signup solves #4. But, that requires using PKI and #1 is still a big problem.

- Brian

Daniel Stenberg

unread,
Mar 8, 2011, 2:44:39 AM3/8/11
to mozilla's crypto code discussion list
On Mon, 7 Mar 2011, Brian Smith wrote:

>> But Curl, that supports secret keys from version 7.21.4, with GnuTLS only
>> at the moment but is pushing hard to get in in Openssl also, apparently has
>> simply given up about having TSP-SRP support when compiled with NSS.

Can I just add that we (in the curl project) haven't "given up" on anything -
we're an open source project and we will of course support whatever our users
and developers want and make happen.

curl supports 7 different SSL libraries (including NSS) and if some of the
libs don't have the necessary features, we provide these specific features
only when built with a lib featuring them.

TLS-SRP is an example of a feature that seemingly only GnuTLS delivers out of
the box right now.

> An augmented PAKE user authentication protocol might be very useful for some
> things, but TLS-SRP seems very troublesome. IIRC, there are at least four
> deal-breaking problems with TLS-SRP as a substitute for PKI:

There are places for both ways I'd say, and it seems there are users out there
who think so. I don't think many people argue that it substitutes PKI to any
greater extent.

--

/ daniel.haxx.se

Jean-Marc Desperrier

unread,
Mar 9, 2011, 3:45:16 AM3/9/11
to mozilla-dev...@lists.mozilla.org
Brian Smith wrote:
> An augmented PAKE user authentication protocol might be very useful
> for some things, but TLS-SRP seems very troublesome. IIRC, there are at
> least four deal-breaking problems with TLS-SRP as a substitute for PKI:

I don't see it as a substitute for PKI, only as a substitute for
user/password. And my point from start was not really that NSS must
implement an EKE protocol, but that if there was one then it should be
SRP rather than JPAKE.

BTW about the patent situation, I did my research, the conclusion is
that they are various patents about everything EKE, but SRP has the
advantage above most others protocols, including JPAKE, that Stanford
owns a patent on it (the license is free for any usage) whose claims are
apparently not shared with other existing patents, so if someone wants
to claim rights on it, they'd first have to show Stanford shouldn't have
received this patent. Not that this never happens (cf
Microsoft/Lucent/Fraunhofer), but it's still much less likely than to
just to hope nobody will ever claim rights on the format you're using.

> 1. The user's username is sent in the clear. The user's username should be protected.

You mean for privacy reasons, not as a way to limit brute force attacks ?

Although I don't see SRP as a replacement for PKI, I'm tempted to say
that the equivalent of the username in PKI is the certificate, and that
the certificate is not protected at all. In a SSL session with client
authentification, the client certificate is sent in the clear (except in
the case of IIS, that open a non-authenticated SSL session and
renegotiates it at the time it needs user authentication).

> 2. The strength of the authentication of the website to the user is
> a function of the strength of that user's password; that is, a user with a
> weak password will have a very weak assurance of the server's identity.
> (I don't remember if this is exactly correct, but I think so.)

That seems correct to me, and that's really an important point to take
into account for the security of SRP based solution, thanks.

> 3. The user cannot verify the identity of the server until after the
> password has been entered. However, we've trained users to enter their
> passwords only after verifying the server's identity.

The rule doesn't change so much : you still need to enter your password
inside a secure element, ie if we teach user it's OK to enter their SRP
password in a non secure GUI "because it won't be sent to the server" we
loose.

Anders Rundgren

unread,
Mar 9, 2011, 4:21:49 AM3/9/11
to dev-tec...@lists.mozilla.org
It is too late introducing TLS-SRP, the market will not use it.
Why not make NSS more useful for certificates instead?

Anders

On 2011-03-09 09:45, Jean-Marc Desperrier wrote:
> Brian Smith wrote:

>> An augmented PAKE user authentication protocol might be very useful
>> for some things, but TLS-SRP seems very troublesome. IIRC, there are at
>> least four deal-breaking problems with TLS-SRP as a substitute for PKI:
>

> I don't see it as a substitute for PKI, only as a substitute for
> user/password. And my point from start was not really that NSS must
> implement an EKE protocol, but that if there was one then it should be
> SRP rather than JPAKE.
>
> BTW about the patent situation, I did my research, the conclusion is
> that they are various patents about everything EKE, but SRP has the
> advantage above most others protocols, including JPAKE, that Stanford
> owns a patent on it (the license is free for any usage) whose claims are
> apparently not shared with other existing patents, so if someone wants
> to claim rights on it, they'd first have to show Stanford shouldn't have
> received this patent. Not that this never happens (cf
> Microsoft/Lucent/Fraunhofer), but it's still much less likely than to
> just to hope nobody will ever claim rights on the format you're using.
>

>> 1. The user's username is sent in the clear. The user's username should be protected.
>

> You mean for privacy reasons, not as a way to limit brute force attacks ?
>
> Although I don't see SRP as a replacement for PKI, I'm tempted to say
> that the equivalent of the username in PKI is the certificate, and that
> the certificate is not protected at all. In a SSL session with client
> authentification, the client certificate is sent in the clear (except in
> the case of IIS, that open a non-authenticated SSL session and
> renegotiates it at the time it needs user authentication).
>

>> 2. The strength of the authentication of the website to the user is
>> a function of the strength of that user's password; that is, a user with a
>> weak password will have a very weak assurance of the server's identity.
>> (I don't remember if this is exactly correct, but I think so.)
>

> That seems correct to me, and that's really an important point to take
> into account for the security of SRP based solution, thanks.
>

>> 3. The user cannot verify the identity of the server until after the
>> password has been entered. However, we've trained users to enter their
>> passwords only after verifying the server's identity.
>

> The rule doesn't change so much : you still need to enter your password
> inside a secure element, ie if we teach user it's OK to enter their SRP
> password in a non secure GUI "because it won't be sent to the server" we
> loose.
>

Daniel Stenberg

unread,
Mar 10, 2011, 3:32:22 AM3/10/11
to mozilla's crypto code discussion list
On Wed, 9 Mar 2011, Anders Rundgren wrote:

> It is too late introducing TLS-SRP, the market will not use it.

Uh? There's not just one single market that will or won't use a particular
protocol feature. There are plenty of different areas where TLS is used and
some of them will use TLS-SRP, and some even already are.

--

/ daniel.haxx.se

Anders Rundgren

unread,
Mar 10, 2011, 5:44:27 AM3/10/11
to mozilla's crypto code discussion list

TLS-SRP doesn't do anything that certificates do not do better.
If SRP had been available in the browser it could have been important.
But it failed, hard.

Anders

Brian Smith

unread,
Mar 10, 2011, 4:07:06 PM3/10/11
to mozilla's crypto code discussion list, mozilla-dev...@lists.mozilla.org
"Jean-Marc Desperrier" wrote:
> I don't see it as a substitute for PKI, only as a substitute for
> user/password.

If you want SRP but don't need TLS-SRP then you could implement SRP outside of NSS and then build the UI support around that non-NSS support as a HTTP


> > 1. The user's username is sent in the clear. The user's username
> > should be protected.
>
> You mean for privacy reasons, not as a way to limit brute force
> attacks ?

Both. In particular, if somebody learned that my Gizmodo username/password was bsm...@mozilla.com/bieber4ever, then when they see "bsm...@mozilla.com" in the clear they can just try to break into the connection using that password. But, also, I do not want to tell everybody in every Starbucks I go to my email address.

> Although I don't see SRP as a replacement for PKI, I'm tempted to say
> that the equivalent of the username in PKI is the certificate, and
> that the certificate is not protected at all. In a SSL session with
> client authentification, the client certificate is sent in the clear
> (except in the case of IIS, that open a non-authenticated SSL session
> and renegotiates it at the time it needs user authentication).

Yes, this is a problem that needs to be fixed in TLS and worked around (as much as possible) in implementations. I just filed https://bugzilla.mozilla.org/show_bug.cgi?id=640745 about this. The same could be done for TLS-SRP, but you would need to authenticate the server first using PKI.

> > 3. The user cannot verify the identity of the server until after the
> > password has been entered. However, we've trained users to enter
> > their passwords only after verifying the server's identity.
>
> The rule doesn't change so much : you still need to enter your
> password inside a secure element, ie if we teach user it's OK to
> enter their SRP password in a non secure GUI "because it won't be
> sent to the server" we loose.

It's hard to explain what a "secure element" is to somebody. It's much easier to say "make sure the address bar turns green and says 'PayPal, Inc.'" but even that's asking too much most of the time.

- Brian

Brian Smith

unread,
Mar 10, 2011, 4:07:06 PM3/10/11
to mozilla's crypto code discussion list, mozilla-dev...@lists.mozilla.org

Anders Rundgren

unread,
Mar 11, 2011, 2:07:18 AM3/11/11
to dev-tec...@lists.mozilla.org
On 2011-03-10 22:07, Brian Smith wrote:
> "Jean-Marc Desperrier" wrote:

>> The rule doesn't change so much : you still need to enter your
>> password inside a secure element, ie if we teach user it's OK to
>> enter their SRP password in a non secure GUI "because it won't be
>> sent to the server" we loose.
>
> It's hard to explain what a "secure element" is to somebody.
> It's much easier to say "make sure the address bar turns green
> and says 'PayPal, Inc.'" but even that's asking too much most of the time.

If you use PKI + PIN-code a PIN code given to a bad server through a
spoofed GUI doesn't represent a major security issue since the bad guy
has no use of it unless he has local access to your computer/token/SE.

This is another reason why SRP is the wrong solution.

Unfortunately NSS has no support for PIN provisioning through the
browser so all this is mainly "theory" except for a few lucky who
(for example) have a PIV card.

Anders

0 new messages