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]

Message-ID: <CALW8-7LhZ+ryRkqJgQT=QzuCcaqZ5jFJixmOtpgT0iKAj=xgQw@mail.gmail.com>
Date: Thu, 13 Aug 2015 15:08:03 +0200
From: Dmitry Khovratovich <khovratovich@...il.com>
To: "discussions@...sword-hashing.net" <discussions@...sword-hashing.net>
Subject: Re: [PHC] Argon2 improvement thread

I would rather enable scrubbing in the extended API to simplify the default
one. The extended API can then have a boolean flag to clean all the inputs
immediately after they are used.

Maybe there are other opinions on that? So far only a few people
participated the API discussion...

Dmitry

On Tue, Jul 21, 2015 at 10:06 PM, Bill Cox <waywardgeek@...il.com> wrote:

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



-- 
Best regards,
Dmitry Khovratovich

Content of type "text/html" skipped