canmove, Confirmed users
640
edits
Services/Sync/SimplifiedCrypto: Difference between revisions
Jump to navigation
Jump to search
Services/Sync/SimplifiedCrypto (view source)
Revision as of 22:42, 29 October 2010
, 29 October 2010→Proposal
| Line 23: | Line 23: | ||
== Proposal == | == Proposal == | ||
'''tl;dr''': replace the passphrase with an AES key, which will be schlepped around using J-PAKE (so typing it is likely unnecessary). Use this key to | '''tl;dr''': replace the passphrase with an AES key, which will be schlepped around using J-PAKE (so typing it is likely unnecessary). Use this key to indirectly encrypt the 'bulk' symkeys. No RSA involved. | ||
| Line 30: | Line 30: | ||
Rather than have a user enter a passphrase (which will likely be weak), we have already transitioned to having them generate a "sync key" (which they can replace if they so choose). This is 20 alphanumeric characters. | Rather than have a user enter a passphrase (which will likely be weak), we have already transitioned to having them generate a "sync key" (which they can replace if they so choose). This is 20 alphanumeric characters. | ||
We propose to expand this to 25 characters, enough for a 128-bit AES key (case-insensitive; 23 is enough if case-sensitive, but that's little advantage). This avoids the use of PBKDF2 to routinely bootstrap the sync key into an AES key. Remove the ability for users to enter a key; it's always generated (giving us more confidence in the amount of entropy), and can be regenerated if desired. | We propose to expand this to 25 characters, enough for a base36-encoded 128-bit AES key (case-insensitive; 23 is enough if case-sensitive, but that's little advantage). This avoids the use of PBKDF2 to routinely bootstrap the sync key into an AES key. Remove the ability for users to enter a key; it's always generated (giving us more confidence in the amount of entropy), and can be regenerated if desired. | ||
The length of this key is not a big issue: we intend to use J-PAKE for the (infrequent) migration of keys between devices. In any case, 25 is not significantly worse than 20 if typing it does enter the picture. | The length of this key is not a big issue: we intend to use J-PAKE for the (infrequent) migration of keys between devices. In any case, 25 is not significantly worse than 20 if typing it does enter the picture. | ||
| Line 46: | Line 46: | ||
So long as the salt is available, other clients can apply PBKDF2 to their stored passphrase and the salt to yield the new key without any re-entry or J-PAKE-style key distribution. | So long as the salt is available, other clients can apply PBKDF2 to their stored passphrase and the salt to yield the new key without any re-entry or J-PAKE-style key distribution. | ||
The generated base36 alphanumeric key doesn't actually need to be decoded: it is used as input into a pair of hash operations which yield an encryption key and an HMAC key. | |||
::encr = SHA256("encrypt:" + key) | |||
::hmac = SHA256("hmac:" + key) | |||
The outputs are then used during the encryption process. | |||
=== Bulk keys === | === Bulk keys === | ||
| Line 51: | Line 59: | ||
The server stores one or more bulk keys: one default ("keys/default"), and an optional set of keys associated with specific collections. This will allow rudimentary sharing scenarios (provide your bookmarks collection key to a web app, and your passwords remain secure). A default key is simpler than having per-engine/collection keys without an obvious need. | The server stores one or more bulk keys: one default ("keys/default"), and an optional set of keys associated with specific collections. This will allow rudimentary sharing scenarios (provide your bookmarks collection key to a web app, and your passwords remain secure). A default key is simpler than having per-engine/collection keys without an obvious need. | ||
Bulk keys are encrypted using the sync key, and cached on the client. ('''TODO''': per-session or persistent caching?) | Bulk keys are encrypted and HMACed using the sync key outputs, and cached on the client. ('''TODO''': per-session or persistent caching?) | ||
The timestamp on the collections record allows clients to invalidate their key cache when a new key is associated with a collection: the 'keys' collection will appear to have changed. | The timestamp on the collections record allows clients to invalidate their key cache when a new key is associated with a collection: the 'keys' collection will appear to have changed. | ||
| Line 62: | Line 70: | ||
=== HMAC === | === HMAC === | ||
It's a good practice to use separate keys for HMAC and for encryption. The | It's a good practice to use separate keys for HMAC and for encryption. The bulk keys (stored encrypted on the server) are themselves used as input for exactly the same hash operations mentioned above. This yields a pair of keys that can be used for encryption and message authentication. | ||
| Line 70: | Line 76: | ||
Now is a great time to partition the "storage" namespace into "keys" and "data", rather than "keys" and everything else (e.g., "tabs"). This makes deletion of just keys or just data much more straightforward. | Now is a great time to partition the "storage" namespace into "keys" and "data", rather than "keys" and everything else (e.g., "tabs"). This makes deletion of just keys or just data much more straightforward. | ||
== Proposed flows == | == Proposed flows == | ||