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
