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 functions are you referring when you say "the interface to these > functions isn't frozen." ?? The functions you listed below (which I > haven't copied here)? Yes. > 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 concern with putting J-PAKE building blocks in NSS is getting that NSS release out for FF4.0. > - the wisdom of making Mozilla products even MORE dependent on shared > secrets and passwords than they already are, when, for at least a decade, > shared secrets in general and passwords in particular have been regarded > by security experts as more part of the problem than part of the solution. > > Letting mozilla products become a playground for home-baked crypto > protocols. That's a gate you'll find difficult to close once it is > allowed to be opened. At the present time, the only thing you can do with the Sync account password is delete the data off the server and/or associate a different (strong) sync key with the account. Besides J-PAKE, it looks like Sync crypto will end up using quite simple/standard/boring algorithms & techniques. Once things are nailed down a little more, there will be a complete design document (and code, of course) for public review. Cheers, Brian -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
