Re: Firefox profile encryption
I plan on using a randomly generated 32-byte key provided by a trusted 3rd party. I also plan on using a randomly generated 32-byte initialization vector generated by NSS within Firefox (to use with the AES Chain Block Cipher scheme). What should I do with the initialization vector? I read that you have to keep changing the initialization vector to preserve security. But to decrypt the data you need the same initialization vector that you encrypted the data with (which might not be the same IV as other files in the profile at that given moment). Now, I know that SQLCipher keeps the initialization vector at the end of every page it reads/writes to. Should I be doing something similar with NSS (keeping the IV at the end or at the start of each file)? On Wed, Jun 6, 2012 at 3:18 PM, Robert Relyea rrel...@redhat.com wrote: On 06/04/2012 08:20 AM, David Dahl wrote: - Original Message - From: Denis Cormierdenis.r.cormier@**gmail.comdenis.r.corm...@gmail.com To: dev-tech-crypto@lists.mozilla.**orgdev-tech-crypto@lists.mozilla.org Sent: Monday, June 4, 2012 9:10:34 AM Subject: Firefox profile encryption 1. Assuming the user does not enter a master password, would key3.db require further encryption? 2. Am I missing files from the profile that would contain sensitive information? I believe the key3.db stores everything encrypted. I am not sure where the key it uses to encrypt things might be stored. Yes, key3.db is encrypted. The key is derived from the Master Password. In fact that is what the master password is (the source of the PBE which encrypts the key3.db). If no master password is set, the key is derived from the password . The key3.db is still encrypted, but it's contents is trivially encrypted because the key is known. Question, what key are you using to encrypt the whole profile? You should also include 'sessionstore.bak' and 'webappsstore.sqlite' (which may only be in pre-releases right now). Also, localstore.rdf has information about extensions and search providers you have installed, my nightly build also has chromeappsstore.sqlite which has web urls in it that are I think pinned to the new tab page. Is your project hosted anywhere? I am quite interested in how this will work. Cheers, David -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Firefox profile encryption
On 06/08/2012 01:06 PM, Denis Cormier wrote: I plan on using a randomly generated 32-byte key provided by a trusted 3rd party. I also plan on using a randomly generated 32-byte initialization vector generated by NSS within Firefox (to use with the AES Chain Block Cipher scheme). So you are fetching the key off box through some authenticated and protected channel? What should I do with the initialization vector? I read that you have to keep changing the initialization vector to preserve security. But to decrypt the data you need the same initialization vector that you encrypted the data with (which might not be the same IV as other files in the profile at that given moment). Now, I know that SQLCipher keeps the initialization vector at the end of every page it reads/writes to. Should I be doing something similar with NSS (keeping the IV at the end or at the start of each file)? There is no problem using a single generated IV to encrypt a full file. The IV can and should be public, so you can store the IV with the file. If you make changes to the file, you should generate a New IV and encrypt the full file again. If you want random access (writes or reads), you should generate a new IV per block that you need to read/write (a la SQLCipher's pages). You only need to change the IV on write, and there is no problem including the IV with the data for read. All of this assumes that writes to these files can be triggered by untrusted 3 parties which do not have access to the key, but do have access to the file. This is rare, but it's easier just to protect against the attack than to analyze if you may be vulnerable to attack. Also don't use a stream cipher to encrypt the files (RC-4, AES-CTR, AES-OFB, etc). bob On Wed, Jun 6, 2012 at 3:18 PM, Robert Relyearrel...@redhat.com wrote: On 06/04/2012 08:20 AM, David Dahl wrote: - Original Message - From: Denis Cormierdenis.r.cormier@**gmail.comdenis.r.corm...@gmail.com To: dev-tech-crypto@lists.mozilla.**orgdev-tech-crypto@lists.mozilla.org Sent: Monday, June 4, 2012 9:10:34 AM Subject: Firefox profile encryption 1. Assuming the user does not enter a master password, would key3.db require further encryption? 2. Am I missing files from the profile that would contain sensitive information? I believe the key3.db stores everything encrypted. I am not sure where the key it uses to encrypt things might be stored. Yes, key3.db is encrypted. The key is derived from the Master Password. In fact that is what the master password is (the source of the PBE which encrypts the key3.db). If no master password is set, the key is derived from the password . The key3.db is still encrypted, but it's contents is trivially encrypted because the key is known. Question, what key are you using to encrypt the whole profile? You should also include 'sessionstore.bak' and 'webappsstore.sqlite' (which may only be in pre-releases right now). Also, localstore.rdf has information about extensions and search providers you have installed, my nightly build also has chromeappsstore.sqlite which has web urls in it that are I think pinned to the new tab page. Is your project hosted anywhere? I am quite interested in how this will work. Cheers, David -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Is there an ETA yet for when Firefox will use libpkix by default?
Brian, It has been well over 3 years since the cross-certification looping bug described in Bug #479508 and Bug #634074 was first filed. It was decided that the proper fix was to wait for Firefox to migrate to libpkix by default. We and our customers have been waiting patiently for this fix. The effects of this bug have apparently been getting worse over time, and we don't believe that we can tolerate it for very much longer. Might there be a Firefox 13.x point-release that will enable libpkix by default? Will Firefox 14 enable libpkix by default? Or can you say that enabling libpkix by default will definitely not happen until Firefox 15 or later? If you're reasonably sure it won't happen by Firefox 14, my CTO has asked me to urgently i) attempt to write an ugly kludge of a patch to fix the bug in the old certificate verification library and then ii) petition Mozilla and the NSS team to accept my patch and ship it in Firefox 14 or sooner. Thanks. -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Is there an ETA yet for when Firefox will use libpkix by default?
Rob, Please fix the bug in the old certificate verification library. Thanks. Are you going to use the approach outlined by Nelson in bug 479508 and bug 482153? Wan-Teh -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
