[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <379800991.158174.1397431495111.open-xchange@email.1and1.com>
Date: Sun, 13 Apr 2014 18:24:55 -0500 (CDT)
From: Steve Thomas <steve@...tu.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Password hashing categories for the wiki?
> On April 12, 2014 at 7:09 PM Bill Cox <waywardgeek@...il.com> wrote:
>
> I wonder if it would be useful to describe the various categories that the
>PHC is interested in on the wiki. The functional categories I think I see,
>based on the entries, are:
>
> 1) Bcrypt style cache-bound hashing with unpredictable addressing, and good
>GPU defense
> 2) Catena style cache-bound hashing with solid timing attack resistance
> 3) Scrypt style large memory algorithms with strategies for reducing
>cache-miss penalties
> 4) Password hashing schemes for authentication servers
> 5) Other (and this is a very cool category!)
>
> Some entries focus on one category, such as EARWORM and authentication
>servers, or Catena and cache-bound timing attack resistance. Others span
>multiple categories, such as Yescrypt. Makwa and PolyPassHash are very cool
>"other" entries.
>
> Would it be useful to break out the different functional categories on the
>wiki, and list entries competing in those categories?
>
> Bill
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.
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.
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.
----
Disclosure: I submitted battcrypt and Parallel.
Powered by blists - more mailing lists