[Cryptography] How can you enter a 256-bit key in 12 decimal digits?

[Bill Cox]

On Mon, Jan 4, 2016 at 5:57 PM, Ray Dillinger <bear at sonic.net> wrote:

>
>
> On 01/03/2016 04:33 PM, Tony Arcieri wrote:
> > It's possible there's some sort of high-entropy on-device secret. There
> are
> > also ways of generating these secrets in such a way that attempts to
> > physically tamper with the device will destroy the secret generator, e.g.
> > https://en.wikipedia.org/wiki/Physical_unclonable_function
> >
>
> the point is though that if they steal the device, then they
> steal the high-entropy on-device secret along with it.  They
> only have to hook up their serial port to the wires that
> the buttons connect to, and try the 10^12 combinations.  They
> never have to try to work out the high-entropy secret.
>
>                                 Bear
>
>
>
> _______________________________________________
> The cryptography mailing list
> cryptography at metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography
>

It actually _can_ be done reasonably well, but I have never seen it in a
FDE product before.  A 12-digit decimal pin is nearly 2^40, well above the
number of combinations we typically need to try to guess a typical
password.  If the hardware were specifically designed to strengthen this
pin well, it could be secure.

For example, it could reserve a 100MiB for a ROM and use maybe 1MiB of RAM
and do a 1-second memory-hard hash, and use some operation the hardware
does fast for compute-time hardening.  If done well, an attacker might have
to spend 100ms per guess, and 3000 years worth of compute time on a machine
with 100MiB of ROM and 1MiB of RAM to crack the pin.  Not great, but not
terrible either.

OTOH, even our software FDEs, which I expect to be better than most
embedded closed-source solutions, does not get it quite right, at least not
yet.  LUKS for example has a long-term plan to switch to Argon2, which
should be an excellent solution for this use case, but for now, all they do
is PBKDF2-SHA1 for a fraction of a second.  They're switching to
PBKDF2-SHA256, but not for security reasons, but because SHA1 is going
away.  BitCoin mining ASICs prove we can do 1 GH/s for about $2 in
hardware.  The electricity actually costs more than the hardware.  If we
crank the numbers on the security level LUKS can achieve for sub-second
hashing using PBKDF2, it's not pretty when there is an ASIC attack.  An
ASIC attacker has something like a 1,000,000 to 1 cost advantage over the
defender, and at the same time may be willing to spend 1,000X more than the
defender.  Given most users choose passwords with < 30 bits of difficulty
to guess, an attacker may be able to crack most stretched passwords in < 1
second.  Even a GPU attack looks reasonable against PBKDF2-protected FDE
passwords.

Here's a lame FDE story about me.  I had a paranoid password on my Intel
FDE-SSD in my laptop, which I've since given to my son for use in school.
Every time the battery goes dead, which is about once a week, he has to
re-entry my crazy long high entropy password.  The Intel FDE disk cannot
change the password without wiping the drive (LUKS gets this part right),
and I don't have time to do a full OS re-install.

So, guess where my stupid supler-long painful password lives now?  It's
taped to the laptop.  The complaint I get now is that I taped it on the
bottom, and it is hard to flip the laptop over, type a few characters, flip
it again, and so on.  He wants it taped to the screen.

Bill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20160105/7e3eaf4e/attachment.html>