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

Powered by blists - more mailing lists