phc-discussions - Re: [PHC] A review per day

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20140902201630.GA26330@bolet.org>
Date: Tue, 2 Sep 2014 22:16:30 +0200
From: Thomas Pornin <pornin@...et.org>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] A review per day - Schvrch

On Tue, Sep 02, 2014 at 08:40:40PM +0200, Krisztián Pintér wrote:
> 2, you make the error others made earlier, namely assuming today's
> hardware. next gen processors might be very different, maybe they will
> behave more like asics in terms of keccak performance. we have no idea
> what processors will be like in ten years.

I am pretty sure that processors in 2024 will still be able to run
x86 code. Incidentally, "tne years" is the time it took for CPU to
begin to offer AES-dedicated opcodes.

(Well, that's not entirely true, the VIA C7 had the "Padlock" extension
with AES support back in 2005. But "mainstream" CPU began to offer
AES-NI in 2008, and it began to be common in 2011 or so. My point is
that these things take a lot of time and a lot of incentive. I honestly
don't see the same happening any time soon for Keccak. At least not
before another decade.)

> 3, hw is not the attacker's platform. a lot of resource limited
> friendly platforms might need to run a PBKDF, media players, routers,
> any tool with an html or terminal admin interface, etc. it is a false
> view that password defenders have gigantic multicore multigigabyte
> monsters.

I think "hardware is the attacker's platform" means that the _attacker_,
not the defender, has access to FPGA and ASIC. I totally agree with you
that there are many usage contexts where the defender is a rather feeble
system with little available RAM, and no specialized opcodes like AES
instructions or even SSE2 or 64-bit registers.(*)

The point, here, is that the attacker is assumed to have a larger choice
of implementation options for his budget, and the password hashing
function should strive not to allow the attacker to leverage that choice
into faster attacks. In that sense, Keccak gives a bit of a headstart to
the attacker, since it is known to greatly benefit from FPGA / ASIC
(i.e. the boost that the attacker can obtain by buying 1000$ worth of
FPGA instead of 1000$ worth of x86 CPU is greater in the case of Keccak
than in the case of, say, SHA-512). This is not critical, but it
highlights the peculiarities of the problem of password hashing. During
the SHA-3 competition, Keccak's hardware performance was a big selling
point, making up for somewhat poor software performance. For PHC, we
really want it to work the other way round.

	--Thomas Pornin