Message-ID: <CAFWeb9J2ygMMsQtbg3vNB-hSxFxbf4tiizPV5eaVA=p+ReSX6g@mail.gmail.com>
Date: Mon, 14 Apr 2014 09:09:44 +0100
From: Alec Muffett <alec.muffett@...il.com>
To: discussions@...sword-hashing.net, Casper Dik <Casper.Dik@...cle.com>, 
	darren.moffat@...cle.com
Subject: Re: [PHC] Do we need a common password hashing API?

Hey Alexander!

Before throwing the baby out with the bathwater I would suggest getting in
touch with Casper and Darren who are still at that company and might be
able to give you some insight into the patent. I left Sun in 2009 when Sun
got bought out, but back then the plan was to make it patented but not
enforced, ie: to stop some bad guy doing the same and blocking out the
Internet community.

Evidence of this would include that the SHA512 process borrows some ideas
from SunMD5 ("rounds=N" in the cipher, etc) because Casper (if I remember
correctly?) participated in that process with RedHat.

 I'll cc: them on this mail. I don't know whether if then reply whether it
would bounce?

    - alec


Darren/Casper: context:

On 13 April 2014 00:53, Bill Cox <waywardgeek@...il.com> wrote:

> Now that I've got all the entries linking with the PHS API, I wonder if it
> would be useful to provide the world with a real one, something they could
> actually use in their applications.  If I were developing an application
> right now that needed to hash passwords, I'd like to future-proof my code
> by linking against an "official" API, which would allow me to select an
> established hashing algorithm now (like Bcrypt, Script, PBKDF2, or HKDF),
> and easily switch in the future, after PHC winners are announced.
>
> Such an API would need some more parameters than the PHS API, such as the
> hashing algorithm (like PBKDF2), a PRF (like SHA256), and a boolean flag
> saying whether it's OK for the algorithm to clear the password.  We might
> also want an additional data field, or maybe even a generic interface that
> would allow users to hash as much data as they like, similar to the
> init/update/final APIs.  Maybe it would be good to have something for
> dealing with salt and settings string generation, similar to what
> Pufferfish has.  The easier we can make life for users, the better.
>


...and further...


On 14 April 2014 08:20, Solar Designer <solar@...nwall.com> wrote:

> Hi Alec,
>
> It's very nice to see you in here!
>
> On Sun, Apr 13, 2014 at 04:53:45PM +0100, Alec Muffett wrote:
> > Some of this was the original intention behind the Solaris Pluggable
> Crypt
> > Framework. [statement of interest: I am a co-author]
> >
> > tl;dr: make it ASCII and let the DLL sort out the details.
> > http://dropsafe.crypticide.com/article/1389
>
> Where's the huge warning that Sun/Oracle has patented this stuff, making
> it unsuitable for the PHC community? ;-(  While there's prior art for most
> or all of it (including my crypt_gensalt() on Owl), I think we should
> stay away from the dynamic linking because of the patent, until it expires.
>
> http://dropsafe.crypticide.com/aboutalecm
>
> "Patents
>
> Method and apparatus for implementing a pluggable password obscuring
> mechanism -
> Inventors: Darren J. Moffat, Casper H. Dik, Alec Muffett."
>
> http://www.google.com/patents/US20050005173
>
> Bill, here's a description of my crypt_gensalt(), etc., introduced into
> Owl slightly earlier than Solaris' use of the same function name (year
> 2000 vs. slightly later):
>
> http://www.openwall.com/crypt/openwall-crypt.3.pdf
>
> Besides the different function prototype and several other differences,
> the major difference is in that my crypt_gensalt() accepts prefix
> (requesting a particular hashing scheme) and iteration count as an
> arguments, whereas Solaris' crypt_gensalt() reads the equivalents of
> these (and possibly more) from a system-wide configuration file.  In
> practice, the iteration count for my crypt_gensalt() is passed via
> pam_tcb's command line found in system configuration files anyway, but
> other uses are possible as well.
>
> So these differ in the kind of flexibility they provide.  In my case,
> it's no dependence of this interface on system-wide configuration.
> In Solaris' case, it's no dependence on there being just these two
> parameters, so it's easier (or rather more consistent) to add m_cost and
> any hashing scheme specific parameters.  These can be added via a
> configuration file with my crypt_gensalt() too, but it becomes
> inconsistent (t_cost is passed to the function, but m_cost, etc. is
> somehow read by the function from files).
>
> Maybe yet another interface is desirable, where crypt_gensalt() would
> accept an arbitrary set of parameters for the hashing scheme, and if
> those are not provided then read them from a configuration file.
>
> As to the name=value encoding in salt strings (which I dislike), I think
> it's orthogonal in this context.  Whether the encoding is verbose and
> human-readable (such as the name=value stuff) or compact and
> machine-focused (such as what I intend to use for yescrypt), there's a
> need for an interface to produce those strings from the individual
> parameter values.  e.g. yescrypt_gensalt() does that, and it accepts a
> yescrypt-specific set of parameters.  This is fine for any particular
> hashing scheme, but for a more generic crypt_gensalt() function the set
> of possible parameters would need to vary by the requested hashing scheme.
>
> Alexander
>



-- 
http://dropsafe.crypticide.com/aboutalecm

Content of type "text/html" skipped

Powered by blists - more mailing lists