On Mar 30, 2008, at 9:37 PM, zooko wrote:
You can store your True Name, credit card number, bank
account number, mother's maiden name, and so forth, on the same
server as your password, but you don't have to worry about using
salts or key strengthening on those latter secrets, because the
server doesn't run a service that allows unauthenticated remote
people to connect, submit a guess as to their value, and receive
confirmation, the way it does for your password.
Tahoe doesn't run this service either. I can't use it to make guesses
at any of the values you mentioned. I can use it to make guesses at
whole documents incorporating such values, which is in most cases a
highly non-trivial distinction.
To make such guesses, I need to account for at least:
- file formats, since an e-mail message has a different on-disk
representation depending on the recipient's e-mail client,
- temporal and transport variance, as PDF documents generally
incorporate a generation timestamp, and e-mail messages include
routing headers (with timestamps!),
- document modifications due to variables other than the one(s) being
guessed, e.g. names, e-mail addresses, customized unsubscribe links.
I would be interested to see an actual real-world example of how a
document would fall to this attack. It strikes me as a cute threat in
theory, but uninteresting in practice.
*** Convergent encryption exposes whatever data is put into it to
the sorts of attacks that already apply to passwords.
Sometimes, under highly peculiar circumstances, etc.
Convergent encryption had been invented, analyzed and used for many
years, but to the best of my knowledge the first time that anyone
noticed this issue was March 16 of this year
FWIW, I have discussed this threat verbally with colleagues when I was
asked for possible designs for OLPC's server-based automatic backup
system. I dismissed it at the time as 'not a real-world concern'. I
might even have it in my notes, but those weren't published, so it's
moot.
Now PBKDF2 is a combination of the first two defenses -- salting and
key strengthening. When you first suggested PBKDF2, I -- and
apparently Jerry Leichter -- thought that you were suggesting its
salting feature as a solution.
Yeah, sorry, I wasn't being clear. I should've just said a key
strengthening function rather than naming anything in particular.
This would have a performance impact on normal everyday use of Tahoe
without, in my current estimation, making a brute-force/dictionary
attack infeasible.
Adding, say, 5 seconds of computation to the time it takes to store a
file is likely to be lost as noise in comparison with the actual
network upload time, while still making an attacker's life
_dramatically_ harder than now.
The trade-off is actually worse than it appears since the attacker is
attacking multiple users at once (in traditional convergent
encryption, he is attacking *all* users at once)
Again, is there a real-world example of the kind of data or documents
that would show this to be a serious problem? While it's technically
true that you're targeting all the users in parallel when brute
forcing, note that if you're not actually hyper-targeting your attack,
you need to brute force _all_ the variables I mention above in
parallel, except in pathological cases -- and those, if you know of
some, would be interesting for the discussion.
economy of scale, and can profitably invest in specialized tools,
even specialized hardware such as a COPACOBANA [1].
The OpenBSD eksblowfish/bcrypt design can't be bitsliced and generally
doesn't lend itself well to large speedups in hardware, by design.
Cheers,
--
Ivan Krstić [EMAIL PROTECTED] | http://radian.org
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
