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  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Fri, 17 Jan 2014 06:50:57 -0500
From: Bill Cox <>
Subject: Re: [PHC] Best RNG for filling memory?

On Thu, Jan 16, 2014 at 1:30 PM, Gary W. Hvizdak
<> wrote:
> On Wednesday 25 Dec 2013 at 1411, Bill Cox wrote . . .
> "Second, I only used the salt to initialize the RNG, hoping that I could
> better protect the password in case the large memory array got cached to
> disk.  I'm not that comfortable having 1GB of MARC4 data out there to be
> analyzed to try and guess the key. ... So, how do I force the entire memory
> to depend on the password without risking some attack on the stream itself?
> ... Or would it be better just to keep the password from impacting what we
> write to DRAM at all, and accept the improved attack?"
> --
> Hi Bill,
> I'm a total newbie and am curious how/why "this" is of greater concern than
> the password itself being swapped to disk?  Is it that only heap space ever
> gets swapped whereas stack/local memory never does?

Hi, Gary.  I'm a password hashing newbie, too.  I added another
parameter called clearPassword, and when it's true, I overwrite the
password with 0's once I've computed the PDKDF2_SHA256 of it.  That
way, at least the plain text password is in memory for a minimum
amount of time.

You are right that everything gets swapped.  Alexander pointed out a
number of problems with clearing passwords, so it's not really as safe
as I would like.  The reference version is likely to fail to actually
clear it, but it will at least make some attempt.

> My current strategy for filling memory (subject to change) is the addition
> of a "seed" parameter to PHC().  Kind of like a "pepper" except that it
> wouldn't necessary need to be secret.  As you point out, an attacker need
> only generate the fill pattern once.  However, if the amount of memory we
> fill is sufficiently large, and well fill it quickly enough, the attacker
> will still suffer some overhead to keep a second pristine copy on hand.
> (I'm assuming memory will be modified as part of the "waking" process.)

If I understand correctly, you fill memory based on a parameter
similar to the salt, which is not secret, but then do password-derived
writes?  Something like that might work OK.

> P.S.  Although my scheme is not yet implemented, my seed parameter will be
> combined with the salt and/or password in some way, to seed the PRNG that
> ultimately fills memory.  This way at least an attacker will have to redo
> the calculation for each password.

I'm currently filling memory based on password, salt, and an optional
session key derived data.  If there's a secret session key,
everything's in great shape.  When there is no session key, or when an
attacker knows it, then an attacker can eliminate much of the time it
takes to do an incorrect password guess.  I consider this the most
serious weakness in all the schemes I've seen so far.


Powered by blists - more mailing lists