Services/Sync/SimplifyCrypto: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
(→Cons) |
||
| Line 29: | Line 29: | ||
# 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 this may not be the case) | # 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) | ||
# We are giving up PKI. I (st3fan) understand that this was done to share data with groups? | |||
== Security Concerns == | == Security Concerns == | ||
Revision as of 17:17, 11 October 2010
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.
- each encrypted object contains a relative URI pointing to the key that can decrypt it (in 99.99999% percent of the case this is same, except when the WBO IDs contain slashes and clients get very confused).
Problem
We might want to drop the key URIs for encrypted payloads (specify the hard coded path for their key), but that requires another version bump (and a Firefox Home update). If we're doing _that_, then it may be worth the effort of completely dropping key wrapping. 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.
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)
- We are giving up PKI. I (st3fan) understand that this was done to share data with groups?