phc-discussions - Re: [PHC] Password hashing categories for the wiki?

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] [day] [month] [year] [list]

Date: Sun, 13 Apr 2014 20:12:43 -0400
From: Bill Cox <waywardgeek@...il.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Password hashing categories for the wiki?

On Sun, Apr 13, 2014 at 7:24 PM, Steve Thomas <steve@...tu.com> wrote:

> > On April 12, 2014 at 7:09 PM Bill Cox <waywardgeek@...il.com> wrote:I
> was thinking of doing this while I was going through them.
>

> I came up with similar categories:
> * Script language friendly
> * Dynamic s-box "Bcrypt style"
> * Cache timing resistant "Catena style"
> * Heavy ROM use "PHS for auth servers"
> * Random block access "Scrypt style"
> * Other "Other"
>
> I have not gotten through all of them yet (I fully understand about 1/3 I
> got lazy and skimmed most of the others). So my categories might change.
> This is kind of what I was doing with "strengths" on the wiki.
>

This list sounds very good to me.  I did read all of the entry's papers and
code with roughly equal effort, though that doesn't mean they got equal
treatment.  For example,  Centrifuge kind of blew my mind with AESENC
optimization, and I didn't know what to think of that.  After reading a few
more that use built-in AES instructions, I think I'm more comfortable with
them.  I have in my notes that I need to go back and re-read Centrifuge.
 My initial reaction was not worth much.

> But there is a problem what category do you put algorithms that belong to
> multiple categories? Also should there be a "fixed s-box" for AES or just
> call it s-box. With AES you can put the s-boxes in shared memory on a GPU
> and all threads use it. You just have a bunch of bank conflicts. Instead of
> running out of shared memory and only using a few threads or using main
> memory which is probably overall slower.
>

I worried about issues similar to this problem, and then realised that it's
not the PHC's problem to worry about categorizing each algorithms.  It is
simply their job to create the functional categories.  You and I came up
with similar categories, so I think this is doable.  Yes, some of the
algorithms are difficult to categorize, and may span multiple categories.

> What I'm considering is, ordering the categories such that the first one an
> algorithm meets that's the category it is. Note I already ordered them the
> way I would consider them. Maybe we just list each algorithm in all of it's
> categories. Then take the best from each category and compare the best from
> each. I say this but I just realized this helps mine since it's in multiple
> categories. So we should probably not. Also what if an algorithm is strong
> in multiple categories but best in none. Oh wait that might also help mine.
>

I think we'll call you on favoritism that helps your own algorithm.  At
least, I promise I have no problem doing that.  I appreciate your stating
what you think might be favoritism.  I'll try to do the same, and please
call me on it when I don't.

I put algorithms into the what I consider their "main" categories.  After
doing this, and then picking my favorites listed in each, I found that I
did not see any algorithms from one category that would win over the best
entry in another category.  This obviously depends on the algorithms, but
we have them all now, and I feel this is the case for what we have.

Bill

Content of type "text/html" skipped