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]
Date: Tue, 14 Oct 2014 11:23:23 +0200
From: Krisztián Pintér <pinterkr@...il.com>
To: "discussions@...sword-hashing.net" <discussions@...sword-hashing.net>
Subject: Re: [PHC] What is "basic cryptography" ?

On Tue, Oct 14, 2014 at 10:28 AM, beloumi <beloumi@...eup.net> wrote:
> This is surely not a main topic, but especially password hashing schemes
> have long execution times and uses large amounts of memory, so a cold
> boot attack or the risk of swapping is more relevant than for other
> crypto topics.

that is why i rang the bells some time ago about filling up large
portions of memory with password dependent data. keeping the password
for a long time is not too dangerous, and even can be forced into the
cpu (some simd registers?). but having many megabytes of data that
essentially in 1:1 relationship with the password is something to be
wary of. even in a scenario where you can recover a small fraction of
the data with high error rate, it acts like a supermassive error
correction code.

i was hoping to see candidates that can be blinded, but the only one
with a chance seems to be makwa, however it does not use large memory.
but certainly, if we want low overhead blinding, we need some
"mathematical" hashing as opposed to PRF based. for PRFs, the general
option is to encrypt. but it adds cost to the defender, while not the
attacker. i wonder if it makes sense anyways. salsa20/12 with a random
key seems to be nice solution. it can trivially be added to any phc
candidate using RAM, but promotes 512bit memory granularity.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ