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: <CAGiyFddSW_GKq3dS9jCNTj=kJQ9JPNZVuumG_ZXVgKHup8MuBg@mail.gmail.com>
Date: Sun, 6 Apr 2014 07:15:53 +0200
From: Jean-Philippe Aumasson <jeanphilippe.aumasson@...il.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Re: Yarn issues

The revised version will be uploaded, sorry.
On Apr 5, 2014 11:40 PM, "Evgeny Kapun" <abacabadabacaba@...il.com> wrote:

> Bill Cox <waywardgeek@...> writes:
>
> > The last PHS submission I read (because of it's position in the
> > alphabet) was Yarn.  He didn't submit his code with the PHS prototype,
> > which annoyed me, because I'm trying to compile it.  There's no
> > Makefile, no main function, indentation by tab (one keystroke) and
> > there's not one freaking comment in his code.  Grr...
>
> I did resubmit with the PHS prototype (before the deadline, of course),
> but for some reason the first version was used rather than the second
> one.
>
> > What are the odds that he messed up on his Blake2b or AES
> > implementations, which seem to be written in his style, so I'm
> > guessing he wrote them from scratch?  I'm not going to take that
> > bet...  I did check his initial key derivation.  I'd say at least
> > 1/3rd of the entries have obvious input collisions, mostly from doing
> > H(password || salt), which allows trivial collisions by moving the
> > boundary between password and salt.
>
> I've checked both AES and Blake2b against known outputs, so they are
> most likely correct.
>
> > If I am not mistaken, he has input collisions on both salt, and a
> > parameter called "pers".  Both are padded with 0's to 8 bytes, and
> > XOR-ed onto Blake2b state, so adding additional 0's up to a total
> > length of 8 doesn't change the output.  The password is free of such
> > collisions, so this isn't a critical issue.  He also has a spelling
> > error on the last line of his README
>
> Blake2b has exactly the same kind of collisions. Even Blake has only
> fixed-width salt.
>
>

Content of type "text/html" skipped

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ