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 ).
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
