canmove, Confirmed users
640
edits
Services/Sync/SimplifiedCrypto: Difference between revisions
Services/Sync/SimplifiedCrypto (view source)
Revision as of 21:51, 10 January 2011
, 10 January 2011Updates.
(Updates.) |
|||
| Line 60: | Line 60: | ||
* Attempt to store, using appropriate race-avoidance technique in case there are multiple clients attempting to upgrade. | * Attempt to store, using appropriate race-avoidance technique in case there are multiple clients attempting to upgrade. | ||
* Wipe old key data. | * Wipe old key data. | ||
-- Note that we leave key data in pubkey/privkey, because earlier versions of Sync unfortunately check for these prior to checking storage version. We opted to leave the keys there to get better user experience when an upgrade is needed. | |||
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 [[Services/Sync/SyncKey/J-PAKE|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 [[Services/Sync/SyncKey/J-PAKE|J-PAKE]]-style key distribution. | ||
Note that each major storage change alters the syncID, and thus PBKDF2 will only work for a single such change -- afterwards, one's passphrase is upgraded into a different sync key, and that won't work. | |||
=== Bulk keys === | === Bulk keys === | ||
| Line 67: | Line 70: | ||
The server stores one or more bulk keys: one 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, 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 stored in the single WBO storage/crypto/keys. | |||
Bulk keys are encrypted and HMACed using the sync key outputs, and cached on the client. (Current caching is per-session, but they're stored as identities to make persistence easier to implement.) | Bulk keys are encrypted and HMACed using the sync key outputs, and cached on the client. (Current caching is per-session, but they're stored as identities to make persistence easier to implement.) | ||
| Line 104: | Line 107: | ||
This change is incompatible with older clients: not only due to reorganizing the storage namespace, but also because existing clients will be unaware of the simpler encryption mechanism. That means a storage version bump (from 3 to 4). | This change is incompatible with older clients: not only due to reorganizing the storage namespace, but also because existing clients will be unaware of the simpler encryption mechanism. That means a storage version bump (from 3 to 4). | ||
An error in the argument order of the PBKDF2 function necessitated another version bump, from 4 to 5. Only a small set of nightly builds and add-ons used version 4; these will all prompt to upgrade on launch if a v5 storage version is found on the server. | |||