> Brian Smith wrote: > > (Because of Firefox Sync, we are now always going to have crypto > > features that won't work in FIPS mode.) > Sigh, ignoring FIPS mode in a feature, is usually a red flag. It means > you are handling CSP's where you really shouldn't be. Firefox Sync > *CAN* be implemented in FIPS mode, and we should work to make sure > that happens.
Because of the way key exchange and key entry are done in Firefox Sync, even if it worked in FIPS mode, it wouldn't be FIPS compliant. Because of usability constraints, Sync will use an unapproved key exchange mechanism (J-PAKE). And, it also allows manual key entry. For compatibility with previous versions we also have to support encryption/authentication keys derived from weaker keys via PBKDF2, though the new Sync crypto design will avoid PBKDF2 for new users. > FIPS mode isn't just a check box. If you *CAN'T* work in FIPS mode, it > usually means you need to take another look at your architecture. I am more-or-less a "In NIST We Trust" kind of guy and I am very interested in finding a usable key-exchange mechanism that doesn't require an unapproved algorithm like J-PAKE and which meets the other contraints imposed upon Sync--namely that the Sync server shouldn't have access to the plaintext of the data it stores and that setup must be easy & secure without requiring huge amounts of manual entry by the user. Compliance with FIPS 140 in letter and in spirit would be a huge plus. Suggestions are welcome. I will post an overview of the plan for sync crypto to this mailing list soon for interested people to review. Cheers, Brian -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
