phc-discussions - Re: [PHC] What is "basic cryptography" ?

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:50:54 +0200
From: Dmitry Khovratovich <khovratovich@...il.com>
To: "discussions@...sword-hashing.net" <discussions@...sword-hashing.net>
Subject: Re: [PHC] What is "basic cryptography" ?

I did not check other candidates, but Argon does not require you to store
the password in cleartext in many copies in memory. Just do not store the
inputs to the first call of the Mix operation (nonlinear transformation on
the 512-byte block) in memory and store only the outputs. This does not
allow to recover the password from any portion of memory (except for its
initial storage); the algorithm remains the same, and the computational
costs remain the same (just the operation order is different).

On Tue, Oct 14, 2014 at 11:23 AM, Krisztián Pintér <pinterkr@...il.com>
wrote:

> 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.
>

-- 
Best regards,
Dmitry Khovratovich

Content of type "text/html" skipped