jstedfast
commented
6 years ago For key generation, I didn't seed either of the 2 places where I use the SecureRandom class:
https://github.com/jstedfast/MimeKit/blob/master/MimeKit/Cryptography/OpenPgpContext.cs#L1040 and https://github.com/jstedfast/MimeKit/blob/master/MimeKit/Cryptography/OpenPgpContext.cs#L1070
but I could... actually, I should probably re-use the same SecureRandom context for both places.
Ideally, I'd say that BC's default SecureRandom should be good enough, but this reminded me of an email by Edward Ned Harvey on the BouncyCastle mailing list that I read a while back (posted here since it's easier than linking to the mail thread):
The default constructor of SecureRandom uses GetSeed(8), which is only 64 bits, but worse yet, GetSeed seeds itself from the system clock Ticks.
There are 10million ticks per second, and a single laptop CPU core can perform between 10million and 200million AES operations per second, depending on hardware acceleration, clock speed, and how efficient the software library is. This means, suppose you used SecureRandom() to generate an AES key, a completely unsophisticated brute force attacker could guess your key in a period of time that's less than the precision he has on guessing when you created your key. If he knows when you generated it +/- 12 hours, then he would expect to require something between 0.5 and 12 hours to guess your key, divided by the number of CPU cores he has available.
Even if an attacker had no idea when you generated some key, it's still limited to 64 bits, which is just nowhere near good enough.
Even if you're aware of this, and you painstakingly and consistently use things like ThreadedSeedGenerator to seed the SecureRandom, there are tons of places where SecureRandom() is used internally by Bouncy Castle. By searching code, I see 526 references. I discovered this today, because I painstakingly created strong random to seed my ECKeyPairGenerator, and then signed & verified data, only to discover that the insecure SecureRandom() is used internally by ECDSASigner.
So the questions I have are ... What to do about it.
Option 1: More education to the users. Response: I see code examples all over the internet, where people advise each other to use SecureRandom and expect it to be secure, as the name implies. So the idea of just educating people on proper usage and expectations is unrealistic. The name "SecureRandom" in a widely trusted crypto library such as Bouncy Castle is important and meaningful.
More importantly, SecureRandom() is used internally by Bouncy Castle. Which underscores the futility of "user education" as the solution. As described above, I painstakingly ensured I used good random, only to find it undermined internally by ECDSASigner.
Option 2: Instead of seeding SecureRandom from system time, seed it from ThreadedSeedGenerator, or better yet, a combination of the two, or better yet, pull from both of those sources plus the OS crypto API and everything else available to provide seed material.
In fact, that's what we're doing in TinHat Random. http://tinhatrandom.org If the solution is to seed SecureRandom from a bunch of different sources, then I would like to see TinHat Random folded into the source of Bouncy Castle. Which might be easier said than done, given the Java / C# duality.
Also, there might be some logistical difficulties, compatibility with different system types, different OSes with different threading models, etc. I would be brazen to assume there always exists an OS crypto API on every platform where BC gets used. Not to mention, the assumption that ThreadedSeedGenerator is valid to use. Which is another big assumption.
Option 3: I am rather expecting to hear a lot of "can't" in response to Option 2. But I am working for an employer who is planning to use BC for secure communications, and I cannot afford to deliver "can't" as my answer. So I am estimating probably my response will be forced, to fork BC, and fold TinHat Random into it, to make it suitable for my employer's purposes. And I'll have to go around promoting my fork to application developers, etc. But I'm hoping for a more graceful integration process somehow that doesn't result in fragmentation of community or development efforts.
Other options? Ideas? Comments?
Thanks... PS, I love BC and as always, thanks to everyone who contributed and contributes to it.
The website now seems to be a blank page, but the github repo for tinhatrandom is https://github.com/Vanaheimr/tinhat/tree/master/tinhat
Looking at more recent code, it seems to seed itself using a counter value and 32 bytes of data from RNGCryptoServiceProvider that then gets hashed using SHA256.
I honestly don't know if that is secure enough, though. If not, perhaps I can add an optional SecureRandom argument to the current CreateKeyPair() method.
As far as the AutoKeyRetrieve thing, you just need to set the URL of a KeyServer on the OpenPgpContext. By default, the AutoKeyRetrieve and KeyServer options are populated using the user's gpg.conf file.
For example, I have:
keyserver hkp://keys.gnupg.netIn code, it would just be something like:
ctx.KeyServer = new Uri ("hkp://keys.gnupg.net");
ctx.AutoKeyRetrieve = true;
polterguy
I have (finally) set aside time to refactor my usage of MimeKit in Phosphorus Five, which was long overdue may I add, and I started looking at some of your Open PGP convenience methods - And all I've got to say is wow! It's almost an entirely new library. Gr8 work! :)
However, I have some questions. First of all, obviously I want to use as many of your convenience methods as possible. I do however have this "super paranoid" implementation of creation of PGP keys, where I allow for manually salting the SecureRandom thing, in addition to providing other overrides, such as expiration date, bit strength, etc. How much work have you put into this method? Obviously, the nightmare scenario would be some adversary being able to predict the RNG ...?
Hence, I am reluctant to using this specific method, without knowing what it actually does, and how secure it is ...
Another method I saw, where my jaw simply dropped, was the "AutoImportFromKeyServer" thing. Wow!! I've been fiddling with this myself, and I realise just how much work doing that is. How do I use it though ...?
Do you have some sample code laying around for providing a key server, etc ...?
It really feels almost like an entirely new library though, as I started browsing through your methods. Thx a billion times Jeffrey :)