Updating key size - security related questions

2013-10-10 Thread int0x80
Hi,

I've been asking this on the OpenVPN mailinglist, but didn't get an answer so 
far. Therefore I hope you can help me.
We use OpenVPN in our company with the default cipher suite, which should be: 
DHE_RSA_BF_CBC_SHA

So RSA is used for authentication, Blowfish in CBC mode for symmetric 
encryption. The keys for Blowfish are derived from ephermal Diffie-Hellman and 
changed every hour.
We use a keysize of 1024 bit for RSA and therefore a modulus of 1024 bit for 
Diffie-Hellman (OpenVPN uses the Easy RSA scripts. These scripts use a variable 
KEY_SIZE when the Diffie-Hellman parameter or the RSA keys ar built. This 
variable is set to 1024). Furthermore we use a self-signed CA.

Some days ago I recommended to update the key size to 2048 bit, mainly because 
some sources say 1024 bit aren't enough anymore. Because quite a lot of our 
staff uses OpenVPN, they asked me, if it is possible, to not update all keys at 
once - but only issue user certs with 2048 from now on for new OpenVPN users 
(and leave the old ones in places for later update).
The process of doing that should look like that:

a) Change variable KEY_SIZE used in Easy RSA scripts from 1024 to 2048 (bit).
b) Create new Diffie-Hellman params with the Easy RSA build-dh script (will 
create the params with 2048 bit modulus).
c) Update the OpenVPN server config with the path of the new Diffie-Hellman 
param file.

Now here are my concerns and why _I_ think, that is a bad idea:
If I do it like that, new users would get 2048 bit keys/cert as requested by 
the company. But theses certs would still be signed by our self signed CA which 
still uses the old 1024 bit key/cert. Given that an attacker has enough 
computing power, he could factorize n (from the pub key in the CA cert) to 
get p and q. With that he would have our CA's private key, being able to 
create a faked server cert and sign it with the CA key. With that server 
certificate the attacker could launch a man in the middle attack. That would 
mean: Authentication via RSA would be leveraged.

So my question are:
I. Am I right, or is that rubbish?

II. Is an attacker able to get the CA cert at all? It looks as if during TLS 
handshake only the User certificate and the Server certificates are 
transmitted, but not the CA cert.

III. To complicate things a bit more:
OpenVPN supports a so called tls-auth directive which takes a 160 bit key. 
According to the OpenVPN documentation this key is used to generate a HMAC over 
every packet during TLS handshake (and append it?). It looks as if this is not 
part of TLS itself, but a modified implementation of TLS. They say, that 
without the key, not even the handshake would work.
So my last question is:
If the CA cert, can be requested from the OpenVPN Server somehow, that wouldn't 
work anymore, if such a key is used. Is that correct?

Thanks a lot for your help!
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org


Re: [openssl-users] Updating key size - security related questions

2013-10-10 Thread Erwann Abalea

Bonjour,

Le 10/10/2013 18:29, int0...@safe-mail.net a écrit :

Hi,

I've been asking this on the OpenVPN mailinglist, but didn't get an answer so 
far. Therefore I hope you can help me.
We use OpenVPN in our company with the default cipher suite, which should be: 
DHE_RSA_BF_CBC_SHA

So RSA is used for authentication, Blowfish in CBC mode for symmetric 
encryption. The keys for Blowfish are derived from ephermal Diffie-Hellman and 
changed every hour.


Make sure you don't encrypt more than 2^35 bytes with the same BF key. 
Otherwise, you have an additional problem.



We use a keysize of 1024 bit for RSA and therefore a modulus of 1024 bit for 
Diffie-Hellman (OpenVPN uses the Easy RSA scripts. These scripts use a variable 
KEY_SIZE when the Diffie-Hellman parameter or the RSA keys ar built. This 
variable is set to 1024). Furthermore we use a self-signed CA.

Some days ago I recommended to update the key size to 2048 bit, mainly because 
some sources say 1024 bit aren't enough anymore. Because quite a lot of our 
staff uses OpenVPN, they asked me, if it is possible, to not update all keys at 
once - but only issue user certs with 2048 from now on for new OpenVPN users 
(and leave the old ones in places for later update).
The process of doing that should look like that:

a) Change variable KEY_SIZE used in Easy RSA scripts from 1024 to 2048 (bit).
b) Create new Diffie-Hellman params with the Easy RSA build-dh script (will 
create the params with 2048 bit modulus).
c) Update the OpenVPN server config with the path of the new Diffie-Hellman 
param file.

Now here are my concerns and why _I_ think, that is a bad idea:
If I do it like that, new users would get 2048 bit keys/cert as requested by the company. But theses certs would still 
be signed by our self signed CA which still uses the old 1024 bit key/cert. Given that an attacker has enough computing 
power, he could factorize n (from the pub key in the CA cert) to get p and q. With 
that he would have our CA's private key, being able to create a faked server cert and sign it with the CA key. With 
that server certificate the attacker could launch a man in the middle attack. That would mean: Authentication via RSA 
would be leveraged.


As in broken? Yes.


So my question are:
I. Am I right, or is that rubbish?


You're right. On the other side, how powerful are your opponents? 1024 
bits factorization isn't an easy task, it requires a large amount of 
money. Large isn't a precise number, for sure; I'd place the lower 
limit at 1M$. But don't trust me.



II. Is an attacker able to get the CA cert at all? It looks as if during TLS 
handshake only the User certificate and the Server certificates are 
transmitted, but not the CA cert.


A public key isn't designed to be kept private. Given some certificates 
signed by the same private key, the modulus of the signer key can be 
guessed.

Consider your CA modulus to be public.


III. To complicate things a bit more:
OpenVPN supports a so called tls-auth directive which takes a 160 bit key. 
According to the OpenVPN documentation this key is used to generate a HMAC over every 
packet during TLS handshake (and append it?). It looks as if this is not part of TLS 
itself, but a modified implementation of TLS. They say, that without the key, not even 
the handshake would work.
So my last question is:
If the CA cert, can be requested from the OpenVPN Server somehow, that wouldn't 
work anymore, if such a key is used. Is that correct?


It depends on how this key is used. I don't have any opinion on this point.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org