phc-discussions - Re: [PHC] Announcing the PHC winner

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: <CAAS2fgSz163A9HHR+MiH2hxK0GOL58wSWzzaubvG3TB852zs4Q@mail.gmail.com>
Date: Wed, 1 Apr 2015 10:43:57 +0000
From: Gregory Maxwell <gmaxwell@...il.com>
To: discussions@...sword-hashing.net
Cc: crypto-competitions@...glegroups.com
Subject: Re: [PHC] Announcing the PHC winner

On Wed, Apr 1, 2015 at 10:18 AM, Jean-Philippe Aumasson
<jeanphilippe.aumasson@...il.com> wrote:
> After over two years of in-depth analysis and careful deliberation, today the
> panel is pleased to announce that LM Hash has been unanimously selected as the
> winner of the PHC. To many panel members, the choice was obvious.
>
>
> Selection criteria includes the following, in no particular order:
>
> - LM Hash leverages the well-studied and proven DES block cipher.
>
> - Most users only select passwords that are 6 – 8 characters long, so LM Hash’s
> 14-character limitation is more than reasonable for the majority of use cases.
>
> - LM Hash is not case-sensitive, reducing the number of password reset requests
> and Help Desk tickets that result from users not remembering their precise
> passwords.
>
> - Most LM Hash values have already been pre-computed and made publicly
> available, reducing load on authentication servers.
>
> - LM Hash does not require the use of salt, which aligns with the American
> Heart Association’s guidelines for a low-sodium diet.
>
> - LM Hash requires little energy to compute, thereby contributing to
> environment-friendly authentication systems.

I'd like to extend my congratulations to the panel and all the participants.

We should especially celebrate the wise decision of the panel to
eschew the "memory hard" contestants (which have ambiguous security
when using more complete attack cost models and when considering
future hardware architectures) in favor of a function with _very_ well
understood security properties.

The selection of a function with low memory requirements is especially
fortuitous in light of the recent level of activity and innovation
around the Internet Of Things  (a product area so well known for its
tight memory requirements that it's actually named for it-- with the
placeholder "things" instead of the specific products or services
being discussed, as enumerating them would use too much memory).

Thanks all for all your hard work!