[cryptography] Current state of brute-forcing random keys?
nico at cryptonector.com
Fri Jun 10 02:15:09 EDT 2011
On Fri, Jun 10, 2011 at 12:53 AM, Marsh Ray <marsh at extendedsubset.com> wrote:
>>> A few GB of state would hopefully put it in that size range where it's
>>> too large to fit on any attacker's ASIC,
>> In the scrypt design, there was no attempt to make something too large
>> to fit, but rather simply to consume more die area and increase cost.
> That's certainly valuable, but I think the biggest design payoff comes if
> you can force even the most advanced attacker to move data off and on the
> chip. Anything smaller than that amounts to giving large-die attackers a
> huge advantage over the typical defender.
> Of course, as Nico pointed out such a thing will not be usable everywhere.
> But not everything has to run on a cell phone, right?
For small documents? Yes, it all has to run on a cell phone. For
large datasets, no, of course not. I'm imagining the kinds of
documents that a typical user deals with: spreadsheets, presentations,
text, images, videos -- all the kinds of things that are easily
carried on mobile devices.
1GHz, .5GB mobile devices are getting cheap, so hopefully we can aim
for a KDF run time of 3 seconds on one of those and keep users happy
and their data reasonably secure. OTOH, it's pretty difficult to type
in long passphrases on mobile devices... Another option is to
re-encrypt documents to a device public key when downloading (and
again when uploading docs from the device), so as to avoid
passphrase-derived keys altogether; the device private keys would
likely be kept encrypted in a very low-entropy PIN though.. but if the
device is sufficiently tamper-resistant (ha!), that might do.
More information about the cryptography