Message-ID: <87wpwz8age.fsf@latte.josefsson.org>
Date: Thu, 13 Aug 2015 17:38:57 +0200
From: Simon Josefsson <simon@...efsson.org>
To: Dmitry Khovratovich <khovratovich@...il.com>
Cc: "discussions\@password-hashing.net" <discussions@...sword-hashing.net>,
        Alex Biryukov - UNI <alex.biryukov@....lu>,
        Daniel Dinu <dumitru-daniel.dinu@....lu>
Subject: Re: Argon2 improvement thread

Could you please summarize how the API will look now, or give me a
pointer to where the last/final suggestion was proposed?

Do you intend to reflect the API change in the documentation of the
actual Argon function, or is the API changes discussed purely an
implementation matter for the reference code?  Usually having
consistency (particular in terminology) between implementation and
description helps.

Thanks,
/Simon

Dmitry Khovratovich <khovratovich@...il.com> writes:

> Just for the information: we are now refactoring the code by eliminating
> duplicate code, merging 2d and 2i, integrating new API, fixing the
> endianness issues, adding license information, etc. Any changes in the
> specification will be reported separately. The new code will have BlaMka
> and new indexing function available by default, and the MAXFORM
> transformation available via #define.
>
> Best regards,
> the Argon team.
>
>
>
> On Thu, Aug 13, 2015 at 3:30 PM, Krisztián Pintér <pinterkr@...il.com>
> wrote:
>
>> i proposed earlier to leave any such maintenance task to an outer
>> layer. i'm not even sure it needs standardization at all, especially
>> not within the scope of PHC.
>>
>> in particular:
>>
>> 1, i propose not doing allocation within the hash function at all.
>> memory should be void* parameter to a buffer to use. rationale: there
>> are different ways of allocating memory. on embedded systems, there
>> might be no heap at all, and there might be different kinds of memory
>> (internal, external, etc). only the caller knows how to allocate and
>> then properly clean a memory block.
>>
>> 2, i propose taking the password and the salt in a pre-padded, fixed
>> size block. rationale: it might be not straightforward how to copy the
>> password from a buffer in a manner that does not leak the password
>> length. if the password is hashed, hashing leaks length like nothing
>> else. padding is of utmost importance.
>>
>> 3, there is no need to implement a separate verify interface.
>> rationale: verification is supposed to be a timing-safe comparison,
>> and can be or already is provided by other libs.
>>
>> 4, if the algorithm provides server relief, the interface should
>> reflect to that, and have two parts, pass 1 and pass 2, which are
>> supposed to be chained together when server relief is not used.
>> rationale: usage modes belong to the outer layers, the core should be
>> as simple as possible (but not simpler). there is no need for a
>> function that combines the functionality of other two functions.
>>
>> 5, the result should be a binary of the designed length. no encoding
>> or parameter-prepending is necassary. rationale: it is the task of the
>> outer layers. it might be unnecessary to store the parameters at all,
>> as they might be fixed. an implementor might be short on storage, or
>> must put the hash in 16 bytes space for back-compat.
>>
>> i personally don't care too much about any additional optional
>> interfaces, as long as the core, as explained here, is exposed.
>>
>>
>> On Thu, Aug 13, 2015 at 3:08 PM, Dmitry Khovratovich
>> <khovratovich@...il.com> wrote:
>> > 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...
>>

Download attachment "signature.asc" of type "application/pgp-signature" (473 bytes)

Powered by blists - more mailing lists