Services/Sync/SimplifyCrypto: Difference between revisions
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 | # 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 == | == 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
- 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
- Doing it before Firefox 4 is a lot less disruptive than doing it later
- Removes a bunch of legacy code which adds overhead and system complexity
- Eliminates the need to store keys on the server, which means less network traffic (Toby says ~16%)
- There isn't a separate key that needs to be cached/updated, the key can always be generated from the passphrase
Cons
- 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 this may not be the case)