Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 8 Jul 2015 15:39:57 +0300
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: PHC: yescrypt questions

On Wed, Jul 08, 2015 at 01:47:17AM +0200, Agnieszka Bielec wrote:
> 2015-07-06 23:15 GMT+02:00 Solar Designer <solar@...nwall.com>:
> > On Mon, Jul 06, 2015 at 08:09:13PM +0200, Agnieszka Bielec wrote:
> >> and my task is to add to john only PHS?
> >
> > The interface for you to use is yescrypt_r().
> 
> and should I do also ROM support

Yes, but as a separate task - e.g., integrate basic yescrypt support one
week, and add ROM support the next week.

> and add to salt if hashing function have to use ROM?

I've been thinking of this before you asked, and I'm still not sure.

In practice, authentication servers could want to record a ROM size id
along with each hash in order to allow for ROM size upgrades (which
could then be performed every few years, along with physical servers'
RAM upgrades).  There appears to be less of a need to record what exact
ROM was used to compute a given hash.  While we could record the "param"
to yescrypt_init_shared() right there, and the ROM would still serve its
primary purpose well, this would defeat possible uses of "param" as an
extra secret that might not leak along with the hashes.  As an option, I
was thinking of recording a fast one-way hash of "param" in there
(assuming that "param" is high entropy), as a ROM id, but on its own
this wouldn't help you all that much (you still need to have a "database
of ROMs" elsewhere), and it adds an attack vector for some use cases (if
"param" is being used as an extra secret, but its entropy isn't high).

So maybe we need an optional password cracking specific encoding for
yescrypt hashes, where the ROM would be explicitly referenced.  In fact,
there may be two ways to reference it: by filename (which your code
would need to mmap(), much like userom.c can) and by "param" (in which
case you'd initialize that ROM with yescrypt_init_shared() at startup).

Alexander

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ