Re: RNG: is it possible to spoil /dev/random by seeding it from (evil) TRNGs (was: howto secure older keys after the recent attacks)
I consulted a non-list-reading colleague who knows rather a lot about randomness. He writes: here's my reply; i dunno whether it counts as an example of evil per se: the bigger problem with manufactured entropy sources is that rigorous unit testing at the factory usually is just impossible. it just takes too long to gather a few hours of bits from every unit, then do the exhaustive statistical testing, again for every unit. indeed, it seems likely to me that when a CPU vendor sells CPU chips with integrated TRNG circuits, some of the chips will surely come off the fabrication line with defective TRNGs, just as some CPU chips get made with defective ALUs, memory, etc. the bad logic circuits get caught by exhaustive pre-ship testing, and those chips don't get sold. but given that rigorous testing of the TRNG circuit is so expensive, it's my guess that the CPU vendor surely must just unwittingly ship the CPUs that happen to have obscurely bad TRNGs. --dan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: RNG: is it possible to spoil /dev/random by seeding it from (evil) TRNGs (was: howto secure older keys after the recent attacks)
On Oct 8, 2012, at 6:20 PM, Christoph Anton Mitterer christoph.anton.mitte...@physik.uni-muenchen.de wrote: Hi David. Long time ago, the following[0] ;) I recently stumbled across that question again,... when I deployed haveged on our faculty's HPC cluster... So I've asked[1] around at lkml, whether a malicious (or just bad) entropy source could spoil the kernel's RNG. Ted Ts'o, who currently maintains that part said (see the thread) he wouldn't know any way how that could be done, but... On Thu, 2009-09-10 at 22:35 -0400, David Shaw wrote: 3) One problem with such devices is,.. that one can never know (well at least normal folks like me) how good they actually are. If this company would be evil (subsidiary of NSA or so) they could just sell bad devices that produce poor entropy thus rendering our (symmetric and asymmetric) keys, signatures etc. useless. Right? Not completely useless given the Linux random design, but certainly an evil source of entropy would be a serious problem. Do you have any reason to believe this device is evil? There are many random number generators on the market. Knowing which ones are evil would be handy ;) ... your reply seems to somehow imply that it could... So he (and I) wondered for the reasons :) The message is from three years ago, so I'm honestly not sure where I was going with that thought at the time. Most likely, I was thinking about someone using an evil device for entropy directly rather than through a /dev/random that deals with the evil source case. To be clear: I do not know of some way an evil input can somehow subvert the output of /dev/random on Linux. My understanding was that it was designed to prevent that. David ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
RNG: is it possible to spoil /dev/random by seeding it from (evil) TRNGs (was: howto secure older keys after the recent attacks)
Hi David. Long time ago, the following[0] ;) I recently stumbled across that question again,... when I deployed haveged on our faculty's HPC cluster... So I've asked[1] around at lkml, whether a malicious (or just bad) entropy source could spoil the kernel's RNG. Ted Ts'o, who currently maintains that part said (see the thread) he wouldn't know any way how that could be done, but... On Thu, 2009-09-10 at 22:35 -0400, David Shaw wrote: 3) One problem with such devices is,.. that one can never know (well at least normal folks like me) how good they actually are. If this company would be evil (subsidiary of NSA or so) they could just sell bad devices that produce poor entropy thus rendering our (symmetric and asymmetric) keys, signatures etc. useless. Right? Not completely useless given the Linux random design, but certainly an evil source of entropy would be a serious problem. Do you have any reason to believe this device is evil? There are many random number generators on the market. Knowing which ones are evil would be handy ;) ... your reply seems to somehow imply that it could... So he (and I) wondered for the reasons :) Thanks a lot, Chris. [0] http://lists.gnupg.org/pipermail/gnupg-users/2009-September/037301.html [1] http://lkml.org/lkml/2012/10/4/210 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: howto secure older keys after the recent attacks
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 David Shaw wrote: There are occasional debates on who has the better PRNG. The debates usually end with no changes on either side :) That isn't to say there aren't differences between systems - the FreeBSD PRNG (which seems to have been inherited by OSX) is of a fairly different construction than the Linux one, which has led to some mild controversy in the past. Notably, the Linux one blocks if you run out of gathered entropy, and the FreeBSD one does not. FreeBSD /dev/random is similar to Linux's /dev/urandom. That description is not quite accurate. FreeBSD (and OSX, which actually inherited quite a bit of userland and other bits from FreeBSD) uses the Yarrow PRNG. Here is an excerpt from the wikipedia /dev/random article: Yarrow places a lot of emphasis on avoiding any pool compromise and on recovering from it as quickly as possible. It is regularly reseeded; on a system with small amount of network and disk activity, this is done after fraction of a second. http://en.wikipedia.org/wiki//dev/random So while it is correct to say that like a traditional SysV /dev/urandom our /dev/random does not block (except in extraordinary circumstances, unlikely to happen in any real world application), it is not correct to say that it continues handing out bits of dubious quality when it runs out of entropy. (I realize that is not specifically what you said David, but since at least one reader seems to have come to that conclusion based on what you did say so I felt compelled to respond.) As the wikipedia article also points out we have support for hardware entropy devices as well so anyone doing heavy duty crypto stuff has that option available. But for the casual user our current system is more than enough. And yes, I realize that this is an area of debate, which is why I purposely included your first quote above in my reply. :) My purpose is not to debate which is better, rather to bring some light to the topic of what we're actually doing. Anyone interested in more details about Yarrow can read the paper at http://www.schneier.com/paper-yarrow.html. hth, Doug (aka do...@freebsd.org) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.13 (FreeBSD) iEYEAREDAAYFAkq5KD0ACgkQyIakK9Wy8Pv8dwCeMbTkNlTvaK2Npz7acx3zlzCW pxEAoMaj4NhMmoX9xu5c9d4MThuVjTT8 =MsTX -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: howto secure older keys after the recent attacks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 David Shaw escribió: ... So my question is basically,.. If gpg would use this,... does it only improve the already existing entropy and randomness of the kernel PRNG? I mean that gpg somehow merges the different sources? Or is it more or less a,.. either use the kernel PRNG or the hardware RNG. The kernel merges several sources of entropy into the /dev/random pool. The entropy key would just be another source (though a very prolific source) of entropy. I remember an example from one of the Bruce Schneier book, where 2 people (Alice and Bob, of course) wanted to get a random bit. They thought about each one flipping a coin, and then mixing the results. And Bob said what if one of us don't do it randomly, and Alice said as long as one of the results was truly random, the final result would be random. So I suppose as long as the entropy generator output is mixed with other sources of entropy, it can't lower the quality of the final entropy. But of course, maybe I didn't understand it right. Best Regards -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJKrFK7AAoJEMV4f6PvczxAk6cIAKfa64/reW57fOGrHcAxapEI eOdCLI8MDvUVPVb5+dVVJL6WQXy6jbDAikkjbJuT8sSNaUpK8nkvPccVuI3mNVkg 8PExrLS2fnXqk3HtVWcXRd/TxoQNL454SZ9EXsjaRwqZvijDqpuwuwDmfg4EvWhY SYgzJCboRTnbJhzpaAt+z23IrdSLKdV5EvRtK6RPwjQkvu84Y+EJKiT8qdf11hQe sIzQQoi79k+sBuq8xn+JDRcSFbfjSIdU7erXDK9F2UchB9j7OXAtdqv3ChQN6Med LXfmuqfd+GUeuFYYaBMgKj5S5IFsTiBc3mitcj1ulstPy2MlRHI/KTX9h9R1OMI= =90/F -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: howto secure older keys after the recent attacks
Faramir wrote: I remember an example from one of the Bruce Schneier book, where 2 people (Alice and Bob, of course) wanted to get a random bit. They thought about each one flipping a coin, and then mixing the results. [puts on his voting security hat] This is part of some voting protocols. Let's say you have two candidates who tie in an election. Each candidate sends their own representative to the election with a ten-sided die (you can find these in any hobby store). The election commissioner collects the dice, then distributes them out randomly to the representatives. Everyone throws the dice and the numbers are added up together modulo 10. If it comes up 0 through 4, candidate A wins the election; if it comes up 5 through 9, candidate B wins the election. Thanks to the magic of random distributions and modulo math, as long as there's one fair die in the system, the entire system is fair. Anyway. This is apropos of nothing except to show you that such schemes really are used in the real world. :) ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: howto secure older keys after the recent attacks
Faramir wrote: I remember an example from one of the Bruce Schneier book, where 2 people (Alice and Bob, of course) wanted to get a random bit. They thought about each one flipping a coin, and then mixing the results. [puts on his voting security hat] This is part of some voting protocols. Let's say you have two candidates who tie in an election. Each candidate sends their own representative to the election with a ten-sided die (you can find these in any hobby store). The election commissioner collects the dice, then distributes them out randomly to the representatives. Everyone throws the dice and the numbers are added up together modulo 10. If it comes up 0 through 4, candidate A wins the election; if it comes up 5 through 9, candidate B wins the election. Thanks to the magic of random distributions and modulo math, as long as there's one fair die in the system, the entire system is fair. Anyway. This is apropos of nothing except to show you that such schemes really are used in the real world. :) ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: howto secure older keys after the recent attacks
On Thu, 2009-09-10 at 22:35 -0400, David Shaw wrote: Yes. It's not that gpg has a driver for it though. The developers of the entropy key were clever and instead of making programs write new code to use the key, they made a program that reads the key and feeds the Linux entropy pool. Thus, anything that uses /dev/random (like gpg) benefits without code changes. Nice nice :) Apart from that,.. I've just read that they support even having more of those devices added,.. for an even higher entropy bandwidth :D Not completely useless given the Linux random design, but certainly an evil source of entropy would be a serious problem. Do you have any reason to believe this device is evil? _Not at all_ ... But the problem is,.. how could I know? Nor would I have the technical knowledge to verify their implementation,.. nor the elecetron microscope that I'd probably need for the verification. There are many random number generators on the market. Knowing which ones are evil would be handy ;) Well,.. as soon as I got a list,.. I promise that I'll tell you ... EXCEPT... I'm already detained in Guantanamo, Diego Garcia,.. or something like this ... for knowing that list ;) But in this case we might probably meet anyway,.. as _all_ people I've ever had contact to,.. will be detained, too ;) So my question is basically,.. If gpg would use this,... does it only improve the already existing entropy and randomness of the kernel PRNG? I mean that gpg somehow merges the different sources? Or is it more or less a,.. either use the kernel PRNG or the hardware RNG. The kernel merges several sources of entropy into the /dev/random pool. The entropy key would just be another source (though a very prolific source) of entropy. So this basically means: Use such devices (as much as possible), they practically can only improve security, but not weaken? Grüße, Chris. smime.p7s Description: S/MIME cryptographic signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: howto secure older keys after the recent attacks
On Thu, 2009-09-10 at 22:52 -0400, David Shaw wrote: I suspect you are more in danger of being hit by meteors several times in a row as you walk to your friend's house with the USB stick, than you are in danger from SHA-1. I was watching Armageddon yesterday evening... so watch out what you're saying ;P (and never forget you anti-meteor-shower-umbrella) Chris. smime.p7s Description: S/MIME cryptographic signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: howto secure older keys after the recent attacks
On Thu, 2009-09-10 at 20:38 -0400, Daniel Kahn Gillmor wrote: Worse than this: the devices could produce measurably good entropy that happens to be predictable to a malicious individual in control of a special secret. For example, if such a key were to contain a copy of the secret, and somehow retain the current time (e.g. a battery and a clock?), it could produce a new output stream each second with: AES(secret + time()) (first cleartext block is just secret + time, and next cleartext block for that second is just the previous ciphertext block XOR'ed with secret + time -- reset every second as time() changes) This would produce a predictable stream that (like all good ciphers) has high-entropy output. Then, if this was used to provide random numbers to the kernel, which in turn provided them to gpg, an attacker who knows the secret associated with your entropy key, and the time you generated the key (that information is published with your public key) could probably reproduce the stream of randomness that was used for your key generation, and therefore stumble upon your private key. Ok,... now you've made me unsecure :-/ (on whether to use such a thingy - ok I've already ordered one ^^ - or not) Chris. smime.p7s Description: S/MIME cryptographic signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: howto secure older keys after the recent attacks
On Thu, 2009-09-10 at 22:23 -0400, David Shaw wrote: Sure, but your computer vendor could have a relationship with the NSA and put some special code in the BIOS to capture keyboard input and periodically send it to a central server. Your disk drive vendor could keep a few extra sectors hidden from the reallocation pool, and use them to store copies of things that match the byte signature of a PGP key. Your wifi AP vendor could have a hidden secret WPA key that makes your home network available to a malicious individual in control of the special secret. This is exactly what keeps me awake at nights ;P Chris. smime.p7s Description: S/MIME cryptographic signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: howto secure older keys after the recent attacks
On Thu, 2009-09-10 at 22:55 -0400, Daniel Kahn Gillmor wrote: There is also open hardware for random number generation, for whatever that's worth: http://warmcat.com/_wp/whirlygig-rng/ I think David already pointed me to this one some time ago,.. but they're not yet selling it, right? Chris. smime.p7s Description: S/MIME cryptographic signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: howto secure older keys after the recent attacks
On Thu, 2009-09-10 at 22:46 -0400, David Shaw wrote: The place for all such suggestions is the IETF OpenPGP working group: http://www.imc.org/ietf-openpgp/ Yeah I know,.. and if you remember, most of what I've mentioned before was already discussed at that list... but with no very big support ;) So either these ideas were not improving strictness, security or functionality (as with the additional attributes)... or people are just to scared to break existing things or do not want to put a too high burden on the implementations. Anyway,.. don't believe that much (if any) of the above would be added in (near) future releases,.. and I don't wanna start the same discussions again ;) Best wishes, Chris. smime.p7s Description: S/MIME cryptographic signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: howto secure older keys after the recent attacks
Hi Robert. On Thu, Sep 10, 2009 at 3:05 AM, Robert J. Hansen r...@sixdemonbag.org wrote: Add these lines to your gpg.conf file: personal-digest-preferences SHA256 SHA224 SHA384 SHA512 RIPEMD160 personal-cipher-preferences AES128 3DES [...] And you think this is enough? Not removing and recreating and older signatures that use SHA1? Thanks, Philippe. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: howto secure older keys after the recent attacks
On Thu, Sep 10, 2009 at 3:45 AM, David Shaw ds...@jabberwocky.com wrote: Yes, but it won't actually go away completely. SHA1 is special in OpenPGP. Unlike the other hashes, SHA1 is required to be supported. Removing SHA1 from an OpenPGP preference list doesn't actually remove it, but instead effectively puts it at the end of the list (so it is the lowest ranked choice). Uhm,.. what a pity. What would happen if SHA1 gets fully broken? Would we have to create a new OpenPGP and new keys? -But I'd also like to have the signatures themselves using e.g. SHA256 or SHA512,... but they're alread using SHA1 Can this be changed? Or can I simply add new self signatures? Yes Does this work via --cert-digest-algo option? If so what must I do to get gpg to: - resign my own key - resign other keys Is it simply with the sign command, or will it complain that there's already a signture there? So does this mean any harm to me? At some day SHA1 might be fully broken, and then an attacker could use simply these older self signatures instead of the newer ones, or not? Well, yes and no. Old signatures are certainly available to both friend and foe, but the real question is: use them for what? What attack are you concerned about here? Well.. not sure... I've heard that one can add many settings to these signatures like rovcations or policies. But I have not enough knowledge on them (although I could imagine that someone could probably use them to do evil things which might be impossible with a newer hash-algo). But perhaps it could be used to do some forgery with User IDs? To change the hash you sign with, stick this in your gpg.conf file: personal-digest-preferences sha256 Oh,.. so what is this --cert-digest-algo then good for? Another thing I've read about is, that gpg keys are using SHA1 hard coded in some places with no way to use another algortihm... which places are these so one could avoid them perhaps? You pretty much can't. The key ID itself is derived from SHA1. I thought the key ID is only used for humans to short check the keys,.. but not in the system itself?! So this would basically mean, once SHA1 is broken, we're totally screwed?! There was a very long discussion of the SHA1 issue a few months back on this list. See, for example, http://lists.gnupg.org/pipermail/gnupg-users/2009-May/036338.html and http://lists.gnupg.org/pipermail/gnupg-devel/2009-May/024999.html In short, I wouldn't worry all that much about it. At least at the moment you mean? I mean we had the same thing with MD4, MD5 and so on,... so probably it will hit us with SHA1, too? With regards to AES256, I doubly wouldn't worry about it. See http://lists.gnupg.org/pipermail/gnupg-users/2009-August/037107.html This sort of question tends to cause long threads where everyone throws in their own cipher preferences. Instead of giving my preferences, allow me to point at the wonderful defaults in GPG. They're the default algorithms for a reason. Ok,.. thanks for that information :) I'd have some additional poor men's questions ;-)... - When creating a new key,.. it uses the entropy, right? So is there some way to improve this entropy? Perhaps not using Linux but instead OpenBSD which might have a better PRNG (don't know if this is actually the case ;) ) or use a specific Linux kernel version where a newer and better PRNG was added? -Currently the default (and I assume suggested) algorithm is RSA, right? How does DSA2 compare with it? I once read, that RSA would provide a hash algorithm armor which the DSA's wouldn't have. Is this still true? -My course's professor showed us some number from NIST (don't recall the exact ones, though) where they suggested about something like this: 15360 (or so) bits for the asymetric key - 512 bits for the hash size - 256 symmetric key should lead to about the same strenght... So we have 512/256 bits for the later two,.. but per default much less for the asymmetric... Does this mean, that the other two are overkill for what we use in gpg? - When creating new keys (I'd like to convince some more friends to take part :) )... should they create their keys with gpg1 or gpg2? Or is the key generation equally secure? Best wishes, Philippe. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: howto secure older keys after the recent attacks
- When creating a new key,.. it uses the entropy, right? So is there some way to improve this entropy? Perhaps not using Linux but instead OpenBSD which might have a better PRNG (don't know if this is actually the case ;) ) or use a specific Linux kernel version where a newer and better PRNG was added? Not really. If there were good reasons to believe OpenBSD's entropy collector was better than Linux's, the Linux crew would fix the code, maybe even borrowing OpenBSD's entropy collector. -Currently the default (and I assume suggested) algorithm is RSA, right? How does DSA2 compare with it? Arguing whether RSA or DSA2 is better is kind of like arguing whether King Kong or Godzilla is better at stomping cities flat. I once read, that RSA would provide a hash algorithm armor which the DSA's wouldn't have. Is this still true? Yes. No. Not really. Kind of. RSA gives you a lot of freedom, yes. You could put SHA512 on an RSA-3 (as in three bits of key) signature and it won't bat an eyelash. It's _stupid_, but it won't bat an eyelash. So, sure. RSA gives you more freedom with hashes than DSA2, but that's not necessarily a good thing. should lead to about the same strenght... Beware of those numbers. I don't know anyone who takes them seriously. They are conjecture and speculation. Educated conjecture and speculation, sure: some of the brightest minds out there worked on the conjecture and speculation -- but they're still conjecture and speculation. That said, there's nothing wrong with using those numbers as long as you remember that they're conjecture. So we have 512/256 bits for the later two,.. but per default much less for the asymmetric... Does this mean, that the other two are overkill for what we use in gpg? Probably. But it isn't as if it matters much. - When creating new keys (I'd like to convince some more friends to take part :) )... should they create their keys with gpg1 or gpg2? Or is the key generation equally secure? If memory serves, the key generation code is identical between the 1.4 and 2.0 branches. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: howto secure older keys after the recent attacks
On 09/09/2009 09:45 PM, David Shaw wrote: Instead of giving my preferences, allow me to point at the wonderful defaults in GPG. They're the default algorithms for a reason. I've asked this before, but without any satisfactory answer, i'm still curious: Why do the digest defaults in 1.4.10 and 2.0.13 list SHA-1 above SHA-512, SHA-224, and SHA-384? I don't believe that the mere existence of hardware acceleration of SHA-1 is sufficient to warrant its default preference over stronger, widely-implemented digests. Users who have (and prefer to use) accelerator hardware for any particular digest can change their published preferences to explicitly prefer that hardware, right? Are SHA-1 accelerators so widespread that people have them (and gpg uses them) without being aware of them? Is there some other reason to rank SHA-1 like this? --dkg signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: howto secure older keys after the recent attacks
Hi Robert. On Thu, Sep 10, 2009 at 3:59 PM, Robert J. Hansen r...@sixdemonbag.org wrote: Not really. If there were good reasons to believe OpenBSD's entropy collector was better than Linux's, the Linux crew would fix the code, maybe even borrowing OpenBSD's entropy collector. Ah,.. right... it was the other way round it didn't work (GPL2 to BSD ;) ) -Currently the default (and I assume suggested) algorithm is RSA, right? How does DSA2 compare with it? Arguing whether RSA or DSA2 is better is kind of like arguing whether King Kong or Godzilla is better at stomping cities flat. One should perhaps count in all the King Kong vs. Godzilla moviews,.. who has won more often? ;-) I once read, that RSA would provide a hash algorithm armor which the DSA's wouldn't have. Is this still true? Yes. No. Not really. Kind of. k... ^^ should lead to about the same strenght... Beware of those numbers. I don't know anyone who takes them seriously. They are conjecture and speculation. Educated conjecture and speculation, sure: some of the brightest minds out there worked on the conjecture and speculation -- but they're still conjecture and speculation. That said, there's nothing wrong with using those numbers as long as you remember that they're conjecture. Ok,.. I see. If memory serves, the key generation code is identical between the 1.4 and 2.0 branches. Thanks :) Philippe. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: howto secure older keys after the recent attacks
On Thu, 2009-09-10 at 14:02 +0200, Philippe Cerfon wrote: Uhm,.. what a pity. What would happen if SHA1 gets fully broken? Would we have to create a new OpenPGP and new keys? Probably. However, if SHA-1 gets totally broken we'll have a lot bigger things to worry about than OpenPGP. Well, yes and no. Old signatures are certainly available to both friend and foe, but the real question is: use them for what? What attack are you concerned about here? Well.. not sure... But perhaps it could be used to do some forgery with User IDs? As soon as you find an attack, then we can discuss it. Unfortunately, we can't really talk intelligently about vague fears. I thought the key ID is only used for humans to short check the keys,.. but not in the system itself?! Nope, it's pretty pervasive in the system. So this would basically mean, once SHA1 is broken, we're totally screwed?! If SHA-1 gets totally broken, pretty much everyone with a computer more powerful than a pocket calculator is screwed. We won't be the only ones. At least at the moment you mean? I mean we had the same thing with MD4, MD5 and so on,... so probably it will hit us with SHA1, too? Hans Dobbertin proved MD5 was weak in 1996. In 1997, Network Associates (who then were pretty much the only game in town, as far as PGP goes) decided the Dobbertin attack was worrisome and that MD5 needed to go. By the time the MD5 attacks became practical, PGP had _long_ since migrated to SHA-1 and RIPEMD160. The same thing is happening today with OpenPGP. Everyone knows about the SHA-1 attacks. For right now, the SHA-1 attacks are impractical. The people behind OpenPGP are working on a new OpenPGP proposal that will use a stronger, better hash algorithm. They're on it. Relax. :) If you want to follow the discussion yourself on the official mailing list for the RFC4880 standard, feel free. It's a public list and everyone's welcome. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: howto secure older keys after the recent attacks
On Thu, 2009-09-10 at 16:51 +0200, Philippe Cerfon wrote: Ah,.. right... it was the other way round it didn't work (GPL2 to BSD ;) ) Copyright protects the way an idea is expressed, not the idea itself. If Linux had a better entropy collector than OpenBSD, the OpenBSD folks would study the Linux version. They'd learn how it works, they'd learn how it was designed. The Linux developers would probably help them out in this. Once the OpenBSD folks knew exactly how the Linux collector worked and why, they'd go off and hammer out their own version of the Linux collector. It wouldn't take them long. The hardest part of programming is understanding the problem and how the solution you're writing interacts with it. Once you've got that down, the code almost writes itself. It comes together really, really quick. IANAL, if you're doing serious software development talk to your own IP lawyer before you take this seriously, etc., etc. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: howto secure older keys after the recent attacks
On Sep 10, 2009, at 8:02 AM, Philippe Cerfon wrote: On Thu, Sep 10, 2009 at 3:45 AM, David Shaw ds...@jabberwocky.com wrote: Yes, but it won't actually go away completely. SHA1 is special in OpenPGP. Unlike the other hashes, SHA1 is required to be supported. Removing SHA1 from an OpenPGP preference list doesn't actually remove it, but instead effectively puts it at the end of the list (so it is the lowest ranked choice). Uhm,.. what a pity. What would happen if SHA1 gets fully broken? Would we have to create a new OpenPGP and new keys? Not a new OpenPGP, exactly, but certainly a revised one. New keys, yes. Of course, SHA1 is nowhere near being fully broken. Heck, even MD5 is nowhere near being fully broken (which doesn't mean I recommend people use it, of course). -But I'd also like to have the signatures themselves using e.g. SHA256 or SHA512,... but they're alread using SHA1 Can this be changed? Or can I simply add new self signatures? Yes Does this work via --cert-digest-algo option? If so what must I do to get gpg to: - resign my own key - resign other keys Is it simply with the sign command, or will it complain that there's already a signture there? Yes. To re-sign a key with a new hash, do this: gpg --cert-digest-algo sha256 --expert --edit-key (thekey) (pick the user IDs you want to sign) sign The cert-digest-algo tells GPG which hash to make key signatures with, and the expert tells GPG that it is okay to re-sign a user ID that is already signed. To change the hash you sign with, stick this in your gpg.conf file: personal-digest-preferences sha256 Oh,.. so what is this --cert-digest-algo then good for? personal-digest-preferences sets the hash for signatures you make on data. cert-digest-algo sets the hash for signatures (certifications) you make on keys. Another thing I've read about is, that gpg keys are using SHA1 hard coded in some places with no way to use another algortihm... which places are these so one could avoid them perhaps? You pretty much can't. The key ID itself is derived from SHA1. I thought the key ID is only used for humans to short check the keys,.. but not in the system itself?! So this would basically mean, once SHA1 is broken, we're totally screwed?! No, just that we need to revise OpenPGP. It's not a disaster - we've done it in the past, and can do it again in the future. It's just a specification that describes a cryptographic system using the best knowledge of the time. If the knowledge changes, we change the specification. The real headache here is (as always) the practical - what to do with existing keys and such. I suspect that removing SHA1 would effectively mean a new key type for OpenPGP (again, not a disaster - we're on our 4th key type today). I'd have some additional poor men's questions ;-)... - When creating a new key,.. it uses the entropy, right? So is there some way to improve this entropy? Perhaps not using Linux but instead OpenBSD which might have a better PRNG (don't know if this is actually the case ;) ) or use a specific Linux kernel version where a newer and better PRNG was added? There are occasional debates on who has the better PRNG. The debates usually end with no changes on either side :) That isn't to say there aren't differences between systems - the FreeBSD PRNG (which seems to have been inherited by OSX) is of a fairly different construction than the Linux one, which has led to some mild controversy in the past. Notably, the Linux one blocks if you run out of gathered entropy, and the FreeBSD one does not. FreeBSD /dev/random is similar to Linux's /dev/urandom. See also http://www.entropykey.co.uk/ -Currently the default (and I assume suggested) algorithm is RSA, right? How does DSA2 compare with it? Given the same key length and same hash, they are (massive armwave!) roughly equal for real-world use. If you like, you can define roughly equal as usually so much stronger than the rest of the system that fiddly differences are irrelevant. The actual difference you find between the two is more in implementation and use issues, like DSA signatures being physically smaller than RSA signatures (nice for email), RSA being more widely supported in hardware doodads (smartcards, crypto math chips, etc), and RSA allowing more hash flexibility than DSA. Read NIST SP 800-57 for lots of detail on strength, but they basically conclude the same thing: roughly equal for real-world use. I once read, that RSA would provide a hash algorithm armor which the DSA's wouldn't have. Is this still true? I'm not exactly sure what you mean by hash algorithm armor. RSA in OpenPGP does have a additional protection (usually called a hash firewall) that DSA lacks. This gives some protection against hash substitution attacks, but it's not a major deal either way. -My course's professor showed us some number from NIST
Re: howto secure older keys after the recent attacks
On Sep 10, 2009, at 10:51 AM, Philippe Cerfon wrote: Not really. If there were good reasons to believe OpenBSD's entropy collector was better than Linux's, the Linux crew would fix the code, maybe even borrowing OpenBSD's entropy collector. Ah,.. right... it was the other way round it didn't work (GPL2 to BSD ;) ) Those are just implementations of methods to gather and manipulate entropy. If one method was better, the other would more likely re- implement the idea rather than lifting code wholesale. This usually works out that way in the open source world, and especially in the open source crypto world. Most likely, the people with the better entropy gatherer would actively help the other people to improve their code. This doesn't necessarily work out the same way in the non-open source world, but even so, some companies are very good to deal with with getting information and discussing common problems (the PGP company is a good example of this). -Currently the default (and I assume suggested) algorithm is RSA, right? How does DSA2 compare with it? Arguing whether RSA or DSA2 is better is kind of like arguing whether King Kong or Godzilla is better at stomping cities flat. One should perhaps count in all the King Kong vs. Godzilla moviews,.. who has won more often? ;-) Kong 1, Godzilla 0. Not exactly an Oscar winner, but King Kong vs. Godzilla does have its charms. I'm not sure which is RSA or DSA in this example though, and then there is Mechani-Kong, and Lady Kong, and... ;) David ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: howto secure older keys after the recent attacks
* Philippe Cerfon philc...@googlemail.com [2009-09-10 14:03]: I'd have some additional poor men's questions ;-)... - When creating a new key,.. it uses the entropy, right? So is there some way to improve this entropy? Perhaps not using Linux but instead OpenBSD which might have a better PRNG (don't know if this is actually the case ;) ) or use a specific Linux kernel version where a newer and better PRNG was added? Hi, regarding this, the Simtec Entropy Key http://www.entropykey.co.uk/ is available for sale online since a few days ago. This is an USB hardware entropy generator. Perhaps this would be something to consider in your tests regarding quality and speed of entropy generation. Kind Regards, Sebastian -- New GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) Old GPG Key-ID: 0x76B79F20 (0x1B6034F476B79F20) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant signature.asc Description: Digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: howto secure older keys after the recent attacks
* Sebastian Wiesinger gnupg.us...@ml.karotte.org [2009-09-10 18:01]: Hi, regarding this, the Simtec Entropy Key http://www.entropykey.co.uk/ is available for sale online since a few days ago. This is an USB hardware entropy generator. Perhaps this would be something to consider in your tests regarding quality and speed of entropy generation. I'm sorry, somehow I mixed up this thread with one on gnupg-devel. Nevertheless the key is a nice piece of hardware. Regards, Sebastian -- New GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) Old GPG Key-ID: 0x76B79F20 (0x1B6034F476B79F20) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant signature.asc Description: Digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: howto secure older keys after the recent attacks
On 09/10/2009 10:54 AM, Robert J. Hansen wrote: On Thu, 2009-09-10 at 14:02 +0200, Philippe Cerfon wrote: I thought the key ID is only used for humans to short check the keys,.. but not in the system itself?! Nope, it's pretty pervasive in the system. Unless i misunderstand the context, I think I disagree with your characterization here, Robert. The Key ID is a substring (either the last 8 or 16 hex chars) of the Key Fingerprint (which is 40 hex chars). The Key ID is used nowhere in the internals of the OpenPGP specification, from what i can tell. The fingerprint itself is used only in the designated revocation key [0], which is an acknowledged weakness of the cryptosystem [1]. It's not used anywhere else that i can tell. So I think Philippe Cerfon's characterization is pretty accurate, actually. The fingerprint (and to a weaker extent, the keyID) is useful where the mechanical implementation meets the human mind. But I don't think either are used internally to the OpenPGP cryptosystem in many places at all. --dkg [0] http://tools.ietf.org/html/rfc4880#section-5.2.3.15 [1] http://www.imc.org/ietf-openpgp/mail-archive/msg33257.html signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: howto secure older keys after the recent attacks
Daniel Kahn Gillmor wrote: On 09/10/2009 10:54 AM, Robert J. Hansen wrote: On Thu, 2009-09-10 at 14:02 +0200, Philippe Cerfon wrote: I thought the key ID is only used for humans to short check the keys,.. but not in the system itself?! Nope, it's pretty pervasive in the system. Unless i misunderstand the context, I think I disagree with your characterization here, Robert. I understood him to mean the key ID as the fingerprint of the certificate's primary signing key, rather than checking each bit of the certificate's primary signing key individually. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: howto secure older keys after the recent attacks
Hi Robert. On Thu, Sep 10, 2009 at 4:54 PM, Robert J. Hansen r...@sixdemonbag.org wrote: Probably. However, if SHA-1 gets totally broken we'll have a lot bigger things to worry about than OpenPGP. What specifically do you mean? Crypto-stuff in banking etc.? As soon as you find an attack, then we can discuss it. Unfortunately, we can't really talk intelligently about vague fears. Of course,... just wondered if there might be any known issues due to that. Hans Dobbertin proved MD5 was weak in 1996. In 1997, Network Associates (who then were pretty much the only game in town, as far as PGP goes) decided the Dobbertin attack was worrisome and that MD5 needed to go. By the time the MD5 attacks became practical, PGP had _long_ since migrated to SHA-1 and RIPEMD160. Ok,.. I see. But attackers could still attack older data, that they intercepted, right? Best wishes, Philippe. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: howto secure older keys after the recent attacks
On Thu, Sep 10, 2009 at 5:08 PM, David Shaw ds...@jabberwocky.com wrote: The real headache here is (as always) the practical - what to do with existing keys and such. I suspect that removing SHA1 would effectively mean a new key type for OpenPGP (again, not a disaster - we're on our 4th key type today). Ok,.. but then people would loose all their collected signatures on their keys and to other keys :-( That isn't to say there aren't differences between systems - the FreeBSD PRNG (which seems to have been inherited by OSX) is of a fairly different construction than the Linux one, which has led to some mild controversy in the past. Notably, the Linux one blocks if you run out of gathered entropy, and the FreeBSD one does not. FreeBSD /dev/random is similar to Linux's /dev/urandom. So I better use Linux and not FreeBSD ;) I'm not exactly sure what you mean by hash algorithm armor. RSA in OpenPGP does have a additional protection (usually called a hash firewall) that DSA lacks. This gives some protection against hash substitution attacks, but it's not a major deal either way. Yeah,.. that's the issue I've meant... It's true that NIST's guidelines say that to truly get the maximum juice out of a 512-bit hash, you should use a 15360-bit key, but that doesn't mean you must. That overall strength of the system is the weakest point, so as long as that weakest point is strong enough, you're fine. *still cannot believe, that I've remembered the exact number :-O * Thanks, Philippe. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: howto secure older keys after the recent attacks
Hello Daniel. On Thu, Sep 10, 2009 at 6:22 PM, Daniel Kahn Gillmor d...@fifthhorseman.net wrote: The Key ID is a substring (either the last 8 or 16 hex chars) of the Key Fingerprint (which is 40 hex chars). The Key ID is used nowhere in the internals of the OpenPGP specification, from what i can tell. I think I've messed up the terms fingerprint and key ID, sorry :-( The fingerprint itself is used only in the designated revocation key [0], which is an acknowledged weakness of the cryptosystem [1]. It's not used anywhere else that i can tell. Ok,.. I'm confused now. David said,.. the community would probably have to create a new key type or version at some point. But this sounds more, that if I simply don't use designated revocation keys,... I don't use SHA1 at all,.. and would be fine to simply swtich to another algorithm. Regards, Philippe. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: howto secure older keys after the recent attacks
Hi folks. On Thu, 2009-09-10 at 11:08 -0400, David Shaw wrote: The real headache here is (as always) the practical - what to do with existing keys and such. I suspect that removing SHA1 would effectively mean a new key type for OpenPGP (again, not a disaster - we're on our 4th key type today). Wa will loose all my signatures *G* Ok seriously: ... This is _really_ nice (especially as there are Debian packages for it :-D) See also http://www.entropykey.co.uk/ Anyway,.. I'm really not an randomness-expert so perhaps some questions: 1) Is this already supported by gpg? 2) If so,.. where would gpg use it? Only for symmetric keys? Or also for asymmetric? 3) One problem with such devices is,.. that one can never know (well at least normal folks like me) how good they actually are. If this company would be evil (subsidiary of NSA or so) they could just sell bad devices that produce poor entropy thus rendering our (symmetric and asymmetric) keys, signatures etc. useless. Right? So my question is basically,.. If gpg would use this,... does it only improve the already existing entropy and randomness of the kernel PRNG? I mean that gpg somehow merges the different sources? Or is it more or less a,.. either use the kernel PRNG or the hardware RNG. If there is such a merging,.. how well does it work? I mean imagine the device would be very evil (or just stupid) and produce only 0's or 1's or series of 0101's or something like this. Would the merging produce entropy that's still as least as good as if one would just have the kernel PRNG? Or would it yield in weaker randomness. (sorry for my non-expert terminology here ;) ) - When creating new keys (I'd like to convince some more friends to take part :) )... should they create their keys with gpg1 or gpg2? Or is the key generation equally secure? Equally secure. In fact, it's almost the same code. I really wonder if you'll maintain both versions forever :-) ;) Happy crypting, Chris. -- Grid Monkey smime.p7s Description: S/MIME cryptographic signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: howto secure older keys after the recent attacks
On Thu, Sep 10, 2009 at 10:21 PM, Robert J. Hansen r...@sixdemonbag.org wrote: I understood him to mean the key ID as the fingerprint of the certificate's primary signing key, rather than checking each bit of the certificate's primary signing key individually. I meant the fingerprint, yes. But now that you say it. Would it be better to not just check other keys via their fingerprint, but to really copy them (e.g. per USB-stick) from their owners and sign only such direct copies? Philippe. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: howto secure older keys after the recent attacks
Hi folks. On Thu, 2009-09-10 at 11:08 -0400, David Shaw wrote: The real headache here is (as always) the practical - what to do with existing keys and such. I suspect that removing SHA1 would effectively mean a new key type for OpenPGP (again, not a disaster - we're on our 4th key type today). Wa will loose all my signatures *G* Ok seriously: ... This is _really_ nice (especially as there are Debian packages for it :-D) See also http://www.entropykey.co.uk/ Anyway,.. I'm really not an randomness-expert so perhaps some questions: 1) Is this already supported by gpg? 2) If so,.. where would gpg use it? Only for symmetric keys? Or also for asymmetric? 3) One problem with such devices is,.. that one can never know (well at least normal folks like me) how good they actually are. If this company would be evil (subsidiary of NSA or so) they could just sell bad devices that produce poor entropy thus rendering our (symmetric and asymmetric) keys, signatures etc. useless. Right? So my question is basically,.. If gpg would use this,... does it only improve the already existing entropy and randomness of the kernel PRNG? I mean that gpg somehow merges the different sources? Or is it more or less a,.. either use the kernel PRNG or the hardware RNG. If there is such a merging,.. how well does it work? I mean imagine the device would be very evil (or just stupid) and produce only 0's or 1's or series of 0101's or something like this. Would the merging produce entropy that's still as least as good as if one would just have the kernel PRNG? Or would it yield in weaker randomness. (sorry for my non-expert terminology here ;) ) - When creating new keys (I'd like to convince some more friends to take part :) )... should they create their keys with gpg1 or gpg2? Or is the key generation equally secure? Equally secure. In fact, it's almost the same code. I really wonder if you'll maintain both versions forever :-) ;) Happy crypting, Chris. -- Grid Monkey smime.p7s Description: S/MIME cryptographic signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: howto secure older keys after the recent attacks
Hi Robert. On Thu, 2009-09-10 at 10:54 -0400, Robert J. Hansen wrote: Nope, it's pretty pervasive in the system. I thought it (and SHA1 fingerprints) would only be used in designated revoker signatures, and MDC? The people behind OpenPGP are working on a new OpenPGP proposal that will use a stronger, better hash algorithm. Have workings on an 4880 successor already started? Perhaps some of you (David?) remember the discussion that took place here and on the WG list some time ago about things like: - how criticality and critical bit could be handled much stricter - potential problems that arise because conforming implementation are only recommended to ignore signatures of an older time (especially self-sigs). - some other places where OpenPGP could (and for security reasons perhaps should) be more strict and demanding to (conforming) implementations - Ideas for much broader use of attributes (different types of names, birth-dates, -places, sex, etc. etc.) So I wonder who's doing the (main) work for the writing this time? And is there perhaps a wiki or so, where one could collect such suggestions? Sincerely, Chris. smime.p7s Description: S/MIME cryptographic signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: howto secure older keys after the recent attacks
Philippe Cerfon wrote: What specifically do you mean? Crypto-stuff in banking etc.? Specifically? I don't have the time to list everywhere that will break. SHA-1 is used in a ton of places, and often not places you'd immediately expect. For instance, computer fuel injection timings are controlled by software. Auto enthusiasts would like to be able to customize them, but can't. If SHA-1 breaks, auto enthusiasts will be able to forge their own signatures and deliver their own updates to their engines. Skype will potentially break. Many P2P networks (including the ones Skype is based upon) use a mathematical construct called a distributed hash table to figure out how to route data. If the hash algorithm is bad, well, you're out of luck. Filesystems will suffer. There exist some filesystems that avoid storing redundant data by tracking a hash of each file. If the file you're writing matches a hash that's already on the disk, the filesystem just puts in a soft link. That's three examples of things that will unexpectedly break if SHA-1 falls. A complete laundry list would go for pages and pages and pages. I'd suggest reading comp.risks; they might have something on point. But attackers could still attack older data, that they intercepted, right? No. Imagine that in 2010, the OpenPGP Working Group publishes a new key specification. v5 keys use SHA256, not SHA1. I revoke my current key and migrate to a new v5 key. In 2015, the SHA-1 attack becomes practical. Someone goes back to my old messages and lifts a signature off something I've written. They construct a new message that hashes out the same as my old message, and put my old signature on a new message. Look, look! He signed a message in 2009 claiming that he'd pay me $1 million in 2015! Pay up, Mr. Hansen! No one would take such a forgery seriously. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: howto secure older keys after the recent attacks
Philippe Cerfon wrote: But now that you say it. Would it be better to not just check other keys via their fingerprint, but to really copy them (e.g. per USB-stick) from their owners and sign only such direct copies? No. Sharing media is a great way to spread malware. Don't do that to your friends. Use the keyserver network. SHA-1 is in trouble, but it's not dead yet, and regular users should not be worried about it. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: howto secure older keys after the recent attacks
On Fri, Sep 11, 2009 at 12:39 AM, Robert J. Hansen r...@sixdemonbag.org wrote: That's three examples of things that will unexpectedly break if SHA-1 falls. A complete laundry list would go for pages and pages and pages. I'd suggest reading comp.risks; they might have something on point. Thanks,.. got what you meant :-) But attackers could still attack older data, that they intercepted, right? Imagine that in 2010, the OpenPGP Working Group publishes a new key specification. v5 keys use SHA256, not SHA1. I revoke my current key and migrate to a new v5 key. In 2015, the SHA-1 attack becomes practical. Someone goes back to my old messages and lifts a signature off something I've written. They construct a new message that hashes out the same as my old message, and put my old signature on a new message. Look, look! He signed a message in 2009 claiming that he'd pay me $1 million in 2015! Pay up, Mr. Hansen! No one would take such a forgery seriously. Ah I see,... And encryption does not suffer from hash algorithm weaknesses anyway, does it? I mean there it wouldn't help to revoke my key,... (given the fact that one has such long term secrets). Cheers, Philippe. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: howto secure older keys after the recent attacks
On 09/10/2009 06:32 PM, Christoph Anton Mitterer wrote: 3) One problem with such devices is,.. that one can never know (well at least normal folks like me) how good they actually are. If this company would be evil (subsidiary of NSA or so) they could just sell bad devices that produce poor entropy thus rendering our (symmetric and asymmetric) keys, signatures etc. useless. Right? Worse than this: the devices could produce measurably good entropy that happens to be predictable to a malicious individual in control of a special secret. For example, if such a key were to contain a copy of the secret, and somehow retain the current time (e.g. a battery and a clock?), it could produce a new output stream each second with: AES(secret + time()) (first cleartext block is just secret + time, and next cleartext block for that second is just the previous ciphertext block XOR'ed with secret + time -- reset every second as time() changes) This would produce a predictable stream that (like all good ciphers) has high-entropy output. Then, if this was used to provide random numbers to the kernel, which in turn provided them to gpg, an attacker who knows the secret associated with your entropy key, and the time you generated the key (that information is published with your public key) could probably reproduce the stream of randomness that was used for your key generation, and therefore stumble upon your private key. --dkg signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: howto secure older keys after the recent attacks
On Fri, 2009-09-11 Christoph Anton Mitterer wrote: . . . sell bad devices that produce poor entropy thus rendering our (symmetric and asymmetric) keys, signatures etc. useless. . . . Just out of curiousity, about how poor entropy might make it easy to break encryption: Is it necessary for an attacker to know pre-attack that a specific targeted file has been encrypted or etc using poor entropy? Or is the weakness one which can efficiently be exploited en mass, by attacking all files in a batch of files and just being successful against any of the files which happened to be encrypted using poor entropy? ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: howto secure older keys after the recent attacks
On Sep 10, 2009, at 6:32 PM, Christoph Anton Mitterer wrote: Hi folks. On Thu, 2009-09-10 at 11:08 -0400, David Shaw wrote: The real headache here is (as always) the practical - what to do with existing keys and such. I suspect that removing SHA1 would effectively mean a new key type for OpenPGP (again, not a disaster - we're on our 4th key type today). Wa will loose all my signatures *G* Ok seriously: ... This is _really_ nice (especially as there are Debian packages for it :-D) See also http://www.entropykey.co.uk/ Anyway,.. I'm really not an randomness-expert so perhaps some questions: 1) Is this already supported by gpg? Yes. It's not that gpg has a driver for it though. The developers of the entropy key were clever and instead of making programs write new code to use the key, they made a program that reads the key and feeds the Linux entropy pool. Thus, anything that uses /dev/random (like gpg) benefits without code changes. 2) If so,.. where would gpg use it? Only for symmetric keys? Or also for asymmetric? Both. 3) One problem with such devices is,.. that one can never know (well at least normal folks like me) how good they actually are. If this company would be evil (subsidiary of NSA or so) they could just sell bad devices that produce poor entropy thus rendering our (symmetric and asymmetric) keys, signatures etc. useless. Right? Not completely useless given the Linux random design, but certainly an evil source of entropy would be a serious problem. Do you have any reason to believe this device is evil? There are many random number generators on the market. Knowing which ones are evil would be handy ;) So my question is basically,.. If gpg would use this,... does it only improve the already existing entropy and randomness of the kernel PRNG? I mean that gpg somehow merges the different sources? Or is it more or less a,.. either use the kernel PRNG or the hardware RNG. The kernel merges several sources of entropy into the /dev/random pool. The entropy key would just be another source (though a very prolific source) of entropy. David ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: howto secure older keys after the recent attacks
On Sep 10, 2009, at 8:38 PM, Daniel Kahn Gillmor wrote: On 09/10/2009 06:32 PM, Christoph Anton Mitterer wrote: 3) One problem with such devices is,.. that one can never know (well at least normal folks like me) how good they actually are. If this company would be evil (subsidiary of NSA or so) they could just sell bad devices that produce poor entropy thus rendering our (symmetric and asymmetric) keys, signatures etc. useless. Right? Worse than this: the devices could produce measurably good entropy that happens to be predictable to a malicious individual in control of a special secret. Sure, but your computer vendor could have a relationship with the NSA and put some special code in the BIOS to capture keyboard input and periodically send it to a central server. Your disk drive vendor could keep a few extra sectors hidden from the reallocation pool, and use them to store copies of things that match the byte signature of a PGP key. Your wifi AP vendor could have a hidden secret WPA key that makes your home network available to a malicious individual in control of the special secret. Could is a very powerful word. At some point, people have to buy and run the closed-source hardware they need to run their open-source software on :) David ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: howto secure older keys after the recent attacks
On Sep 10, 2009, at 6:32 PM, Christoph Anton Mitterer wrote: The people behind OpenPGP are working on a new OpenPGP proposal that will use a stronger, better hash algorithm. Have workings on an 4880 successor already started? No, at this point things are mainly being proposed as *additions* to 4880. The first of these to reach completion is RFC-5581, which added the Camellia cipher to OpenPGP (it's in 1.4.10, incidentally, but you need to opt-in by adding it to your key prefs before it will be used). Another addition would be ECC support, or the SHA-1 free key format. Perhaps some of you (David?) remember the discussion that took place here and on the WG list some time ago about things like: - how criticality and critical bit could be handled much stricter - potential problems that arise because conforming implementation are only recommended to ignore signatures of an older time (especially self-sigs). - some other places where OpenPGP could (and for security reasons perhaps should) be more strict and demanding to (conforming) implementations - Ideas for much broader use of attributes (different types of names, birth-dates, -places, sex, etc. etc.) So I wonder who's doing the (main) work for the writing this time? And is there perhaps a wiki or so, where one could collect such suggestions? The place for all such suggestions is the IETF OpenPGP working group: http://www.imc.org/ietf-openpgp/ David ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: howto secure older keys after the recent attacks
On 09/10/2009 10:23 PM, David Shaw wrote: Could is a very powerful word. At some point, people have to buy and run the closed-source hardware they need to run their open-source software on :) Agreed! I was just pointing out that the lack of true entropy might not be as obvious as the proposed card that always returned 0x00 when asked for a random byte. There is also open hardware for random number generation, for whatever that's worth: http://warmcat.com/_wp/whirlygig-rng/ i've never used any of these devices myself. --dkg signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: howto secure older keys after the recent attacks
On Sep 10, 2009, at 5:44 PM, Philippe Cerfon wrote: On Thu, Sep 10, 2009 at 10:21 PM, Robert J. Hansen r...@sixdemonbag.org wrote: I understood him to mean the key ID as the fingerprint of the certificate's primary signing key, rather than checking each bit of the certificate's primary signing key individually. I meant the fingerprint, yes. But now that you say it. Would it be better to not just check other keys via their fingerprint, but to really copy them (e.g. per USB-stick) from their owners and sign only such direct copies? I suspect you are more in danger of being hit by meteors several times in a row as you walk to your friend's house with the USB stick, than you are in danger from SHA-1. :) David ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
howto secure older keys after the recent attacks
Hi. Now something more realistic and pracitcal. I'm using gpg for anonymous but secured communication together with some of my friends for some years now Recently I've read on severa attacks on SHA1 and AES256 that could also affect gpg and its keys. So waht I'd like to see is some step by step howto on securing older keys (written by some expert probably ;-) ). I have two keys a the moment one is a 4096 bit RSA key, the oder (for daily use) has 1024 bits. Using the pgpdump tool I found out that it has these settings: Old: Signature Packet(tag 2)(567 bytes) Ver 4 - new Sig type - Positive certification of a User ID and Public Key packet(0x13). Pub alg - RSA Encrypt or Sign(pub 1) Hash alg - SHA1(hash 2) Hashed Sub: key flags(sub 27)(1 bytes) Flag - This key may be used to certify other keys Flag - This key may be used to sign data Hashed Sub: preferred symmetric algorithms(sub 11)(5 bytes) Sym alg - AES with 256-bit key(sym 9) Sym alg - AES with 192-bit key(sym 8) Sym alg - AES with 128-bit key(sym 7) Sym alg - CAST5(sym 3) Sym alg - Triple-DES(sym 2) Hashed Sub: preferred hash algorithms(sub 21)(2 bytes) Hash alg - SHA1(hash 2) Hash alg - RIPEMD160(hash 3) Hashed Sub: preferred compression algorithms(sub 22)(2 bytes) Comp alg - ZLIB RFC1950(comp 2) Comp alg - ZIP RFC1951(comp 1) Hashed Sub: features(sub 30)(1 bytes) Flag - Modification detection (packets 18 and 19) Hashed Sub: key server preferences(sub 23)(1 bytes) Flag - No-modify Hashed Sub: signature creation time(sub 2)(4 bytes) Time - Fri Oct 28 20:48:23 CEST 2005 Hashed Sub: primary User ID(sub 25)(1 bytes) Primary - Yes Sub: issuer key ID(sub 16)(8 bytes) and a more recent User ID has these: Old: Signature Packet(tag 2)(566 bytes) Ver 4 - new Sig type - Positive certification of a User ID and Public Key packet(0x13). Pub alg - RSA Encrypt or Sign(pub 1) Hash alg - SHA1(hash 2) Hashed Sub: signature creation time(sub 2)(4 bytes) Time - Fri Apr 25 01:23:36 CEST 2008 Hashed Sub: key flags(sub 27)(1 bytes) Flag - This key may be used to certify other keys Flag - This key may be used to sign data Hashed Sub: preferred symmetric algorithms(sub 11)(5 bytes) Sym alg - AES with 256-bit key(sym 9) Sym alg - AES with 192-bit key(sym 8) Sym alg - AES with 128-bit key(sym 7) Sym alg - CAST5(sym 3) Sym alg - Triple-DES(sym 2) Hashed Sub: preferred hash algorithms(sub 21)(3 bytes) Hash alg - SHA1(hash 2) Hash alg - SHA256(hash 8) Hash alg - RIPEMD160(hash 3) Hashed Sub: preferred compression algorithms(sub 22)(3 bytes) Comp alg - ZLIB RFC1950(comp 2) Comp alg - BZip2(comp 3) Comp alg - ZIP RFC1951(comp 1) Hashed Sub: features(sub 30)(1 bytes) Flag - Modification detection (packets 18 and 19) Hashed Sub: key server preferences(sub 23)(1 bytes) Flag - No-modify As far as I understand thise means: - The signatures on them are created with SHA1 - The differ in preferred algorihtms for hashes and compression Well... - It seems that I can easily change these preferences via gpg --edit-key,.. so I could simply remove e.g. SHA1 -But I'd also like to have the signatures themselves using e.g. SHA256 or SHA512,... but they're alread using SHA1 Can this be changed? Or can I simply add new self signatures? And if I do so the old ones would still be on the keyservers, right? And no way to delete them. So does this mean any harm to me? At some day SHA1 might be fully broken, and then an attacker could use simply these older self signatures instead of the newer ones, or not? Or should I better start with a fresh key without any old signatures? Another thing I've read about is, that gpg keys are using SHA1 hard coded in some places with no way to use another algortihm... which places are these so one could avoid them perhaps? Thanks for your insight, Philippe. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: howto secure older keys after the recent attacks
So waht I'd like to see is some step by step howto on securing older keys (written by some expert probably ;-) ). Add these lines to your gpg.conf file: personal-digest-preferences SHA256 SHA224 SHA384 SHA512 RIPEMD160 personal-cipher-preferences AES128 3DES ... This will tell GnuPG that you'd much rather use a newer SHA than you would SHA-1; and if for some reason GnuPG has to use a 160-bit hash, to use RIPEMD160 instead of SHA-1. It will also tell GnuPG to use AES128 for message encryption. If for whatever reason your recipient can't read AES128, it should fall back to 3DES. Some people will tell you that 3DES is an old, antique and outdated cipher. This is true. Some will tell you it's slow. This is an understatement. 3DES is ugly, crude, and inelegant. It has all the aesthetics of the Soviet Socialist Realism school of art. It has also been turning brilliant cryptanalysts into burned-out alcoholic wrecks for three decades straight, and that reputation is solid gold. Some people will undoubtedly advocate much more complex schemes. I suggest avoiding them. Simple and effective solutions are usually much, much better than complex and effective solutions. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: howto secure older keys after the recent attacks
On Sep 9, 2009, at 6:43 PM, Philippe Cerfon wrote: Hi. Now something more realistic and pracitcal. I'm using gpg for anonymous but secured communication together with some of my friends for some years now Recently I've read on severa attacks on SHA1 and AES256 that could also affect gpg and its keys. So waht I'd like to see is some step by step howto on securing older keys (written by some expert probably ;-) ). [..] As far as I understand thise means: - The signatures on them are created with SHA1 - The differ in preferred algorihtms for hashes and compression Well... - It seems that I can easily change these preferences via gpg --edit- key,.. so I could simply remove e.g. SHA1 Yes, but it won't actually go away completely. SHA1 is special in OpenPGP. Unlike the other hashes, SHA1 is required to be supported. Removing SHA1 from an OpenPGP preference list doesn't actually remove it, but instead effectively puts it at the end of the list (so it is the lowest ranked choice). -But I'd also like to have the signatures themselves using e.g. SHA256 or SHA512,... but they're alread using SHA1 Can this be changed? Or can I simply add new self signatures? Yes And if I do so the old ones would still be on the keyservers, right? And no way to delete them. Yes So does this mean any harm to me? At some day SHA1 might be fully broken, and then an attacker could use simply these older self signatures instead of the newer ones, or not? Well, yes and no. Old signatures are certainly available to both friend and foe, but the real question is: use them for what? What attack are you concerned about here? Or should I better start with a fresh key without any old signatures? No need. If you had a DSA key, I might suggest changing keys, but you have an RSA key, and are thus free to use whatever hash you please. To change the hash you sign with, stick this in your gpg.conf file: personal-digest-preferences sha256 Feel free to list whatever hashes you like here. GPG will rank them in that order. Another thing I've read about is, that gpg keys are using SHA1 hard coded in some places with no way to use another algortihm... which places are these so one could avoid them perhaps? You pretty much can't. The key ID itself is derived from SHA1. There was a very long discussion of the SHA1 issue a few months back on this list. See, for example, http://lists.gnupg.org/pipermail/gnupg-users/2009-May/036338.html and http://lists.gnupg.org/pipermail/gnupg-devel/2009-May/024999.html In short, I wouldn't worry all that much about it. With regards to AES256, I doubly wouldn't worry about it. See http://lists.gnupg.org/pipermail/gnupg-users/2009-August/037107.html This sort of question tends to cause long threads where everyone throws in their own cipher preferences. Instead of giving my preferences, allow me to point at the wonderful defaults in GPG. They're the default algorithms for a reason. David ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
