canmove, Confirmed users
725
edits
(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 == | ||