flat assembler
Message board for the users of flat assembler.

Index > Heap > Public Diffie-Hellman parameter generator (fasm of course)

Author
Thread Post new topic Reply to topic
redsock



Joined: 09 Oct 2009
Posts: 364
Location: Australia
redsock
Greetings all,

Been very busy over the last couple of months w/ client work, but in light of all of the recent Logjam discussions circulating, I decided to add my DH tool as a public/free service to 2ton.com.au, along with source to the generator/verifier/converter.

It can be used to update/replace DH parameters for any OpenSSL/OpenVPN/OpenSSH based installation, which is why I put the thread here instead of Linux Smile

Page and details of the service are at: https://2ton.com.au/dhtool/, source (linux x86_64 of course) is inside the HeavyThing library as usual.

Cheers!
Post 29 May 2015, 00:05
View user's profile Send private message Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3502
Location: Bulgaria
JohnFound
Interesting service. But with my very basic cryptography skills, I hardly can understand what is the purpose (except that it generates very big prime numbers). Is it useful for the usual user, or only for the OS maintainers and web server administrators?

Anyway, any use of assembly on the wide use, real life project and product must be acclaimed, because it raises the average quality of the Earth software. Smile
Post 29 May 2015, 16:39
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
redsock



Joined: 09 Oct 2009
Posts: 364
Location: Australia
redsock
JohnFound wrote:
...But with my very basic cryptography skills, I hardly can understand what is the purpose (except that it generates very big prime numbers)
Smile Most every server runs some form of remote access service, all of which are encrypted. This includes SSH servers, VPN servers, TLS/webservers, TLS chat servers, the whole gamut of encrypted goods. It is often problematic, especially for the conventional Discrete Logarithm based encryption methods (DHE for TLS, group-exchange for SSH, etc) to generate decent-sized replacement Diffie-Hellman parameters.

If you have access to a machine with openssl installed, run this command:
Code:
openssl dhparam 8192    
And let me know how long it takes to finish Smile Of course not many people actually use 8192 bit safe primes for normal operations (some do though). My clients maintain (as do I) a fairly decent number of remote servers, and it is nice to update them all periodically. Using the standard openssl dhparam tool, or ssh-keygen to do the deed means that at whatever periodic update frequency I want on my remote servers, they would all have to dedicate the CPU power to finding them, or I would have to come up with trusted update installation paths in order to propagate ones I generate locally, etc.

You get the idea, it is rather a pain in the backside, and always has been. For most operations, either 2048 bit or 4096 bit keys are in use, which aren't nearly as bad as 8192 bit, but the point remains... on the remote servers, my clients can issue a single "curl https://2ton.com.au/dhparam/4096 > newdhparam.pem" command and have recent/new semi-static encryption parameters all without dedicating cpu power or time themselves to the task.

SSH servers typically use a large-ish file "/etc/ssh/moduli", and since it must have multiple DH parameters, this is considerably more time consuming than generating a single one as above with openssl. Similarly, by accessing https://2ton.com.au/dhparam/4096/ssh people then can use the same curl syntax to replace an entire one of those too.

I dedicated 48 CPU cores to the task of constantly generating safe primes (1 cpu for 2048 bit, 3 cpus for 3072 bit, 8 for 4096 bit, and 36 for 8192 bit). I was surprised to find out last night that there is no large database of safe primes available, so maybe after it runs for a fair while I'll put up archives of them all Smile

Mostly though, anyone (windows or linux or mac os x) that does server-based encryption needs DH parameters and they are a pain to generate, hence the service.

I probably should have made it more clear that it was all written in assembly on its page, haha.

Tah for the acclamation, not sure it is warranted for such a service but at least a handful of people so far are happy I put the service up.

Cheers!
Post 29 May 2015, 21:55
View user's profile Send private message Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3502
Location: Bulgaria
JohnFound
redsock wrote:
If you have access to a machine with openssl installed, run this command:
Code:
openssl dhparam 8192    
And let me know how long it takes to finish Smile


Well, 32 minutes at 1GHz AMD 64bit. Not the fastest CPU in the world. Laughing

_________________
Tox ID: 48C0321ADDB2FE5F644BB5E3D58B0D58C35E5BCBC81D7CD333633FEDF1047914A534256478D9
Post 30 May 2015, 04:40
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
gens



Joined: 18 Feb 2013
Posts: 161
gens
Post 30 May 2015, 18:37
View user's profile Send private message Reply with quote
redsock



Joined: 09 Oct 2009
Posts: 364
Location: Australia
redsock
JohnFound wrote:
Well, 32 minutes at 1GHz AMD 64bit. Not the fastest CPU in the world. Laughing
Hah, well FWIW, it really is a "luck of the draw" exercise picking prime numbers like that... for grins I started three of the same openssl commands, one of which is still going (more than a full day now) looking for an 8192 bit safe prime...

Here're the times for the other two that did finish:

real 1139m52.042s
real 958m34.170s

heh, the third is STILL going... sometimes my generators get "lucky" and generate one inside a couple of minutes, but that is part of why the multiple CPUs dedicated to it help (that and my prime sieve process is far better than OpenSSL's), so that my average ends up about how long it took your CPU to do it Smile

You can appreciate the madness involved in any case..

This machine that I ran the same on is an Intel 3930K (getting a bit dated now but still plenty fast).

hehe, interesting and fun stuff aye?
Post 31 May 2015, 08:04
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17462
Location: In your JS exploiting you and your system
revolution
So is it safe to use publicly available primes for one's crypto parameters? If the NSA/GCHQ/MiB/Alien overlords/god is hacking your server and logging all the generated numbers does that mean that there is a DB of quick check values they can try when decrypting one's traffic?
Post 01 Jun 2015, 01:51
View user's profile Send private message Visit poster's website Reply with quote
redsock



Joined: 09 Oct 2009
Posts: 364
Location: Australia
redsock
revolution wrote:
So is it safe to use publicly available primes for one's crypto parameters? If the NSA/GCHQ/MiB/Alien overlords/god is hacking your server and logging all the generated numbers does that mean that there is a DB of quick check values they can try when decrypting one's traffic?
The all-seeing, all-knowing powers-that-be is Bruce Schneier, and his article on what nation-state budgets can do with the discrete logarithm problem is telling (heavy reading advisory, haha): https://www.schneier.com/blog/archives/2015/05/the_logjam_and_.html .. my hit on it and what I take away is: Most installations use public/well-known safe primes because doing "precomputation" against them was previously thought infeasible. Now we know that at least for <= 1024 bit safe primes, it is not only feasible, but well within a nation-state budget, and it allows for literally "passive decryption" (read: on the fly, may as well be plaintext).

BUT, and this is a big BUT, it only applies to long-standing static prime numbers, so my generation tool's update frequency for even 2048 bit primes is a new one every 2 to 3 minutes, precomputing a 2048 bit prime is not thought to be feasible in the first place, so as a matter of safety, if you never use the same prime for "very long", then said nation-state budget has to dedicate a huge array of supercomputing power _just to your prime_, and that is not going to happen.

Hehe, messy business I suppose. Lots of people seem to recommend moving away from conventional DLP/integer arithmetic and moving toward Elliptic Curve crypto (widely used of course, along with the Diffie-Hellman specific bits of EC too), but until Bruce Schneier retracts his statement about not trusting the US govt-issued curves, I am sticking to "conventional".

To answer your Q more succinctly, the Number Field Sieve technique for doing prime number "precomputation" is _very very expensive_, so for brief-use primes, no way can a nation-state precompute every prime it sees. The only reason people believe it is possible now is because so many actual static ones have been in use for many years, well enough time for them to do their precomputations and thus do passive decryption using same.
Post 01 Jun 2015, 02:01
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17462
Location: In your JS exploiting you and your system
revolution
So if the NSA/GCHQ/MiB/Alien overlords/god had a website similar to yours would it be safe to use their published numbers?
Post 01 Jun 2015, 02:08
View user's profile Send private message Visit poster's website Reply with quote
redsock



Joined: 09 Oct 2009
Posts: 364
Location: Australia
redsock
revolution wrote:
So if the NSA/GCHQ/MiB/Alien overlords/god had a website similar to yours would it be safe to use their published numbers?
Ahh, hehe, I forgot perhaps an important bit of the Diffie-Hellman scenario altogether... forgive me for being obtuse Smile

So, in the Diffie-Hellman key exchange process, it is _perfectly acceptable_ (and even required) that the prime modulus and generator be publicly known values. So in that regard, all primes (provided they meet the requirements as safe primes do) can be public for any length of time, and it is in fact a part of the deal. The wikipedia page on the DH problem itself ( http://en.wikipedia.org/wiki/Diffie–Hellman_problem ) spells it out pretty well.

So it is safe to use long-term public safe primes, with the proviso that your nation-state adversary can't do the precomputation against them reasonably. Frequent updating of the safe primes makes it ridiculously intractable, rather than just most-likely intractable. Smile

The DH parameters that my OpenSSH distribution uses for example is dated 2012, which is considerably older than my new-one-every-few-minutes generator, haha.

And really, if an adversary was generating safe primes, I don't think I'd be using their service.. jus' sayin' Razz
Post 01 Jun 2015, 02:19
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17462
Location: In your JS exploiting you and your system
revolution
redsock wrote:
And really, if an adversary was generating safe primes, I don't think I'd be using their service.. jus' sayin' Razz
Yes, indeed. Now all we need to do is be convinced that you are not an adversary and we're all good. So is it possible, even in principle, for anyone to convince another that they are not an adversary? Wouldn't generating our own numbers still be a better option overall because of that uncertainty.

I'm just playing devils advocate here. I'm sure you are not an adversary. But the hardware and OS you use cannot be given that same level of certainty.
Post 01 Jun 2015, 09:14
View user's profile Send private message Visit poster's website Reply with quote
redsock



Joined: 09 Oct 2009
Posts: 364
Location: Australia
redsock
revolution wrote:
So is it possible, even in principle, for anyone to convince another that they are not an adversary? Wouldn't generating our own numbers still be a better option overall because of that uncertainty.
Agreed, a part of the "nicety" I suppose of having done my dhtool in assembly language is that its codepath to verify I am not an adversary is actually pretty small (compared to OpenSSL, Botan, Crypto++, etc). In all of my running-at-the-mouth commentary I put on there I actually encourage people to verify the output of my service (as it is relatively easy to do).

At the end of whatever discourse is had about all security-related things though, IMO it is a question of what risk level you are comfortable with. If you are uber paranoid and require the strictest self-assurance that you are not dealing with adversarial code, then you are going to grab libraries like the one I built, and go through it piece by piece to verify it is okay and suits your risk level, or you will sit down and write it all yourself Smile (hmmm, what does that say about me then? hahah).

Being _able_ to review methods is not necessarily an easy option for many people though sadly, and trust is earned for sure.

Re: the OS adversary argument, I use Mac OS X for my primary desktop, and installed "Little Snitch", it is abso-unbelievable the sheer number of net requests the OS makes _constantly_ ... how anyone thinks that can possibly be a good thing I have no idea. Denying every last one of them and lo-and-behold, my OS doesn't display any visual warnings, and works otherwise just fine. Trust you say?

I like devil's advocate discussions Smile
Post 01 Jun 2015, 20:23
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on YouTube, Twitter.

Website powered by rwasa.