Confirmed users
1,042
edits
Identity/CryptoIdeas/02-Recoverable-Keywrapping: Difference between revisions
Identity/CryptoIdeas/02-Recoverable-Keywrapping (view source)
Revision as of 17:05, 29 October 2013
, 29 October 2013no edit summary
No edit summary |
|||
| (3 intermediate revisions by one other user not shown) | |||
| Line 1: | Line 1: | ||
{{LastUpdated}} | |||
== Recoverable Keywrapping == | == Recoverable Keywrapping == | ||
| Line 131: | Line 132: | ||
The Account Server (or someone who compromises it) can mount a brute-force | The Account Server (or someone who compromises it) can mount a brute-force | ||
attack to deduce the user's password (and thus access the Secure data), using | attack to deduce the user's password (and thus access the Secure data), using | ||
one of: | one of the following as an oracle: | ||
* the SRP verifier (or H(S1) in the non-SRP variant) | * the SRP verifier (or H(S1) in the non-SRP variant) | ||
* a combination of the WSUK and an SDK (or plaintext/ciphertext pair from any web site the user has logged into) | * the HMAC used as an integrity check on the encrypted WSUK | ||
* a combination of the WSUK and an SDK (or a plaintext/ciphertext pair from any web site the user has logged into) | |||
(we might omit the HMAC integrity check on WSUK, to avoid providing this | |||
oracle, in the hopes that SRP verifiers cost too much to create, and getting | |||
a plaintext/ciphertext pair is too hard. If we did this, corruption in the | |||
account server would not be detected until the user tried to decrypt data and | |||
failed) | |||
The cost of this brute-force attack is equal to the cost of a single guess | The cost of this brute-force attack is equal to the cost of a single guess | ||
| Line 162: | Line 170: | ||
be able to take over the account, but that won't help them learn the SUK or | be able to take over the account, but that won't help them learn the SUK or | ||
the user's password). | the user's password). | ||
== Discussion == | |||
* Francois and I talked a bit about data migration: if a site moves to a new domain name, is it possible to bring the user's data along? I think it'd require an explicit authorization from the user on the old site, naming the new site, which doesn't sound very nice. Maybe some sort of .well-known on the old domain, to authorize new domains that should be allowed to get the same key? Tricky stuff. -warner 27-Sep-2012 | |||
* I'd really like to have an extension point that makes it easy for an addon to provide pairing-based no-password management of strong keys, like how Sync does it. The password-based scheme can be as strong as the password you're willing to manage, but we know most users won't use good passwords. A pairing-based scheme gives unconditional security despite user behavior, but doesn't offer password-based recovery or new-machine setup. We should enable addons to experiment with different approaches here. Specifically I'm thinking that an addon should be able to supply the "C" value in lieu of the password-based KDF. -warner 27-Sep-2012 | |||