phc-discussions - Re: [PHC] Argon2 improvement thread

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, 21 Jul 2015 13:06:40 -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:52 PM, Solar Designer <solar@...nwall.com> wrote:

> I propose passing two pointers instead, one "const char *" and the other
> non-const.  If the non-const pointer is not NULL, then this one will be
> used for scrubbing.
>
> Rationale: some reasonable higher-level APIs may already have the const
> (or will have), so we'd have to cast it away for the scrubbing if we
> used the Boolean parameter approach.
>

That would work for me.  It's a bit ugly, but that's the price of backwards
compatibility and simpler integration.

I think we should provide a default API and an extended API.  I would
prefer that the default API take a char *password with scrubbing, but if
that's going to cause issues, then const char *password is OK.  I'll just
always use the extended API instead.  As for other parameters, I think the
PHS interface is close to reasonable for a default API.  I'd drop t_cost,
though.  I've never seen much need for it, and certainly not in the default
API if we can push it into the extended API instead.  I'm OK with
parallelism being only available in an extended API, as well as the
additional secrets and other parameter Argon2 supports now.

Bill

Content of type "text/html" skipped