On 10/29/10 12:44, Nelson B Bolyard wrote:
On 2010/10/28 03:12 PDT, Jean-Marc Desperrier wrote:
<...>
Hardware protected private keys have a much more significant added value than
software ones when compared to those schemes. Unfortunately they are still very
little used. Except in China, sur
On 2010/10/29 01:44 PDT, Nelson B Bolyard wrote:
> No, passwords simply have NO PLACE in protecting the average user from
> phishing. And it doesn't matter whether the password is used to derive
> a session encryption key, or just as an authentication token. The user
> is just as vulnerable eith
On 10/29/2010 03:44 AM, Nelson B Bolyard wrote:
On 2010/10/28 03:12 PDT, Jean-Marc Desperrier wrote:
Nelson B Bolyard wrote:
[...] It because none of them: J-PAKE, SPEKE, SRP, or for that
matter, good old CRAM-MD5 address the NUMBER ONE problem with
passwords.
PHISHING.
They are a very sign
On 2010/10/28 03:12 PDT, Jean-Marc Desperrier wrote:
> Nelson B Bolyard wrote:
>> [...] It because none of them: J-PAKE, SPEKE, SRP, or for that
>> matter, good old CRAM-MD5 address the NUMBER ONE problem with passwords.
> >
>> PHISHING.
>
> They are a very signif
Nelson B Bolyard wrote:
[...] It because none of them: J-PAKE, SPEKE, SRP, or for that
matter, good old CRAM-MD5 address the NUMBER ONE problem with passwords.
>
PHISHING.
They are a very significant progress with regard to that actually.
What do JPAKE, SPEK
On 2010-10-25 10:49 PDT, Jean-Marc Desperrier wrote:
> Brian Smith wrote:
>> Nelson B Bolyard wrote:
>>
>>> [...]
>>> I'm talking about putting JBAKE (or whatever it is) into the base product.
>>> [...]
>> Is there something specific about J-PAKE that you think is bad or
>> worse than some alternat
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 triv
Brian Smith wrote:
Nelson B Bolyard wrote:
[...]
I'm talking about putting JBAKE (or whatever it is) into the base product.
[...]
Is there something specific about J-PAKE that you think is bad or
worse than some alternative? Are you objecting to J-PAKE because you do
not trust the proof
Nelson B Bolyard wrote:
> [...]
> I'm talking about putting JBAKE (or whatever it is) into the base product.
> [...]
Is there something specific about J-PAKE that you think is bad or worse than
some alternative? Are you objecting to J-PAKE because you do not trust the
proofs of security given
"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 toda
On 22/10/2010 19:07, Brian Smith wrote:
> Speaking only for myself, I have no objection to offering the mp_int
> bignum API as a "public" API out of freebl3.
If people are open to having the J-PAKE building blocks in FreeBL,
then we wouldn't need MPI to be part of the public API. The main conc
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
On 2010-10-22 11:35 PDT, Wan-Teh Chang wrote:
> On Thu, Oct 21, 2010 at 3:53 PM, Nelson B Bolyard wrote:
>> I'd say the interfaces to those functions (more precisely, their
>> signatures) are quite frozen. The mp_int bignum package API is so
>> frozen as to have become something of a standard of
This is a resend. Don't know why my previous copy went only to Marsh.
I intended it to go to the list as well.
On 2010-10-21 16:50 PDT, Marsh Ray wrote:
> On 10/21/2010 05:53 PM, Nelson B Bolyard wrote:
>> - Letting mozilla products become a playground for home-baked crypto
>> protocols. That's
On Thu, Oct 21, 2010 at 3:53 PM, Nelson B Bolyard wrote:
>
> I'd say the interfaces to those functions (more precisely, their
> signatures) are quite frozen. The mp_int bignum package API is so
> frozen as to have become something of a standard of its own. There
> are now at least 3 different im
Nelson B Bolyard wrote:
> Brian Smith wrote:
> I personally would like to find a way to avoid calling these internal
> functions from within Firefox--especially since there's no way to
> detect incompatibilities at compile-time and because the interface to
> these functions isn't frozen.
> To what
"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-
Philipp von Weitershausen wrote:
Not sure how generic the signature of the zero knowledge proof we use
in J-PAKE is. Compatibility with the implementation found in OpenSSL
is important for us right now
Hi,
Why are you choosing J-PAKE instead of SRP ?
Looking for an assessment of J-PAKE agains
On Oct 21, 7:58 pm, Robert Relyea wrote:
> > SHA1Context
> > SHA1_Hash
> > SHA1_HashBuf
> > SHA1_NewContext
> > SHA1_DestroyContext
> > SHA1_Begin
> > SHA1_Update
> > SHA1_End
>
> The exported equivalence to these functions are:
> #include "sechash.h"
I see. Having found the SHA1_* functions in b
On 10/21/2010 05:53 PM, Nelson B Bolyard wrote:
IMO, apart from the mundane technical issue of making hash and bignum
functions public, there are some bigger questions, such as:
- the wisdom of making Mozilla products even MORE dependent on shared
secrets and passwords than they already are, wh
On 2010-10-20 17:13 PDT, Brian Smith wrote:
> See https://bugzilla.mozilla.org/show_bug.cgi?id=601645.
>
> The following internal functions and data structures in FreeBL that
> would be used Firefox 4.0 Sync's J-PAKE implementation through JSCtypes
> (a mechanism for calling native code through Ja
On 10/20/2010 05:13 PM, Brian Smith wrote:
> See https://bugzilla.mozilla.org/show_bug.cgi?id=601645.
>
> The following internal functions and data structures in FreeBL that would be
> used Firefox 4.0 Sync's J-PAKE implementation through JSCtypes (a mechanism
> for calling native code through Ja
See https://bugzilla.mozilla.org/show_bug.cgi?id=601645.
The following internal functions and data structures in FreeBL that would be
used Firefox 4.0 Sync's J-PAKE implementation through JSCtypes (a mechanism for
calling native code through Javascript).
I personally would like to find a way t
23 matches
Mail list logo
