[Openvpn-users] Diffie Hellman

[J***@mindef.nl]

Hi all,

Once in a while it is handy to review all you've been doing and wonder if what you do it is still wise, or you are just giving yourself a false sense of security.
One of the things that kept me awake was the diffie-hellman-parameter.

I (like probably a lot of people around here) just used the info from the man-pages or how2 to get a properly working openvpn and I took a precaution to use a longer DH (2K in stead of the default 1K).
But I noticed that my co-workers are still using the same DH I made several years ago.

So I wonder

a) What kind of length is supposed to be safe (presume 2K is still good and fast enough to generate)

b) Should one use different DH's for each vpn-process

c) How often should one re-new the DH? (never, yearly, monthly, weekly, at boot-time, at process-start-up?

Is it wise to tighten up, or am I victim of snowdon-paranoia :)

And before mentioning it, I did read:
http://security.stackexchange.com/questions/42415/openvpn-dhparam
http://security.stackexchange.com/questions/38206/can-someone-explain-a-little-better-what-exactly-is-accomplished-by-generation-o/38207#38207
http://security.stackexchange.com/questions/38206/can-someone-explain-a-little-better-what-exactly-is-accomplished-by-generation-o/38252#38252

hw

______________________________________________________________________
Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het electronisch verzenden van berichten.

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages.

[David Sommerseth]

Post by J***@mindef.nl
Hi all,

Hi,

I dare to answer this, even though I'm no cryptologist. For those who
see I'm wrong, please correct me! But I don't think I'm that far from
reality.

Post by J***@mindef.nl
Once in a while it is handy to review all you’ve been doing and
wonder if what you do it is still wise, or you are just giving
yourself a false sense of security.
One of the things that kept me awake was the
diffie-hellman-parameter.
I (like probably a lot of people around here) just used the info
from the man-pages or how2 to get a properly working openvpn and I
took a precaution to use a longer DH (2K in stead of the default
1K).
But I noticed that my co-workers are still using the same DH I
made several years ago.
So I wonder
a) What kind of length is supposed to be safe (presume 2K is
still good and fast enough to generate)
b) Should one use different DH’s for each vpn-process
c) How often should one re-new the DH? (never, yearly,
monthly, weekly, at boot-time, at process-start-up?
Is it wise to tighten up, or am I victim of snowdon-paranoia J
http://security.stackexchange.com/questions/42415/openvpn-dhparam
http://security.stackexchange.com/questions/38206/can-someone-explain-a-little-better-what-exactly-is-accomplished-by-generation-o/38207#38207

The
answers by tylerl, is pretty much exact, how I understand this
topic. And there really isn't much secrecy regarding the DH params.
It is basically just prime numbers, not any direct keying material.

Post by J***@mindef.nl
http://security.stackexchange.com/questions/38206/can-someone-explain-a-little-better-what-exactly-is-accomplished-by-generation-o/38252#38252

Thomas
Pornin seems to just confirm tylerl here, as well. It makes
sense to me, what he says.

IIRC, the only important thing here is the length of the DH
parameters. To be able to get a certain length of the temporary keys,
which the DH key exchange is all about, you need a certain length of
the DH parameters. Otherwise, it gets easier to crack the temporary key.

Generally, I'd say 2048 should in most cases be more than fine enough.
You might want to consider 4096 if you are paranoid. And if you have
plenty of spare CPU cycles, you can always generate higher ones. But
I'd say that's more waste of energy than enhancing the encryption.

You may decide to replace your DH parameters every now and then, but I
doubt it's really a need to do so too frequently or to even schedule
it regularly. I don't recall the SSL/TLS wire protocol now, but IIRC,
the DH parameteres passes in clear text over the wire during the key
exchange.

What is going to be far more interesting in the (nearer) future, is
the Elliptic Curve (EC) cryptography. There are some work to adopt
OpenVPN to support it, OpenSSL and PolarSSL have added support to it
too. But the tricky part with EC, is that the cryptographic safety is
depending on the curve algorithm used. The EC implementations are
more like a framework, but both OpenSSL and PolarSSL ships with
pre-implemented curves (and they will probably add more in the future
too) so you don't have to configure all that magic yourself - as doing
it wrong will result in really poor keys.

But having all this said. The key importance for all crypto is to
have proper random data. If you don't have any good RNGs in hardware,
you do need some entropy gathering process which can help seeding the
RNGs. And this means that you really shouldn't create any keys on
embedded devices, as their entropy sources for the RNGs are poor.
Also be careful when creating keys in virtualized environments, some
environments provides poor entropy to the the virtualized hosts as well.


- --
kind regards,

David Sommerseth

[J***@mindef.nl]

See below

-----Original Message-----
From: David Sommerseth [mailto:***@topphemmelig.net]
Sent: dinsdag 28 januari 2014 13:01
To: Witvliet, J, DMO/OPS/I&S/HIN; openvpn-***@lists.sourceforge.net
Subject: Re: [Openvpn-users] Diffie Hellman

Post by J***@mindef.nl
Hi all,

Hi,

I dare to answer this, even though I'm no cryptologist. For those who see I'm wrong, please correct me! But I don't think I'm that far from reality.

Post by J***@mindef.nl
Once in a while it is handy to review all you've been doing and wonder
if what you do it is still wise, or you are just giving yourself a
false sense of security.
One of the things that kept me awake was the diffie-hellman-parameter.
I (like probably a lot of people around here) just used the info from
the man-pages or how2 to get a properly working openvpn and I took a
precaution to use a longer DH (2K in stead of the default 1K).
So I wonder
a) What kind of length is supposed to be safe (presume 2K is
still good and fast enough to generate)
b) Should one use different DH's for each vpn-process
c) How often should one re-new the DH? (never, yearly,
monthly, weekly, at boot-time, at process-start-up?
Is it wise to tighten up, or am I victim of snowdon-paranoia J
http://security.stackexchange.com/questions/42415/openvpn-dhparam
http://security.stackexchange.com/questions/38206/can-someone-explain-
a-little-better-what-exactly-is-accomplished-by-generation-o/38207#382
07

The

answers by tylerl, is pretty much exact, how I understand this topic. And there really isn't much secrecy regarding the DH params.
It is basically just prime numbers, not any direct keying material.

Post by J***@mindef.nl
http://security.stackexchange.com/questions/38206/can-someone-explain-
a-little-better-what-exactly-is-accomplished-by-generation-o/38252#382
52

Thomas
Pornin seems to just confirm tylerl here, as well. It makes sense to me, what he says.

IIRC, the only important thing here is the length of the DH parameters. To be able to get a certain length of the temporary keys, which the DH key exchange is all about, you need a certain length of the DH parameters. Otherwise, it gets easier to crack the temporary key.

Generally, I'd say 2048 should in most cases be more than fine enough.
You might want to consider 4096 if you are paranoid. And if you have plenty of spare CPU cycles, you can always generate higher ones. But I'd say that's more waste of energy than enhancing the encryption.

You may decide to replace your DH parameters every now and then, but I doubt it's really a need to do so too frequently or to even schedule it regularly. I don't recall the SSL/TLS wire protocol now, but IIRC, the DH parameteres passes in clear text over the wire during the key exchange.

What is going to be far more interesting in the (nearer) future, is the Elliptic Curve (EC) cryptography. There are some work to adopt OpenVPN to support it, OpenSSL and PolarSSL have added support to it too. But the tricky part with EC, is that the cryptographic safety is depending on the curve algorithm used. The EC implementations are more like a framework, but both OpenSSL and PolarSSL ships with pre-implemented curves (and they will probably add more in the future
too) so you don't have to configure all that magic yourself - as doing it wrong will result in really poor keys.

But having all this said. The key importance for all crypto is to have proper random data. If you don't have any good RNGs in hardware, you do need some entropy gathering process which can help seeding the RNGs. And this means that you really shouldn't create any keys on embedded devices, as their entropy sources for the RNGs are poor.
Also be careful when creating keys in virtualized environments, some environments provides poor entropy to the the virtualized hosts as well.

David Sommerseth

========================================================================================================
Hi David,

You are right, the DH is just a safe way for transporting keys, by means of prime-numbers (or curves). So the longer they are: the better.
But eventhough when using a decent length, when using them very intensively for years, what are they still worth...

With regards to the generation time, I just tried some out:
DH group2 group5
512 0.4s 1,5s
1024 3.5s 30s
2048 99s 5min
4096 13min 30min
And when doing this virtualized, quite a bit longer ;-)

Might seem long, but 5 minutes for a 2K-group-5 DH, if you only need to do this every 3 months or so, should not pose such a burden.
And probably, it will take longer for other groups (14 ..24)
As long as it does not have significant impact upon the creation of a vpn tunnel....

I saw some traffic about ECDH, and tried to generate some of them, and it seems that even one of the longest, sect571, is taking up just 0.022 second.
(time openssl ecparam -genkey -out sect571r1.pem -name sect571r1)
Would be nice if openvpn can work with these ECDH's

Hw

______________________________________________________________________
Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het electronisch verzenden van berichten.

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages.

[David Sommerseth]

On 28/01/14 14:13, ***@mindef.nl wrote:
[...snip...]

Post by J***@mindef.nl
You are right, the DH is just a safe way for transporting keys, by
means of prime-numbers (or curves). So the longer they are: the
better. But eventhough when using a decent length, when using them
very intensively for years, what are they still worth...

As the DH is a public factor ... I struggle to see how long time usage
will impact it. The only parts of DH params is sent to the client (in
clear text) when it connects as part of the key exchange, before the
encryption has been established. So if your concerned about the
integrity of the temporary encryption keys, the DH param isn't really
that much valuable. It's a big prime number, and not even guaranteed
to be unique.

Something which might help shed more light on how SSL/TLS works:
<http://www.sans.org/reading-room/whitepapers/authentication/ssl-tls-whats-hood-34297>

Post by J***@mindef.nl
With regards to the generation time, I just tried some out: DH
group2 group5 512 0.4s 1,5s 1024 3.5s 30s
2048 99s 5min 4096 13min 30min And when doing this
virtualized, quite a bit longer ;-)

Yeah, this isn't atypical numbers. Group5 takes longer, as it has to
find more prime numbers than group2.

Post by J***@mindef.nl
Might seem long, but 5 minutes for a 2K-group-5 DH, if you only
need to do this every 3 months or so, should not pose such a
burden. And probably, it will take longer for other groups (14
..24) As long as it does not have significant impact upon the
creation of a vpn tunnel....

It is possible to have "dynamically created DH params" for each
connection, but it's not widely used as you basically want 2048 bits,
and establishing an SSL/TLS connectio would then take almost 2 minutes.

Post by J***@mindef.nl
I saw some traffic about ECDH, and tried to generate some of them,
and it seems that even one of the longest, sect571, is taking up
just 0.022 second. (time openssl ecparam -genkey -out sect571r1.pem
-name sect571r1) Would be nice if openvpn can work with these
ECDH's

It's coming :) ... if you want to help out testing it, please pay
attention to the openvpn-devel list. You can get more info by joining
our #openvpn-devel IRC channel on FreeNode as well ... currently
patches are under development/review, iirc.


- --
kind regards,

David Sommerseth