On Thu, Feb 27, 2014 at 11:19:23AM +0100, Marco d'Itri wrote: > On Feb 27, Yves-Alexis Perez <cor...@debian.org> wrote: > > > > Because unless you are paranoid, then it is not. > > > If anybody disagrees then please describe a credible threat model in > > > which: > > > - an entity would want to have access to the key of a DD, and > > > - would find brute forcing a 1024 bit key more practical than > > > stealing it or coercing a developer to disclose it. > > > > There's also the hash algorithm issue, which could lead to signature > > collision attacks (wether in data signing or in key signing). > Please describe a credible threat model, etc. > "Theoretically possible" also means that somebody could factor a RSA > 4096 key at the first try with pen and paper so it does not matter much.
I'm not concerned about the hash algorithm myself. As I understand it, it's a preimage attack. MD5 is "broken" for that in that it can be done in 2^123 instead of 2^128, and so should still be fine. SHA1 is still at 2^160, and so such clearly not a problem. SHA1 on the other hand is at 2^60 for a collision attack. That is, someone could generate 2 keys with the same fingerprint in a reasonable time, but can not generate a key with the same fingerprint as an existing key. The current cost estimate for such a collision attack is around 1M USD. See: https://www.schneier.com/blog/archives/2012/10/when_will_we_se.html MD5 is currently completly useless if collision resistance is important, it's around 2^18, and in the other of seconds. But as far as I know, for most cases we don't care about collision resistance, but do care about the preimage resistance. As long as you're not singing something that an attacker has control over MD5 and SHA1 should still be safe. If an attacker does have control over it, SHA-2 would be safe instead. Kurt -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140227192851.ga30...@roeckx.be
