increase from 2048 to 4096 bits

[dylanmtaylor]

You might want to cherry pick out the README change, but I feel 2048 might be too weak for today's crypto standards

[Stsosz]

This sounds great. Exactly what I was trying to do with my install. 2048 bits is waaaay too small for modern standards.

[stefancrain]

@dylanmtaylor nice work, might be worth taking a look #23.

[dylanmtaylor]

I could easily write a bit of code to prompt for the bit size, it's not overly complicated to do, but I definitely think 4096 should be the default. 8192 seems a bit overkill in my opinion. Is there much demand for the feature?

[stefancrain]

@Stsosz and @dylanmtaylor I'm NOT the maintainer but it seems to me that this community has differing ideas RE: a safe key-bit length. I think that a prompt would be a good addition, but that may just be me.

From my point of view it would be a nessisity to add a section in the README about key length. Here's a few links I've found, it's not at all complete but just a little research I've done today.

• May, 2015, OpenVPN.net has a section on hardening

  Up to 4096-bit is accepted by nearly all RSA systems (including OpenVPN,) but use of keys this large will dramatically increase generation time, TLS handshake delays, and CPU usage for TLS operations; _the benefit beyond 2048-bit keys is small enough not to be of great use at the current time. It is often a larger benefit to consider lower validity times than more bits past 2048, but that is for you to decide._

• Feb 2015, Torrentfreak.com VPN Service Provider Review

  Key Length	Used as standard length	Total mentions
  1024	0	0
  2048	12	18
  4096	13	18
  8192	0	0

• July 2012, US National Institute of Standards and Technology Recommendation for Key
  Management

  2048 bits will be sufficient for commercial use until around the year 2030. p69,70

Obviously this is just a start and we can draw our own conclusions, but it seemed like a good unbiased set of data to me.

[jamesrascal]

@stefancrain you would be correct. The idea of this script is to provide users with a quick and easy way to setup a VPN server. The security customizations are sometying that the end user can do after everything is installed should they choose.

Adding an additional option during the install while a good idea for the advance users add more complexity to the script which may discourage some new users.

Keeping it simple and easy is what this script is setup to do.

[dylanmtaylor]

I feel it should stay simple but use hardened security. 4096 bits isn't too much overhead, and is more secure. There is little downside for personal use and use with a small number of clients

[stefancrain]

@jamesrascal totally agree with you - maybe this could be solved with a set of instructions?

Here's another source, this time from the EU.

• Oct 2013, European Union Agency for Network and Information Security

We have focused on 128 bit security in this document for future use recommendations; clearly this offers a good long term security gaurantee. (RSA 2048 = 112 bit) p35
It would seem prudent that only legacy applications should use 1024 bit RSA modulus going forward, and that future systems should use RSA keys with a minimum size of 3072 bits. p31

Legacy	Near Term (10+ years)	Long Term (30-50 years)
1024	3072	15360

[Nyr]

@Stsosz: 2048 bits is waaaay too small for modern standards.

Prove why.

@dylanmtaylor isn't too much overhead

Just a quick test on a DigitalOcean VPS:

root@test:/etc/openvpn/easy-rsa/2.0# time /etc/openvpn/easy-rsa/2.0/build-dh
Generating DH parameters, 2048 bit long safe prime, generator 2
This is going to take a long time
................................................................................................+...................+.................................................................................................................................................................................
[...]
.......................+....................................................................................+.........+.............................................+............++*++*

real    3m37.371s
user    3m35.396s
sys 0m0.912s
root@test:/etc/openvpn/easy-rsa/2.0# 


root@test:/etc/openvpn/easy-rsa/2.0# time /etc/openvpn/easy-rsa/2.0/build-dh
Generating DH parameters, 4096 bit long safe prime, generator 2
This is going to take a long time
..............................................+...........................+.......+.......................................................................................+...........................................................................................................................
[...]
..............................................+...............................................................................................................................++*++*

real    19m44.100s
user    19m37.156s
sys 0m1.480s

@dylanmtaylor: I definitely think 4096 should be the default

Convince the OpenVPN devs about it and the script will use it by default in its current form.

[Stsosz]

Uh... That second quote was not by me... @Nyr

[dylanmtaylor]

2048 is the minimum that should be acceptable anywhere. Debian is forbidding 1024 bit keys for instance (source: https://lists.debian.org/debian-devel-announce/2010/09/msg00003.html) If a way to crack 2048 bit keys is discovered, it will still take a sufficiently long time to crack a 4096 bit key. I do not find 20 minutes to generate the primary key on a low-end VPS completely unacceptable. It only has to be done once, and after that, adding user certs takes only a few seconds (tested on bare metal). I strongly feel that your security is worth 15 minutes of your time.

[Nyr]

@Stsosz sorry, fixed.

@dylanmtaylor: 2048 is the minimum that should be acceptable

I agree, that's why it's the default currently.

@dylanmtaylor: I do not find 20 minutes to generate the primary key on a low-end VPS completely unacceptable

Neither do I, but DigitalOcean is not a low-end service, more like middle class. On low-end OpenVZ services with a slow CPU, users could even be suspended during setup if I switched to generating 4096 bit keys and if not, it could still take more than an hour. Not to mention a Raspberry Pi or something like that.

@dylanmtaylor: I strongly feel that your security is worth 15 minutes of your time.

I do too, but I feel like shorter keys provide a good balance between performance and security, which is the same position held by the OpenVPN developers. And remember, longer key lengths do not only affect performance during key generation.

[dylanmtaylor]

What if I were to code in an option that the user selects? For instance

Would you like to upgrade to using a 4096-bit RSA key [Y/n]? n

[Nyr]

No, because:

• The script is a "road warrior" installer. If your adversary potentially has the capacity to crack 2048 bit keys in a reasonable amount of time, your threat model shouldn't include this script.
• One prompt wouldn't explain the implications to the user. I don't really consider it an upgrade, certainly not on the performance side.
• There are ZERO practical security benefits on using longer keys at this time. There are some serious disadvantages which proponents for the change seem to ignore.
• Someone would later want to add a prompt to change the cipher too. Same implications as with this: decreased performance and confused users.
• I am not a commercial VPN provider selling a false sense of privacy or security to my users. They need to implement longer keys because paranoid customers with little technical knowledge ask them. They are in the business of selling bullshit, I am not.

TL;DR: longer keys have little/no benefits for the OPSEC of the users. I understand there are differing opinions on this matter, but I prefer to respect the default OpenVPN settings which were selected by very capable people and will probably be considered secure for the next 10+ years. Forks about this are welcome but will not be merged at this point.