canmove, Confirmed users
725
edits
No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
== Current situation == | == Current situation == | ||
| Line 8: | Line 6: | ||
# generate a symmetric key from the passphrase using PBKDF2 and a random salt and encrypt ("wrap") the private key using that symmetric key | # 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 | # 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 | # 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 == | == Proposal == | ||