Services/Sync/SimplifyCrypto: Difference between revisions

From MozillaWiki
< Services‎ | Sync
Jump to navigation Jump to search
(Created page with "We have no intention of doing PKI-based sharing in the future, so the current key wrapping is just legacy cost we don't need. Doing a bunch of key generation makes first syncs mu...")
 
No edit summary
Line 1: Line 1:
We have no intention of doing PKI-based sharing in the future, so the current key wrapping is just legacy cost we don't need. Doing a bunch of key generation makes first syncs much more painful than necessary, and isn't even enabled on Fennec.
We have no intention of doing PKI-based sharing in the future, so the current key wrapping is just legacy cost we don't need. Doing a bunch of key generation makes first syncs much more painful than necessary, and isn't even enabled on Fennec.
== Current situation ==
Right now we
# generate a RSA key pair
# generate a symmetric key from the passphrase using PBKDF2 and a random salt and encrypt ("wrap") the private key using that symmetric key
# upload public key, wrapped private key + IV + salt to server
# for each collection, generate a random symkey, encrypt it using the public key, and upload it to the server
== Proposal ==
* Everything is encrypted with 1 symmetric key. This key is never uploaded.
* The symmetric key is generated from the passphrase using PBKDF2, taking the clientID from the meta/global record as the salt.


== Pros ==
== Pros ==
Line 11: Line 25:


# Requires coordinating another storage bump between four clients on a tight schedule.
# Requires coordinating another storage bump between four clients on a tight schedule.
# Doing it before we drop 3.x support might mean we'd have to make this change to the binary components as well (Philipp believes no)
# Doing it before we drop 3.x support might mean we'd have to make this change to the binary components as well (Philipp believes this may not be the case)
 
== Proposal ==
 
* Everything is encrypted with 1 symmetric key. This key is never uploaded.
 
* The symmetric key is generated from the passphrase using PBKDF2, taking the clientID from the meta/global record as the salt.


== Security Concerns ==
== Security Concerns ==

Revision as of 16:49, 11 October 2010

We have no intention of doing PKI-based sharing in the future, so the current key wrapping is just legacy cost we don't need. Doing a bunch of key generation makes first syncs much more painful than necessary, and isn't even enabled on Fennec.

Current situation

Right now we

  1. generate a RSA key pair
  2. generate a symmetric key from the passphrase using PBKDF2 and a random salt and encrypt ("wrap") the private key using that symmetric key
  3. upload public key, wrapped private key + IV + salt to server
  4. for each collection, generate a random symkey, encrypt it using the public key, and upload it to the server

Proposal

  • Everything is encrypted with 1 symmetric key. This key is never uploaded.
  • The symmetric key is generated from the passphrase using PBKDF2, taking the clientID from the meta/global record as the salt.

Pros

  1. Doing it before Firefox 4 is a lot less disruptive than doing it later
  2. Removes a bunch of legacy code which adds overhead and system complexity
  3. Eliminates the need to store keys on the server, which means less network traffic (Toby says ~16%)
  4. There isn't a separate key that needs to be cached/updated, the key can always be generated from the passphrase

Cons

  1. Requires coordinating another storage bump between four clients on a tight schedule.
  2. Doing it before we drop 3.x support might mean we'd have to make this change to the binary components as well (Philipp believes this may not be the case)

Security Concerns