On Fri, Jun 10, 2011 at 12:53 AM, Marsh Ray <[email protected]> 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. Nico -- _______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
