Services/Sync/SimplifyCrypto: Difference between revisions

no edit summary
No edit summary
Line 36: Line 36:
* We most likely want the option to use different keys for different objects (bookmarks vs. passwords, say). Again, we need 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.
* It would be an even bigger code and infrastructure change.
== Proposal C ==
* 2+ keys on server, all AES
** One HMAC key to rule them all (keys/hmac)
** One default bulk key that we use for all crypto (keys/default)
** Option to have collection-specific keys (keys/<collection>) for cases where a user wants to share a specific set of data, like bookmarks
* One AES key on the client to decrypt the wrapped keys stored on the server.  Users with existing passphrase-based keys will have these converted via PBKDF2 during migration, and we'll use the resulting key.  New users will not have an option to enter weak keys, just generate new ones.  Because J-PAKE transfers this key, having it be 25 characters instead of 20 is acceptable.


== Pros ==
== Pros ==
Confirmed users, Bureaucrats and Sysops emeriti
812

edits