canmove, Confirmed users
725
edits
Services/Sync/SimplifiedCrypto: Difference between revisions
Services/Sync/SimplifiedCrypto (view source)
Revision as of 22:54, 29 October 2010
, 29 October 2010→Bulk keys
(→HMAC) |
|||
| Line 59: | Line 59: | ||
Bulk keys are encrypted and HMACed using the sync key outputs, 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?) | ||
::philikon: right now they're just cached by per-session. I think we want to store sync_key and data_key persistently though in the password manager (using identity.js) and re-fetch any time the keys collection changes | |||
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 65: | Line 67: | ||
:: While not really interesting here, this one-way property is really useful in other situations, like if you derived per-object encryption keys from a parent folder's key. You could then share the whole thing with someone by giving them the parent's key, or share just one object and *not* give them the ability to get at anything else in that folder. But the sharing discussion is for another day.. | :: While not really interesting here, this one-way property is really useful in other situations, like if you derived per-object encryption keys from a parent folder's key. You could then share the whole thing with someone by giving them the parent's key, or share just one object and *not* give them the ability to get at anything else in that folder. But the sharing discussion is for another day.. | ||
=== HMAC === | === HMAC === | ||