Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 19 Aug 2012 18:56:52 +0200
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: Help-wanted tasks for musl

* Szabolcs Nagy <nsz@...t70.net> [2012-08-19 13:49:14 +0200]:
> * Rich Felker <dalias@...ifal.cx> [2012-08-19 00:26:11 -0400]:
> > Preparing MD5 and SHA crypt for integration
> > 
> > See the threads on the list. Basically we need source with appropriate
> > license status (MIT/BSD/permissive or public domain) that's optimized
> > for size.
> > 
> 
> i'm looking into this
> 
> fun fact:
> the sha based crypt (the modern one designed in 2007,
> but it follows the old weird md5 crypt algo)
> has limits on the rounds but no mention of limits on keys
> 
> http://www.akkadia.org/drepper/SHA-crypt.txt
> 
> eventhough
> 
> step 11. is O(keylen * log(keylen))
> step 14. is O(keylen^2) (!)
> step 16. the reference implementation uses alloca(keylen) (!!)
> step 21. is O(keylen * rounds)
> 

i have preliminary code for md5 and sha crypt
http://port70.net/~nsz/crypt/

but i found other design problems with sha crypt

1) keylen is not limited while the algo is O(keylen^2)
(see above)

2)* according to the spec 'rounds=<N>$' prefix should
be recognized as an iteration specification, but the
reference implementation (and in glibc) accepts empty
or whitespace only N as well, ie.

  '$5$rounds=  $' is treated as '$5$rounds=0$'

3)* reference implementation and glibc accepts negative
rounds in an implementation defined way, ie.

  '$5$rounds=-4294965296$' is treated as
  '$5$rounds=2000$' on a 32bit system and as
  '$5$rounds=999999999$' on a 64bit one

(according to spec N is clamped into 1000...999999999
so the correct treatment would be '$5$rounds=1000$')

4) if the rounds part is not closed by '$' then it is
treated as a salt, but in the output there will be a $
after the salt so it will look like a proper rounds setting,
so output should be treated carefully when the salt has to
be parsed back, ie.

  '$5$rounds=1000' setting will result in an output like
  '$5$rounds=1000$<hash>'

where the salt is 'rounds=1000'

the output can be correctly parsed (based on the $s)
but it's not possible to use the output as a setting
like in the md5 crypt case

i don't know if this is a real issue, but it seems ugly


* the cause of 2) and 3) is that the reference implementation
recognizes rounds=<N>$ if strtoul returns with the end
pointer on a '$'

so strtoul semantics should be assumed for the '<N>$' part

which depends on ULONG_MAX value in case of negative numbers
and may modify errno etc

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.