Date: Wed, 16 Apr 2014 20:12:27 -0300
From: Marcos Simplicio <mjunior@...c.usp.br>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Re: Lyra2 initial review

OK, I was going home after the last e-mail, but I have to avoid
misunderstandings here: the SSE code is actually Samuel Neves's, so he
is the real mage behind internal optimizations (we are far from being
the most SSE/AVX-savy team in PHC...)

As for Blake2b's internals, we like to think that what we lack in
SSE/AVX expertise we have in cryptography (or at least in the ability to
understand other people's work on cryptography ;-) ). In summary:
sponges need a good permutation function "f" at their core, and our
review of the literature (see section 4.4) showed that Blake2b's
function is a very good example of such functions. Hence, at first sight
it is natural to plug one thing into the other. Then, all we did was to
keep the capacity (the last 256 bits) hidden, which is is essential for
the security proofs of sponges. The reduced number of rounds in the
algorithm's core is actually J. Daemen and V. Rijmen's "Alred" idea with
which we worked in the past. As for the question "is it secure?", as a
crypto-guy I cannot say for sure without independent cryptanalysis, but
this combination of "Sponge + Blake2b's permutation + Alred" does seem
to me as something very promising.

Marcos.

PS.: Blake2b's team is aware of our work and did not complain (at least
yet...) about this construction, so it seems like a nice fit :)



On 16-Apr-14 19:09, Bill Cox wrote:
> On Wed, Apr 16, 2014 at 2:32 PM, Bill Cox <waywardgeek@...il.com> wrote:
> 
>> I think there may be a bug in sse/Sponge.c.  If not, at a comment
>> explaining how this works is in order.  Here's the Blake2b implementation:
>>
>> static inline void blake2bLyraSSE(__m128i *v){
>>     __m128i t0, t1;
>>
>>     ROUND(0);
>>     ROUND(1);
>>     ROUND(2);
>>     ROUND(3);
>>     ROUND(4);
>>     ROUND(5);
>>     ROUND(6);
>>     ROUND(7);
>>     ROUND(8);
>>     ROUND(9);
>>     ROUND(10);
>>     ROUND(11);
>> }
>>
>> Here's the ROUND definition:
>>
>> #define ROUND(r) \
>>   G1(v[0],v[2],v[4],v[6],v[1],v[3],v[5],v[7]); \
>>   G2(v[0],v[2],v[4],v[6],v[1],v[3],v[5],v[7]); \
>>   DIAGONALIZE(v[0],v[2],v[4],v[6],v[1],v[3],v[5],v[7]); \
>>   G1(v[0],v[2],v[4],v[6],v[1],v[3],v[5],v[7]); \
>>   G2(v[0],v[2],v[4],v[6],v[1],v[3],v[5],v[7]); \
>>   UNDIAGONALIZE(v[0],v[2],v[4],v[6],v[1],v[3],v[5],v[7]);
>>     ROUND_LYRA(11);
>> }
>>
>> Macros can be really weird, but it looks to me like ROUND(r) is not a
>> function of r.  This might cause the SSE version to have an insecure PRK.
>>  However, it generates the same hash result as the reference version.  Is
>> this macro really doing a proper Blake2b round, or is this some altered
>> version?
>>
>>
> I dug into this.  It's cool, and shows that the Lyra2 team:
> a) Isn't afraid to muck with the internals of Blake2b
> b) Knows a lot more about Blake2b than me!
> 
> The macro ROUND does not in Lyra2's version depend on r.  This corresponds
> to running Blake2b while compressing all 0's.  When compressing 0's, all
> the Blake2b rounds do the same thing, so you can simplify the code and get
> rid of the r variable.
> 
> I was concerned that squeeze might reveal all the state bits, making it
> simple for an attacker to predict future bits as more are squeezed.
>  Lyra2's sponge has a 1024 bit state, the same that is hashed in rounds of
> Blake2b.  Lyra2 squeezes only 768 bits before applying 12 rounds of
> Blake2b's compression G function with 0's for input.  Thus, an attacker is
> missing 256 bits of the internal state each time, and likely cannot make
> any predictions about what will come out to the sponge next.  I was
> wondering why Lyra2's block size is 96 bytes while Blake2b hashes 128 bytes
> of state in it's rounds.  I think this may be the reason.
> 
> Lyra2's version of Blake2b skips the initialization from IV and two
> variables called f and t.  It also skips compressing the state down to 512
> bits at the end by XORing the upper half onto the lower half.  I assume
> they understand what's going on in Blake2b well enough to make these
> choices confidently.  I'll need to have the rationale explained to me.
> 
> Bill
> 

---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

Powered by blists - more mailing lists