mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Szabolcs Nagy <nsz@port70.net>
To: musl@lists.openwall.com
Subject: Re: Help-wanted tasks for musl
Date: Sun, 19 Aug 2012 18:56:52 +0200	[thread overview]
Message-ID: <20120819165652.GE16602@port70.net> (raw)
In-Reply-To: <20120819114914.GD16602@port70.net>

* Szabolcs Nagy <nsz@port70.net> [2012-08-19 13:49:14 +0200]:
> * Rich Felker <dalias@aerifal.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



  reply	other threads:[~2012-08-19 16:56 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-19  4:26 Rich Felker
2012-08-19  8:10 ` idunham
2012-08-19 16:18   ` William Haddon
2012-08-19  8:44 ` boris brezillon
2012-08-19 11:49 ` Szabolcs Nagy
2012-08-19 16:56   ` Szabolcs Nagy [this message]
2012-08-19 17:29     ` Szabolcs Nagy
2012-08-20  0:51       ` Rich Felker
2012-08-20  1:35         ` Szabolcs Nagy
2012-08-20  1:39           ` Rich Felker
2012-08-20  1:58             ` Szabolcs Nagy
2012-08-20  2:12               ` Rich Felker
2012-08-28 20:09                 ` Szabolcs Nagy
2012-08-28 23:35                   ` Szabolcs Nagy
2012-08-29  0:15                     ` Szabolcs Nagy
2012-08-29 14:30                     ` Rich Felker
2012-08-29 15:14                       ` Szabolcs Nagy
2012-08-29 17:01                         ` Rich Felker
2012-08-30  8:40                           ` Szabolcs Nagy
2012-08-19 21:46 idunham
2012-08-19 22:19 ` Gregor Richards

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120819165652.GE16602@port70.net \
    --to=nsz@port70.net \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).