Re: key generation: paranoia mode - explicit random input
On 02/28/2014 02:58 PM, Hauke Laging wrote: a) Maybe I was not clear enough about that but I do not suggest this as a Set the flag once (and do the other stuff) and after that you are safe forever feature. This feature would have to be used for every encryption, too. (I guess it would be easily possible with RSA signatures today i.e. without changes to GnuPG.) Thus your when you're not using that flag point is never reached. Asking the end users to routinely choose a novel high-entropy seed for randomness *without* relying on OS-level feature like /dev/random or /dev/urandom seems even worse than the case you're trying to defend against. It reduces the problem of breaking the encryption to that of figuring out what data was used as the seed for randomness. How do you prevent users from choosing the same seed multiple times? How is the user supposed to come up with this entropy? In practice, i think this won't happen reliably, and users will be exposed to all the usual attacks possible against broken RNGs if they try to use this proposed feature. -dkg signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: key generation: paranoia mode - explicit random input
Am Sa 01.03.2014, 08:40:56 schrieb Daniel Kahn Gillmor: Asking the end users to routinely choose a novel high-entropy seed for randomness *without* relying on OS-level feature like /dev/random or /dev/urandom seems even worse than the case you're trying to defend against. Probably. But this is not a proposal for users but for the kind of people who regularly write on this list. People who know what they are doing. Security improvements never(?) come for free. Hauke -- Crypto für alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 signature.asc Description: This is a digitally signed message part. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: key generation: paranoia mode - explicit random input
Probably. But this is not a proposal for users but for the kind of people who regularly write on this list. People who know what they are doing. That, by itself, is a compelling reason not to do it. A feature that will be used by under 0.1% of the userbase is a feature not worth introducing. The likelihood of introducing a bug which may affect everyone is orders of magnitude greater than the limited benefit that will be enjoyed by one user in a thousand. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: key generation: paranoia mode - explicit random input
Your system bears similarities to deterministic compilation, where you build a binary on different systems and compare the results. There is a defining difference though. With deterministic compilation, the built binary is the end goal. When one of the systems it builds on is trustworthy, and all copies are the same, the binary is the one that you want and will use. Your product is okay. You don't care about the machines it was built on. With your scheme, the public key or the signed message are not the end goal. The end goal is the secrecy of the private components. You do care about all the systems it was built on, because they still have your private key. HTH, Peter. -- 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
Re: key generation: paranoia mode - explicit random input
Am Do 27.02.2014, 08:38:37 schrieb Michael Anders: If a private key has been accessed on a system some adversary might have had a chance to tamper with(e.g. with the PRNG or generally if it is an NSA friendly OS connected to the web ;-) , there could have been a keylogger in place and security of the key is gone. I am talking about a szenario in which everything which can be reasonably done already has been done. I am not talking about Here's my system at which I click on every link I see. How can I make GnuPG more secure?. I.e. we are talking about offline systems here (yeah, I remember the discussion about USB sticks being dangerous...) thus a keylogger would not be a problem. Hauke -- Crypto für alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 signature.asc Description: This is a digitally signed message part. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: key generation: paranoia mode - explicit random input
Am Do 27.02.2014, 10:28:10 schrieb Doug Barton: Someone else made this argument already, which I thought should have shut down the thread, but it didn't, so I'll try repeating it. :) Thanks for paying attention and thinking about this but I already explained why I consider the argument you (probably) refer to as valid in general but invalid in the special case I am talking about. I am not simply ignoring well-meant advice. If I am Mal, I am going to make sure that my implementation does the right thing when you add the --verify-my-binary-is-safe flag. But when you're not using that flag I'm still free to do whatever I want with your stuff. That is correct. But your argument does not cover two important cases: a) Maybe I was not clear enough about that but I do not suggest this as a Set the flag once (and do the other stuff) and after that you are safe forever feature. This feature would have to be used for every encryption, too. (I guess it would be easily possible with RSA signatures today i.e. without changes to GnuPG.) Thus your when you're not using that flag point is never reached. b) This is not a problem if you just receive encrypted data. In that case you just must be sure that your key is clean. (The sender obviously has the problem how to be sure that his system is non-compromised.) In other words, we're right back to the same thread we had about 6 weeks ago. You cannot Trust a binary, for sufficiently Secure definitions of Trust. Sure. Thus I don't claim absolute security for my case but only that an attacker has to compromise more systems. Or central components (Kernel, GnuPG itself). I don't even have the slightest idea how safe the key is which signs the GnuPG packages... If I were the NSA then I would consider the software which Werner(?) uses for calculating the digests a valuable target... ;-) ... and BTW, if you think I'm being paranoid or exaggerating the problem on the OS side Not at all. After all most people would even consider my proposal paranoid, wouldn't they? Hauke -- Crypto für alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 signature.asc Description: This is a digitally signed message part. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: key generation: paranoia mode - explicit random input
Am Do 27.02.2014, 22:30:01 schrieb Robert J. Hansen: Trivial to prevent in comparison to the task of verifying a distro. There are literally thousands of vectors. Defending against *all* of them is a deeply nontrivial task. As usual I can agree only. But what does that mean in practice? Does that mean we don't aim for improvements any more, not even those which are easy to implement? Why are we talking about something like SHA-3 at all if all is lost to THEM anyway? (Please note that I am not implying this was your attitude.) Besides the obvious development resource limit I guess the point should be: How much more security would one get from a certain action and how much effort would it be? Hauke -- Crypto für alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 signature.asc Description: This is a digitally signed message part. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: key generation: paranoia mode - explicit random input
On 28/02/14 16:05, Hauke Laging wrote: But what does that mean in practice? Does that mean we don't aim for improvements any more, not even those which are easy to implement? I'm Dutch, so I'll do a dyke analogy. A dyke has breached. Throwing in one sack of sand is easily implemented, and it prevents the water from flowing over a span of say half a meter. Too bad it's still flowing over the span of the rest of the sixty meters the breach is wide. Your solution seems analogous to throwing in the one sack of sand because it is easy to implement. So indeed: how much more security will one get? I think that's where the opinions differ. You just have to trust your most trusted computer, or you have a lot of water in your living room. By the way, if it's so easy to implement, you could write a patch, or pay someone to do it for you. I would warn you to think about the source and quality of your randomness. If a compromised computer supplied your file containing the randomness, you'd look pretty foolish if you used that. So I suppose you need to have each computer generate the amount of randomness that is (worst case) needed for a key generation, and then have a well defined method of combining all those different blocks of randomness in such a way that even if a part of the randomness is crafted precisely to counteract the randomness in the other parts, you still have enough randomness to generate a key. It seems to me assuring the quality of the randomness is much harder than simply redirecting libgcrypt's random functions. Oh, and obviously, each computer that supplied a part of the randomness needs to verify that that is still the same when it generates the key, or the last PC to generate a block of randomness could just as well replace the earlier parts without you noticing. Etcetera. I'm sure I've missed something interesting relating to the randomness generation and transportation. I have one final question: would you even use this yourself or do you just think it's cool? Peter. PS: Sorry for my wildly inaccurate description of a dyke breach and stopping it. I might be Dutch, but I'm not an expert on water. I gladly leave that to the king :). -- 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
Re: key generation: paranoia mode - explicit random input
But what does that mean in practice? Does that mean we don't aim for improvements any more, not even those which are easy to implement? It means that when people ask questions like, But how do we know the GnuPG in distro XY has not been compromised?, we give them clear, matter-of-fact answers: you don't, but if you're serious about this question you clearly need to use a different distro because the distro has literally millions of ways to screw you over surreptitiously. Your proposal tries to answer that question with, well, use this technique. I've read your proposal and it doesn't seem like it solves anything -- which I regret: I really wish it did. Introducing stronger hash algorithms is easy to justify. Introducing new technologies that don't mitigate the problems they exist to solve... not so much. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: key generation: paranoia mode - explicit random input
The discussion on what to do in a partially compromized system is IMHO irrelevant. If a private key has been accessed on a system some adversary might have had a chance to tamper with(e.g. with the PRNG or generally if it is an NSA friendly OS connected to the web ;-) , there could have been a keylogger in place and security of the key is gone. If you consider the NSA to be a benevolent organization, you might make a distinction between security against criminals and security against the NSA, but that is politics and not cryptography. Cheers, Michael Anders ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: key generation: paranoia mode - explicit random input
On Wed, 26 Feb 2014 22:07, mailinglis...@hauke-laging.de said: I had a look at that but I am not sure what you want me to read. Could you be more precise about that? Below and also Peter Gutmann's book (see footnote in the text below). Shalom-Salam, Werner 16.6 Random-Number Subsystem Architecture = Libgcrypt provides 3 levels or random quality: The level `GCRY_VERY_STRONG_RANDOM' usually used for key generation, the level `GCRY_STRONG_RANDOM' for all other strong random requirements and the function `gcry_create_nonce' which is used for weaker usages like nonces. There is also a level `GCRY_WEAK_RANDOM' which in general maps to `GCRY_STRONG_RANDOM' except when used with the function `gcry_mpi_randomize', where it randomizes an multi-precision-integer using the `gcry_create_nonce' function. There are two distinct random generators available: * The Continuously Seeded Pseudo Random Number Generator (CSPRNG), which is based on the classic GnuPG derived big pool implementation. Implemented in `random/random-csprng.c' and used by default. * A FIPS approved ANSI X9.31 PRNG using AES with a 128 bit key. Implemented in `random/random-fips.c' and used if Libgcrypt is in FIPS mode. Both generators make use of so-called entropy gathering modules: rndlinux Uses the operating system provided `/dev/random' and `/dev/urandom' devices. rndunix Runs several operating system commands to collect entropy from sources like virtual machine and process statistics. It is a kind of poor-man's `/dev/random' implementation. It is not available in FIPS mode. rndegd Uses the operating system provided Entropy Gathering Daemon (EGD). The EGD basically uses the same algorithms as rndunix does. However as a system daemon it keeps on running and thus can serve several processes requiring entropy input and does not waste collected entropy if the application does not need all the collected entropy. It is not available in FIPS mode. rndw32 Targeted for the Microsoft Windows OS. It uses certain properties of that system and is the only gathering module available for that OS. rndhw Extra module to collect additional entropy by utilizing a hardware random number generator. As of now the only supported hardware RNG is the Padlock engine of VIA (Centaur) CPUs. It is not available in FIPS mode. 16.6.1 Description of the CSPRNG This random number generator is loosely modelled after the one described in Peter Gutmann's paper: Software Generation of Practically Strong Random Numbers.(1) A pool of 600 bytes is used and mixed using the core RIPE-MD160 hash transform function. Several extra features are used to make the robust against a wide variety of attacks and to protect against failures of subsystems. The state of the generator may be saved to a file and initially seed form a file. Depending on how Libgcrypt was build the generator is able to select the best working entropy gathering module. It makes use of the slow and fast collection methods and requires the pool to initially seeded form the slow gatherer or a seed file. An entropy estimation is used to mix in enough data from the gather modules before returning the actual random output. Process fork detection and protection is implemented. The implementation of the nonce generator (for `gcry_create_nonce') is a straightforward repeated hash design: A 28 byte buffer is initially seeded with the PID and the time in seconds in the first 20 bytes and with 8 bytes of random taken from the `GCRY_STRONG_RANDOM' generator. Random numbers are then created by hashing all the 28 bytes with SHA-1 and saving that again in the first 20 bytes. The hash is also returned as result. -- Footnotes -- (1) Also described in chapter 6 of his book Cryptographic Security Architecture, New York, 2004, ISBN 0-387-95387-6. 16.6.2 Description of the FIPS X9.31 PRNG - The core of this deterministic random number generator is implemented according to the document NIST-Recommended Random Number Generator Based on ANSI X9.31 Appendix A.2.4 Using the 3-Key Triple DES and AES Algorithms, dated 2005-01-31. This implementation uses the AES variant. The generator is based on contexts to utilize the same core functions for all random levels as required by the high-level interface. All random generators return their data in 128 bit blocks. If the caller requests less bits, the extra bits are not used. The key for each generator is only set once at the first time a generator context is used. The seed value is set along with the key and again after 1000 output blocks. On Unix like systems the `GCRY_VERY_STRONG_RANDOM' and `GCRY_STRONG_RANDOM' generators are keyed and seeded using the rndlinux module with the
Re: key generation: paranoia mode - explicit random input
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Someone else made this argument already, which I thought should have shut down the thread, but it didn't, so I'll try repeating it. :) If I am Mal, I am going to make sure that my implementation does the right thing when you add the --verify-my-binary-is-safe flag. But when you're not using that flag I'm still free to do whatever I want with your stuff. In other words, we're right back to the same thread we had about 6 weeks ago. You cannot Trust a binary, for sufficiently Secure definitions of Trust. You can't even Trust the binary if you compiled it yourself because you're not smart enough to go over every line of code for your binary, all of the libs it links against, the compiler, etc. etc. (And that's not an ad hominem attack, no one person has the requisite combination of knowledge and experience to do this.) So if you're an average user at some point you have to put your little-t trust somewhere. If you're part of an organization where lives depend on getting the crypto right you're going to allocate additional resources for making things more Secure as appropriate of course. But that's not going to involve command line options. ... and BTW, if you think I'm being paranoid or exaggerating the problem on the OS side just look at the recent flap with Apple software (iOS and OS X 10.9 both) regarding their own personal SSL/TLS implementation. One single misplaced 'goto' caused everyone using those systems to be vulnerable to a certain type of MITM. Linux has had similar issues, and don't get me started on Windows So Hauke, creative idea, but a non-starter IMO. Doug -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iQEcBAEBCAAGBQJTD4O6AAoJEFzGhvEaGryEks0H/27ng3Cx4dn6Hyig2KoVphPW gDI8z3JsSbglArCbuDghVLgJFCOrbHaN2jOdQXm38Q/3ykwQiG8GZqU9iYXmXcY7 MbjEQUdaqIdULPSyVepL8Sg57DQf2U0Vd2Wf+deUVjPXcQfQzew+I0R/Z5ou1qjA cwBPzXnIL/8zjFUdrHIhxiTPlfAPh5o+NhUTqLVuHRPKATl3QmTj8FQ3FWYUkhR6 hlmEvSpqiHCUYbAzVOOJS1OnxlNfKvCNdNm+DmLOH0ZLE9XujpmVOwd1UC8vsz+6 mUE3rrlT8kvSbcEz3Txxr2Nh+rCyfZNIkg0krack32/JXOdNu8kFZBouquEdsts= =Jhsk -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: key generation: paranoia mode - explicit random input
I just got asked: How do I know that GnuPG in distro XY is not compromised? You don't. At some point you have to choose to trust something. This is usually your operating system provider. If you can't trust your operating system provider, then you're completely screwed and there's nothing anyone can do to change this. The question is not, has GnuPG in distro XY been compromised? The question is, should I trust distro XY? ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: key generation: paranoia mode - explicit random input
Trivial to prevent in comparison to the task of verifying a distro. There are literally thousands of vectors. Defending against *all* of them is a deeply nontrivial task. Sometime take a look at the requirements for a SCIF: they're eye-opening. http://en.wikipedia.org/wiki/Sensitive_Compartmented_Information_Facility This attitute doesn't help though considering that we meanwhile face a situation in which it has become more or less impossible to build a system which is known non-compromised. It was always impossible. If you really want a known non-compromised system, you have to set up your own chip fab plant churning out low-transistor-count, hand-verified IC designs made from six-nines silicon you personally smelted from sand you personally mined off a beach. It has always been this way. It will always be this way. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: key generation: paranoia mode - explicit random input
On Wed, 26 Feb 2014 06:08, mailinglis...@hauke-laging.de said: I suggest to add a new key generation mode. The only difference would be that the random input is not read from /dev/random any more (and that random_seed would not be used or newly initialized) but from an explicit You may first want to read about Libgcrypt/GnuPG RNG. The Libgcrypt manual has a section on it. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: key generation: paranoia mode - explicit random input
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 NotDashEscaped: You need GnuPG to verify this message Hi On Wednesday 26 February 2014 at 5:33:55 AM, in mid:3046785.38M7boRugT@inno, Hauke Laging wrote: Whether the non-compromised key is generated by a compromised GnuPG is a different question and does not affect the security of the key itself! And if the compromised GnuPG then leaks the private key and the passphrase? -- Best regards MFPAmailto:2014-667rhzu3dc-lists-gro...@riseup.net Life is a holiday. In the same way that glass is a liquid. -BEGIN PGP SIGNATURE- iPQEAQEKAF4FAlMOVj1XFIAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5p0ZgEAI5nqpKNYFFsRtBbbPWSYSJdhmKfBEeJd98G H05SivKZBpJ7S0G7Fx0iFPV/k4CBstFlmVLjcqDlIgA1HqDl5rPENuOUdQAg1n6Q ZoyXvoL2RhNEucdkyvO2X8LcFEeyATOAaSDOs+3Qh+AEnyo2vW8mUuDNHqyB8IYD pwp3DQDY =e3m3 -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: key generation: paranoia mode - explicit random input
Am Mi 26.02.2014, 08:56:17 schrieb Werner Koch: You may first want to read about Libgcrypt/GnuPG RNG. The Libgcrypt manual has a section on it. I had a look at that but I am not sure what you want me to read. Could you be more precise about that? One thing came to my mind reading that: It may not be enough to redirect /dev/random as more entropy sources are used. I don't know though when they are used. Probably not for the generation of asymmetric and symmetric keys. It seems to me that in the worst case three different inputs have to be supplied (for the different quality levels). Hauke -- Crypto für alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 signature.asc Description: This is a digitally signed message part. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: key generation: paranoia mode - explicit random input
Am Mi 26.02.2014, 21:01:40 schrieb MFPA: And if the compromised GnuPG then leaks the private key and the passphrase? How is it going to do that if (a) it's running on an offline system and (b) its output is compared with that of other GnuPG versions? Hauke -- Crypto für alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 signature.asc Description: This is a digitally signed message part. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: key generation: paranoia mode - explicit random input
On 26/02/14 22:08, Hauke Laging wrote: How is it going to do that if (a) it's running on an offline system and (b) its output is compared with that of other GnuPG versions? Ultrasound, in combination with a nearby compromised online system with a microphone, for example. Your smartphone would be a pretty good candidate. Or through not-so-random padding on subsequent messages when the key is used, relying on you to bridge the air gap. It sounds to me like the age-old my system is compromised, but I still want to use GnuPG on it. I think you've heard the answer to that. HTH, Peter. -- 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
Re: key generation: paranoia mode - explicit random input
Am Mi 26.02.2014, 22:29:46 schrieb Peter Lebbing: Ultrasound, in combination with a nearby compromised online system with a microphone, for example. Trivial to prevent in comparison to the task of verifying a distro. It sounds to me like the age-old my system is compromised, but I still want to use GnuPG on it. I think you've heard the answer to that. This attitute doesn't help though considering that we meanwhile face a situation in which it has become more or less impossible to build a system which is known non-compromised. Your point is valid towards people who are just too lazy (or uninformed) to do what can be reasonably done. In that case a wish towards GnuPG could be simply replaced by improving the environment in which it is going to be used. My perspective is that what can be reasonably done at the system level may not be enough any more (at the upper border of requirements). Furthermore while you cannot fix security problems in the outer system by the inner system (which I assume is the main part of the answer you mentioned) please mind that this is not what I suggest. I want to enable users to create another layer of control outside their system. Thus I consider an improvement which is both easy to implement and easy to apply by the users a clear advantage. It is not enough to make ciphers and digests NSA-proof if that's not the attack vector they are going to use anyway. Hauke -- Crypto für alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 signature.asc Description: This is a digitally signed message part. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
key generation: paranoia mode - explicit random input
Hello, I just got asked: How do I know that GnuPG in distro XY is not compromised? The answer to this question is long and unpleasant. Thinking about that I had an idea – once more I can just hope it's new. One of the worst problems is that key generation might be compromised. I think this is the worst case because THEY would not even have to steal your key any more. And clever modifications to random data are hard to detect. I suggest to add a new key generation mode. The only difference would be that the random input is not read from /dev/random any more (and that random_seed would not be used or newly initialized) but from an explicit source: --random-source /path/to/file. With that (I guess very small) change every GnuPG installation should generate the same key material (of course, the timestamps would have to be given, too). Then people who need a very high level of security could create a pool of random data (e.g. by reading from /dev/random) and use this data and the same timestamps with different Linux distros, even with Windows. ;-) If the generated keys are exactly the same on all systems then it is very improbable that the key generation has been compromised (or all is lost anyway). This would be much easier (and thus available to normal people) than attempts to audit a distro. Hauke -- Crypto für alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 signature.asc Description: This is a digitally signed message part. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: key generation: paranoia mode - explicit random input
Am Mi 26.02.2014, 00:19:17 schrieb Daniel Kahn Gillmor: If i was an attacker who was compromising your software and i knew the software had this verification mode, i would make my modified software generate keys correctly when in this verification mode (clearly the software can tell when the entropy source is not /dev/random), and when it was not in this verification mode i would do my devious known-key generation. I thought about that when writing the mail but... So i don't see how this proposed change would let anyone sleep easier at night, unfortunately. ...I came to a conclusion quite different from yours: The aim is getting a non-compromised key. Whether the non-compromised key is generated by a compromised GnuPG is a different question and does not affect the security of the key itself! Of course, damage can be caused later: Clean asymmetric crypto doesn't protect against compromised session keys e.g. Thus such a feature should not be bound to key generation (would be even less work then). If this was a general switch the entropy source feature then checks could be applied to encryption and signing (not needed for RSA). Hauke -- Crypto für alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 signature.asc Description: This is a digitally signed message part. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: key generation: paranoia mode - explicit random input
On 02/26/2014 12:08 AM, Hauke Laging wrote: I suggest to add a new key generation mode. The only difference would be that the random input is not read from /dev/random any more (and that random_seed would not be used or newly initialized) but from an explicit source: --random-source /path/to/file. With that (I guess very small) change every GnuPG installation should generate the same key material (of course, the timestamps would have to be given, too). Then people who need a very high level of security could create a pool of random data (e.g. by reading from /dev/random) and use this data and the same timestamps with different Linux distros, even with Windows. ;-) If the generated keys are exactly the same on all systems then it is very improbable that the key generation has been compromised (or all is lost anyway). This would be much easier (and thus available to normal people) than attempts to audit a distro. If i was an attacker who was compromising your software and i knew the software had this verification mode, i would make my modified software generate keys correctly when in this verification mode (clearly the software can tell when the entropy source is not /dev/random), and when it was not in this verification mode i would do my devious known-key generation. So i don't see how this proposed change would let anyone sleep easier at night, unfortunately. --dkg signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
