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 Javascript). > > 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)? 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 implementations known to me that are all API compatible, differing only in the content of the (opaque) mp_int structure itself. Speaking only for myself, I have no objection to offering the mp_int bignum API as a "public" API out of freebl3. They're not presently exported from the freebl shared lib at all, but IMO, they could be. We merely wanted to minimize the exported API. But cryptography isn't the only user of bignums, and IMO, it doesn't make sense to for Mozilla to have yet another bignum library when NSS's is suitable for most purposes. The hash functions you mentioned ARE already exported and there's even a public API for them (albeit slightly different, as Bob has explained). 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, 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. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
