(By the way, how did the topic - gpg.conf: settings for security and compatibility ever get confused with the topic - Setpref is not working or is it a bug or something? because this definitely is the former but is called the latter. Also, @g, as you apparently call yourself, you seem to start a new thread with each post, could you try to get your e-mail client to properly thread?)
On 26/11/14 14:31, Werner Koch wrote: >> digest-algo SHA256 > > May break compatibility because it overrides the preference system. > >> personal-cipher-preferences AES256 TWOFISH AES192 AES CAST5 >> personal-digest-preferences SHA512 SHA384 SHA256 SHA224 >> personal-compress-preferences ZLIB BZIP2 ZIP Wouldn't personal-digest-preferences be completely redundant when you also specify digest-algo? It's going to force usage of SHA-256 anyway. Now about SHA-1 for signatures on data (/not/ certifications). As long as you sign only things you produced yourself, one would generally need a preimage attack on SHA-1 to fake your signature. There are currently no practical preimage attacks on SHA-1. The attacks on SHA-1 that are the buzz these days are collision attacks. But this is *only* a risk if the attacker can get you to sign a document the attacker created! If you are in the habit of signing binary documents (say, a Microsoft Word file or an OpenDocument file), then it might in the future become possible to involve you in a chosen-prefix collision attack and fake your signature. That is because there is more in such a file than meets the eye. You think you sign what meets the eye, you don't see the cruft appendage in that file that was cleverly included to create a chosen-prefix collision. This is what it would look like: Company Alice gives the contract for job X to company Bob, Inc. erfhwGqid389547854ddssdwiAQWQuibidfvsdf However, you wouldn't see that last bit because it is included in such a way into the file that it doesn't appear on your screen. Still, it is part of what you sign. The cruft at the end has the purpose to create a hash collision, and the whole document hashes to b843e5fb9ccef0091fa3e65d2ff349fcb46a6061, which is what you sign. Now, the attacker has created a second message in tandem, which reads: Company Alice gives the contract for job X to company Mallory. erfuihrhiwefbwu2347847834sdvbsduBHUIuygvuiUIHUI323432 They created this in tandem with his first message, and the cruft at the end is chosen carefully such that this again hashes to b843e5fb9ccef0091fa3e65d2ff349fcb46a6061.[1] And again, the cruft at the end is hidden in the file and doesn't show when you view the document. Now they can copy your signature, because you signed that hash. In practice, there are still several problems, such as the time of the signature being part of the hash and thus not fully under attacker control. It's just a rough sketch of the problem to give you a feeling for it. The message behind it is: unless an attacker can get you to sign something the attacker produced, you don't have to worry about collision attacks. If you use the same key for certifications and data signatures, then I think a certification is in the category "sign something the attacker produced", though. Has something like randomized hashing[2] been considered by the OpenPGP standardization people? Peter. [1] no, it doesn't, I can't do SHA-1 collisions, I'm sorry :) [2] for example http://webee.technion.ac.il/~hugo/rhash/ -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at <http://digitalbrains.com/2012/openpgp-key-peter> _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
