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 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. > > We might also have the option of rewriting the J-PAKE implementation in C, > include it in NSS, and making the J-PAKE functionality part of the public API > of NSS. Another option would be to rewrite it in C, add it to NSS, but only > enable it in a special (Firefox-specific) configuration of FreeBL. The > default option seems to be to keep accessing these internal functions and > data structures through JavaScript, and rely on NSS distributors to not > change them. I am eager to hear others' suggestions. > > Note that Sync's design is fundamentally incompatible with FIPS mode and > consequently there's no need to consider FIPS mode concerns. We will just > disable Sync (or require the user to disable it) in FIPS mode. > > Cheers, > Brian > > 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"
HASHContext HASH_HashBuf HASH_Create HASH_Destroy HASH_Begin HASH_Update HASH_End (It's not an accident that they are similarly named). HASH_Create takes a HASH_HashType to say what time of hash you are using. In addition there is a function that returnes the expected length based on HASH_HashType, or the HASHContext. There is also a function that maps oids to HASH_HashType. The latter two would help you if you need hash agility (which you should probably think about). If your protocal uses oids to specify your hash function, then you won't even need to know what the real hash is under the covers. > mp_sign > mp_size > mp_err > mp_digit > mp_int > mp_init > mp_clear > mp_set > mp_sub_d > mp_sub > mp_cmp > mp_cmp_d > mp_mod > mp_addmod > mp_submod > mp_mulmod > mp_exptmod > mp_read_raw > mp_raw_size > mp_toraw > mp_read_radix > mp_radix_size > mp_toradix > It depends on what J-PAKE is doing. My guess is it's doing a zero knowledge proof algorithm (given the need for add and sub), which is generally useful. I would be view a patch that puts the zero knowledge proof into freebl with favor (and would clear out time to review such a patch). If we are just talking DH or RSA operations, there are public equivalents to those as well. bob
-- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
