Hi,
It does not incorporate the SuSE bcrypt implementation as requested by
"Ed W." because I feel that the implementation is incorrect (it is not really
compatible with the actual bcrypt ($2$ scheme, instead it is $2a$ scheme),
and the OpenBSD/NetBSD/FreeBSD implementations were licensed under terms
which required attribution in printed materials (e.g. Four-clause BSD
license). It is possible to implement bcrypt, but I feel the best approach
would be to write a new implementation from scratch that covered both variants
of bcrypt. So I didn't implement it, sorry.
I can't comment on the licence terms right now, but I think you might
misunderstand the history of the bcrypt implementations:
$2$ is legacy and went away around 1997
$2a$ was current until around the end of 2011 when a significant flaw
was found. Post 2011 it's now ambiguous...
$2x$ is the same as pre 2011 bcrypt where the bug is still definitely
present. Only useful for legacy hashes to show that they were generated
with the old algorithm (ie mark them as such, but once upgraded generate
new with the new algorithm)
$2y$ is the current algorithm going forward
I was under the impression the code I supplied implemented all of the
above with the exception of $2$, but I concede I'm scribbling this
history without now rechecking...
To repeat the motivation: Lots of web libraries use bcrypt (rightly or
wrongly). Adding $2y$ to the libc allows an interesting bunch of
applications to automatically acquire bcrypt password checking
functionality and suddenly a large bunch of web application users
suddenly are encouraged to code password storage more securely... Surely
the SHA variant will quickly become popular, but right now we have a
general trend to do nothing, so I think it would be great to try and
match web apps with libc as of "right now"
Cheers
Ed W
_______________________________________________
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
