For those interested in this, please note that the message below is
part of a discussion that is going on right now and no final decision
or approach has been made. This is something good to be aware of, but
there is nothing to act on and no planned changes yet for the ASF, and
for OFBiz we'll be waiting on a recommendation of action from the ASF.
On a more internal functionality note (as opposed to foundation and
project policy), we might consider doing something for the password
encrypted used within OFBiz. That should probably be done with a new
prefix so that older/shorter SHA strings can still be used, and
actually it shouldn't be too difficult to do (just make sure we
support SHA-2 with a 512 bit digest, and then make it the default).
Has anyone looked into that sort of thing yet?
-David
On May 7, 2009, at 8:22 AM, Jacques Le Roux wrote:
FYI (found on Apache infra ML)
From: "Robert Burrell Donkin" <[email protected]>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
NIST advises [1] that SHA1 should be EOL'd by the end of 2010. Recent
research[2] has revealed vulnerabilities in SHA1.
DSA requires a 160bit hash with SHA1 the most common choice. DSA
has a
1024bit key length. This is considered too short[4] now with 4096
bits
being better but 8192 preferrable. Most digital signatures -
including
many of those which secure the WOT[3] and Apache releases- use SHA1
and
DSA keys.
Debian are preparing to start transitioning away from DSA and SHA1[5]
towards longer keys. IMO Apache should think about how to do the
same.
opinions?
some particular issues for apache:
* we ask for MD5 and SHA1 hashes, both of which now have known
vulnerabilities
* by end of 2010, keys of 1024 bits should no longer be considered
secure and will need to be revoked
* by end of 2010, all WOT links signed using SHA1 should be
considered
insecure (and that's most of them)
* by end of 2010, signatures by 1024 bit keys should no longer be
considered secure and many of the keys that made them will have
been revoked
i've started an issue[6] to track any actions apache needs to take.
this
also has attached the results of a baseline scan i ran against
archive.apache.org.
- - robert
[1] See http://csrc.nist.gov/publications/nistpubs/800-57/SP800-57-Part1.pdf
[2] See
http://eurocrypt2009rump.cr.yp.to/
837a0a8086fa6ca714249409ddfae43d.pdf
[3] Web Of Trust
[4] Applied Cryptography, Long Range Factor Predications
[5] http://www.debian-administration.org/users/dkg/weblog/48
[6] https://issues.apache.org/jira/browse/INFRA-2042
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkoC4BAACgkQQ617goCdfgNiuQCeLgbNoo82v+AFTLp3YD9DbKPD
OX8AoKcto++UaybAtNr4Tt3F+CH5J1iW
=StHh
-----END PGP SIGNATURE-----
