[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAOLP8p5_FJ4V8B_jOcw_N6PwV7gV4n4eOBMRQK1VTkR2+jA1VQ@mail.gmail.com>
Date: Tue, 21 Jul 2015 13:32:18 -0700
From: Bill Cox <waywardgeek@...il.com>
To: "discussions@...sword-hashing.net" <discussions@...sword-hashing.net>
Subject: Re: [PHC] Argon2 improvement thread
On Tue, Jul 21, 2015 at 12:37 PM, Solar Designer <solar@...nwall.com> wrote:
> I also support unifying the two, with a parameter. As to making it
> tri-state (or beyond) rather than binary, I have no strong feelings.
>
I would prefer tri-state. There's not much point confusing users by
allowing them to choose what % of memory to fill in one mode before
switching to the other. 50% of memory is fine, IMO, for the hybrid-state.
If we do standardize 2 APIs, default and extended, then I would have the
default be the hybrid state. I guess I could see a good argument for the
default being equivalent to Argon2d, however, since it would simplify the
implementation in some cases. It's nice to be able to support the default
API with simple code.
What I would not be happy about is having an Scrypt-like solution, where
the memory-filling pass is password independent, and only later passes are
unpredictable. This solution would mean that a hybrid solution would
always have to waste a lot of time rehashing memory, rather than just
filling it in one pass, like we typically do with Argon2d. A Yescrypt-like
solution, where a 1/3-ish second pass were unpredictable with a
cache-timing-resistant filling pass might work out well. I'd hate to have
to run a full second pass in hybrid mode.
Bill
Bill
Content of type "text/html" skipped
Powered by blists - more mailing lists