[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120819165652.GE16602@port70.net>
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.
