Many websites now support HTTPS that may not at the time the code was
committed; let's use the HTTPS links where we can.
Change-Id: I7099dfa0dbb213294e65b4387f343d6e8f955b97
Reviewed-on: https://go-review.googlesource.com/47131
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Supporting larger salts makes it possible to implement bcrypt-pbkdf
(http://www.tedunangst.com/flak/post/bcrypt-pbkdf), which is used in
the latest OpenSSH versions to encrypt key files.
This change makes expandKeyWithSalt (and thus NewSaltedCipher) about
20% slower, but since it isn't used in the "heavy" phase of computation
in bcrypt (it uses ExpandKey, which didn't change), the effect on
bcrypt performance is negligible.
The 16-byte limit was an artifact of optimization and due to the fact
that it was enough for bcrypt; Eksblowfish spec or other
implementations don't limit the salt size.
Additionally, there was a bug in the previous implementation: it only
generated correct results for salts consisting of 4, 8, or 16 bytes, and panicked if salt had zero length.
LGTM=agl
R=golang-codereviews, gobot, agl
CC=golang-codereviews
https://golang.org/cl/102720045
bcrypt didn't allow one, two and three letter passwords which is a
policy decision best left to the user of the code. Some users have
legacy issues which require such short passwords to be processed.
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/81800044
Manual edits to README.
Moved from main Go repository, deleted Makefiles, ran gofix -r go1rename.
Tested with: go test code.google.com/p/go.crypto/...
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/5564059
Kevin Burke
Dmitry Chestnykh
Adam Langley
Russ Cox