canmove, Confirmed users
725
edits
Services/Sync/SimplifyCrypto: Difference between revisions
→Proposal
| Line 18: | Line 18: | ||
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. | 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 A == | ||
* Everything is encrypted with 1 symmetric key. This key is never uploaded. | * Everything is encrypted with 1 symmetric key. This key is never uploaded. | ||
* The symmetric key is generated from the | * The symmetric key is generated from the Sync Key using PBKDF2, taking the clientID from the meta/global record as the salt. | ||
== Proposal B == | |||
Essentially, we drop the public key layer, changing from [AES -> RSA -> AES] to [AES -> AES]: | |||
* The Sync Key is used to AES-decrypt one or more pairs of AES keys. These can be cached on the client, stored in the same manner as passwords: if you can steal them from there, you can steal the data directly. These AES keys are stored on the server just as bulk keys are now. | |||
* One of each pair of keys is used for HMAC on stored objects. The other is used to encrypt the data objects. | |||
We don't directly use the Sync Key to encrypt objects (the really simple option) for three or more reasons: | |||
* We want to use different secrets for HMAC and for encryption. We can't have multiple Sync Keys, so, we need the indirection. | |||
* We most likely want the option to use different keys for different objects (bookmarks vs. passwords, say). Again, we need indirection. | |||
* It would be an even bigger code and infrastructure change. | |||
== Pros == | == Pros == | ||