Increasing key size from 1024 to 2048?
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
Updating key size - security related questions
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: seed/$RANDFILE confusion
> On computers that don't have a good /dev/*random, the randomness used
> by OpenSSL comes only from things happening on the computer during the
> few moments when the openssl tool is running. To gather up more
> randomness, the openssl tool tries to accumulate randomness over
> multiple runs as follows:
>
> 1. At the end of each run that used the random number generator,
> write a file of random bits (computed so they have a lot of entropy but
> do not reveal any of the random numbers already generated).
>
> 2. At the start of each such run, read in that file and use it as an
> initial pool of random bits to be mixed with any random system activity
> observed during the run.
Thanks for the explanation, that clarified things!
How does the OpenSSL tools know if /dev/{random,urandom} is "good"?
> So the seed written to ${HOME}/.rnd is supposed to stay around until the
> next time you run the openssl tool, and reveals very little about keys
> you alredy created. But it may reveal something about the next key you
> create, which is why the file is/should be written with permissions so
> only you can read it.
I saw some people getting their randomness from /dev/random via
dd if=/dev/random of=/root/.rnd... and using the -rand parameter to give
the seed to openssl. If I got you right, that is a redundant step, since
OpenSSL
takes its randomness from /dev/random as well. Using -rand would only be
necessary
if one has a hardware random number generator (for example). Is that right?
So my to go would be:
Set $RANDFILE to /root/.rnd and leave it up to openssl to use the file,
without filling it myself. I only need to make sure the permissions are set
correctly. Is that right?
> Now why OpenSSL keeps doing this on platforms with a good OS random
> source (such as non-historic Linux versions, some BSDs, recent Solaris
> versions, non-historic Windows versions) is a mystery to me.
Can somone else bring some light into this?
Thank you very much Jakob!
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
seed/$RANDFILE confusion
Hi, If I try to create Diffie-Hellman key parameter (OpenSSL 1.0.0) via openssl dhparam -out $KEY_DIR/dh1024.pem 1024 I get the following output: "Generating DH parameters, 1024 bit long safe prime, generator 2 This is going to take a long time .+. [...] unable to write 'random state'" I get the error since neither $HOME nor $RANDFILE is set. So if I do an export RANDFILE=/root/.rnd the command above works and I don't get an error. Now I have several questions: 1. Why do I need to specify the path to the seed (RANDFILE) if I don't provide the seed (I dont use the -rand option.)? /root/.rnd doesn't exist before I run the command. After I ran the openssl command it is created under /root/.rnd and contains the seed (or is this something else?). 2. If openssl creates the file on his own, why doesn't it delete if after the DH key parameter were created? Isn't it a security risk if one doesnt delete the seed, since an attacker could generate exactly the same key parameter if he would get access to the seed? [1] http://www.openssl.org/support/faq.cgi#USER2 Thanks! __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Missing entries in index.txt database - Generating CRL
Hi, [...] > > After that I generated a CRL (I own the CA) which then contained the > > certificate with the serial 0x06. > > > > My question now is, would that be a proper workaround or is there a better > > solution? Since the CRL > > only contains the serial numbers of the certificates, this seems to work > > although it is not a very good > > solution. > It is a workaround if you consider the "ca" and "crl" commands as > the only officially blessed way to manage certificats,. just because it > looks convenient at first glance. > > You may consider not to use the "ca" command at all, generate certs > using "x509" instead, manage their status in whatever database you like > and, in order to create a crl using "crl", you just create a temporary > file with the R entries, etc. > You may even go further and not use "crl" at all but create an asn.1 > input for "asn1parse", I leave this idea as an exercise .. > > in other words, once you have understood that you only need some > file that has "R"s and numbers, ... your mind should be > free to create them in any way you want. Thanks for your help, that clarified things! Martin __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Missing entries in index.txt database - Generating CRL
Hi, I have a index.txt database where all the "R" (revoked) and "E" (expired) lines were removed, only the "V" (valid) entries are left. When I generate a new CRL it doesn't contain any certificates since this process parses the database and can't find any revoked certificates. The problem now is, that I need a proper CRL. That's why I tried the following: Every database entry looks like that: V200807100345Z05unknown/C=--/ST=Statebla/L=Citybla/O=Orgbla/OU=OrganizationalUnitbla/CN=foo/emailAddress=foo@somehostname The 4th column contains a serial number which is incremented by 0x01 everytime a new certificate is added. If I find a gap in the serial numbers in two consecutive database entries, I just fill this missing entry with a dummy revoke entry. Example: I have a database which contains those two consecutive entries. The first has the serial 0x05, the second 0x07. The entry with the serial 0x06 is missing, since it was an "R" or "E" entry and someone deleted it. ... V200707100345Z05unknown/C=--/ST=Statebla/L=Citybla/O=Orgbla/OU=OrganizationalUnitbla/CN=user1/emailAddress=user1@somehostname V200907100345Z07unknown/C=--/ST=Statebla/L=Citybla/O=Orgbla/OU=OrganizationalUnitbla/CN=user3/emailAddress=user3@somehostname ... Now I would add and entry to the database, so that the database looks like that: ... V200707100345Z05unknown/C=--/ST=Statebla/L=Citybla/O=Orgbla/OU=OrganizationalUnitbla/CN=user1/emailAddress=user1@somehostname R200807100345Z200807100345Z06unknown/C=--/ST=Statebla/L=Citybla/O=Orgbla/OU=OrganizationalUnitbla/CN=dummy1/emailAddress=dummy1@somehostname V200807100345Z07unknown/C=--/ST=Statebla/L=Citybla/O=Orgbla/OU=OrganizationalUnitbla/CN=user3/emailAddress=user3@somehostname ... After that I generated a CRL (I own the CA) which then contained the certificate with the serial 0x06. My question now is, would that be a proper workaround or is there a better solution? Since the CRL only contains the serial numbers of the certificates, this seems to work although it is not a very good solution. Thanks for your help, Martin __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
