crypt() non-DES support

crypt() non-DES support

[orc]

Will crypt() support more encryption methods in musl? Some applications
expect this. The manpage for crypt(3) says that $id$salt$ is a glibc2
extension. (I've seen stub in src/misc/crypt.c)

Re: crypt() non-DES support

[Rich Felker]

On Fri, Jun 08, 2012 at 05:23:23PM +0800, orc wrote:
> Will crypt() support more encryption methods in musl? Some applications
> expect this. The manpage for crypt(3) says that $id$salt$ is a glibc2
> extension. (I've seen stub in src/misc/crypt.c)

Yes, it's my intent to add a couple popular hashes; the work is
pending getting small implementations of them under appropriate
license (tomcrypt is probably the best source), and doing the
necessary integration. Before doing any work on this, I also want to
completely replace the current DES implementation with one from
tomcrypt; it should be moderately smaller in code size, MUCH smaller
in memory usage, and much faster.

Rich

Re: crypt() non-DES support

[Daniel Cegiełka]

We already have SHA3 finalist:

http://csrc.nist.gov/groups/ST/hash/sha-3/winner_sha-3.html
http://keccak.noekeon.org/
http://keccak.noekeon.org/KeccakReferenceAndOptimized-3.2.zip

Daniel


2012/6/8 Rich Felker <dalias@aerifal.cx>:
> On Fri, Jun 08, 2012 at 05:23:23PM +0800, orc wrote:
>> Will crypt() support more encryption methods in musl? Some applications
>> expect this. The manpage for crypt(3) says that $id$salt$ is a glibc2
>> extension. (I've seen stub in src/misc/crypt.c)
>
> Yes, it's my intent to add a couple popular hashes; the work is
> pending getting small implementations of them under appropriate
> license (tomcrypt is probably the best source), and doing the
> necessary integration. Before doing any work on this, I also want to
> completely replace the current DES implementation with one from
> tomcrypt; it should be moderately smaller in code size, MUCH smaller
> in memory usage, and much faster.
>
> Rich

Re: crypt() non-DES support

[Szabolcs Nagy]

* Daniel Cegie?ka <daniel.cegielka@gmail.com> [2012-10-03 09:16:02 +0200]:
> We already have SHA3 finalist:
> 
> http://csrc.nist.gov/groups/ST/hash/sha-3/winner_sha-3.html
> http://keccak.noekeon.org/
> http://keccak.noekeon.org/KeccakReferenceAndOptimized-3.2.zip
> 

note that crypt is a password based key derivation function
that is supposed to be (configurably) slow, protected against
dictionary attacks and collision resistant (used for password
verification mostly), while sha* is a secure hash that is
supposed to be fast and collision resistant (used for integrity
protection and digital signatures mostly)

Re: crypt() non-DES support

[Gregor Pintar]

2012/10/3, Szabolcs Nagy <nsz@port70.net>:
> * Daniel Cegie?ka <daniel.cegielka@gmail.com> [2012-10-03 09:16:02 +0200]:
>> We already have SHA3 finalist:
>>
>> http://csrc.nist.gov/groups/ST/hash/sha-3/winner_sha-3.html
>> http://keccak.noekeon.org/
>> http://keccak.noekeon.org/KeccakReferenceAndOptimized-3.2.zip
>>
>
> note that crypt is a password based key derivation function
> that is supposed to be (configurably) slow, protected against
> dictionary attacks and collision resistant (used for password
> verification mostly), while sha* is a secure hash that is
> supposed to be fast and collision resistant (used for integrity
> protection and digital signatures mostly)
>

You can increase number of rounds.

Re: crypt() non-DES support

[Szabolcs Nagy]

* Gregor Pintar <grpintar@gmail.com> [2012-10-03 13:56:37 +0200]:
> 2012/10/3, Szabolcs Nagy <nsz@port70.net>:
> > * Daniel Cegie?ka <daniel.cegielka@gmail.com> [2012-10-03 09:16:02 +0200]:
> >> We already have SHA3 finalist:
> >>
> >> http://csrc.nist.gov/groups/ST/hash/sha-3/winner_sha-3.html
> >> http://keccak.noekeon.org/
> >> http://keccak.noekeon.org/KeccakReferenceAndOptimized-3.2.zip
> >>
> >
> > note that crypt is a password based key derivation function
> > that is supposed to be (configurably) slow, protected against
> > dictionary attacks and collision resistant (used for password
> > verification mostly), while sha* is a secure hash that is
> > supposed to be fast and collision resistant (used for integrity
> > protection and digital signatures mostly)
> >
> 
> You can increase number of rounds.

well

the main selling point of keccak is that it
has very simple and efficient hw implementation

which means hw implementation can be a lot
faster than any software implementation
on a generic cpu

this is good for a cryptographic hash, because
you want it to be fast, but it's bad for a passwd
hash, because you want it to have stable run time,
otherwise you cannot set a reasonable iteration
count
(eg for this reason the scrypt passwd hash
was designed so that hw implementation would
use lots of transistors and cannot gain much
performance)

(the nist pbkdf2 often uses hmac-sha hash internally
but it's main application is creating a secure
symmetric encryption key from a simple password,
the stored passwd hash application is more sensitive
to the speed variation of the hash function)

tl;dr: don't use sha3 for passwd hash

Re: crypt() non-DES support

[Solar Designer]

This is offtopic for the musl list, but on topic for the crypt-dev list,
also hosted by Openwall.  Anyhow, I'd rather not spend much time
discussing SHA-3 before having played with it for real.

On Wed, Oct 03, 2012 at 04:01:35PM +0200, Szabolcs Nagy wrote:
> tl;dr: don't use sha3 for passwd hash

At a high level, I fully agree.  If someone simply puts SHA-3 in a loop,
the result won't be great.

But there's more to it: hardware implementations of password hashing are
possible (I mean "defensive" ones), and parallelized implementations of
SHA-3 (multiple inputs/outputs at once) in software might actually be
very fast (so one of them can be used as a primitive for a password
hashing method, just like I was thinking of building a password hashing
method on top of bitslice DES in ~1998 - easily scalable to any SIMD
vector width).

Alexander