"Jean-Marc Desperrier" wrote: > I notice the committed code extracts the generated shared symmetric > key up to the javascript level, so takes no real advantage from > having generated it inside NSS (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. It seems they believe they *must* be > able to extract the key, but I don't really understand why).
This was done this way because of the desire to change the JavaScript parts of Sync as little as possible. The kind of improvement you described above will be made to resolve Bug 443386 and/or Bug 638966. > BTW, it's a bit disappointing to see the javascript so entangled with > the specificities of J-PAKE, when the P11 layer below maps it to > generic PK11_KeyGenWithTemplate / PK11_DeriveWithTemplate / > PK11_Derive operations. We don't intend to expose J-PAKE to anything except Sync. 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). Also, I am hoping to move *all* of the lower-level Sync crypto stuff from Javascript into its own native-code implementation exposed with more Sync-specific APIs. See Bug 636309. I am very interested in what you want to use SRP for (especially other than Sync). Maybe there is some way to get your SRP-based ideas working in Firefox without waiting around for us to take some action on it. Lets start a new thread (privately or on this mailing list) about that. - Brian -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
