key generation: paranoia mode - explicit random input

Doug Barton dougb at
Thu Feb 27 19:28:10 CET 2014

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.

Version: GnuPG v2.0.20 (GNU/Linux)


More information about the Gnupg-users mailing list