[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKGDhHVoWRKu8-2M9YoYJyGBy6DBbu7sxCKHezFmfWaoOoOojw@mail.gmail.com>
Date: Fri, 14 Aug 2015 23:57:19 +0200
From: Agnieszka Bielec <bielecagnieszka8@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: PHC: makwa
2015-08-14 15:13 GMT+02:00 Solar Designer <solar@...nwall.com>:
> On Thu, Aug 13, 2015 at 09:48:32PM +0200, Lukas Odzioba wrote:
>> 2015-08-13 21:42 GMT+02:00 Agnieszka Bielec <bielecagnieszka8@...il.com>:
>> > I implemented basic version of makwa on CPU (although this is a messy
>> > version so far)
>> > and have questions
>> > PHS calls makwa_hash with pre_hash=1, should I also support pre_hash=0
>> > and support both sha256 and 512 ? in PHS is makwa_init() with
>> > hard-coded parameters, support also another parameters?
>>
>> To make it complete I guess we should support all cases, solar please
>> correct me if I am wrong.
>> The question is whether it is feasible to make 2 versions for each sha
>> function or to "multiplex" them in one format selected by hash
>> encoding. Personally I would go or the latter.
>
> Yes, it should be one format. I think Makwa's use of SHA-256 or -512
> isn't performance-critical, so it shouldn't significantly affect
> benchmarks.
what to do with static const unsigned char PHC_PUB2048[] = { which is
hard-coded, also add it to the salt?
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
