Saturday, March 22, 2014

Using the RSA Algorithm for Encryption and Signatures

During performance testing DSA is actually faster during signature generation, but slower during the validation process. Suprised? The title of this article is not misleading. With DSA it is also slightly slower when encrypting, but faster when decrypting data so security here is very close to RSA at equal key lengths.

However, since the RSA algorithm is based on the idea that large integer factorization is "difficult". Within the DSA security mechanism is an example of the discrete logarithm problem. ECDSA utilizes elliptic curve cryptography in a variant of DSA.

There is no clear winner. However, we can remember that the NIST Special Publication 800-57 (Jul 2012) recommends 2048-bit private keys. This will be important later, as it will be a factor which will elucidate the reasons for my recommendation.

If you have OpenSSL installed on your machine, you may execute :

openssl speed

You will see that the statements discussed in this article are true. Except that we did not mention that verification is what you want to be the fastest. The signature only happens once, but the verification happens an indefinite number of times. RSA also supports out of the box encryption, whereas DSA is dependent on third party encryption and is slower here as well.  However, DSA is faster at decrypting so we are still only tipping the scale a tiny bit.

However, for commercial entities considering organizational security policies which will last into the future should consider RSA or ECDSA. Overall RSA is clearly the winner for the moment, even though ECDSA is actually computationally lighter than all three it is not traditionally supported (RFC 4251) for SSH. Also, being a young encryption algorithm; it has had some serious critical vulnerabilities in the recent past. Most professionals are steering away from using this type of key for the time being.

In commercial terms, RSA is clearly the winner, commercial RSA certificates are much more widely deployed than DSA certificates.

Now we reach the final decision. A DSA key has to contain a 1024-bit keystrength in order to comply with NIST FIPS 186-2.  Unfortunately, while longer DSA keys are possible (FIPS 186-3) ssh-keygen restricts you to 1024 bits. When you take this article into consideration, we are no longer able to reasonably secure data with 1024-bit keys for either RSA or DSA.

Managing Digital RSA keys for SSH

Now each organization must ask itself roughly about: digital key creation and expiration. Does the client create the key pair? All the private keys have a passphrase? If so, what's the minimum length? Do the keys expire? What types of keys are allowed/accepted? The private keys can be copied and then cracked so these are all things to keep in consideration. In the IT world, it is important to stay abreast of security and on ahead of new vulnerabilities.

Passphrases that have also few (or too easily guessed) alphanumeric characters (including spaces) don't last. Changing the password in one private key doesn't changes it in all other copies either. In other words, changing the passphrase in the "private" official key doesn't create a ripple effect that changes the passphrase in all other copies.

You will need to also figure out your key strength.

Right now, there is no serious reason to prefer one type over any other, assuming large enough keys (2048 bits for RSA or DSA, 256 bits for ECDSA). You may specify the key size in ssh-keygen using the -b argument.

ssh-keygen -t rsa -b 4096 ~/.ssh/id_rsa

A remaining question to ask, is: how will your organization associate any key pair with each specific user? Will they use one private key to access all of your infrastructure? Will there be a separate key for each system? How many keys are allowed to access each account? What kind of accounts are allowed to be shared? This organization specific detail is best mapped  out with a security professional.

Tuesday, December 10, 2013

Create a new RSA keyfile for SSH

When you consider creating a new RSA or DSA keyfile, you do it with the knowledge that it will provide increased security when logging into a server using SSH. Requiring a RSA key as a security credential in the SSH authentication process is a more secure access management policy. Properly managing your credentials to maintain access and security can prevent problems, and increase profitability. 

There are at least three potential security related problems with traditional SSHD configuration.

1. Credential loss/theft
2. Potential Bruteforcing
3. Out of date access

We also discussed some solutions for eliminating and minimizing the risk of these problems.

1. Encrypted credentials (PGP encrypted username, password, key file)
2. Requiring a key, as well as a username and password
3. Rotating keys, audits

For those of you who are new to ssh keys, you can create a create a new key easily using the ssh-keygen command. This command allows the generation, management, and conversion of authentication keys. You only need to enter the ssh-keygen command to create an RSA keyfile, where the -t flag is used to specify the type of key to be generated, e.g.

ssh-keygen -t rsa
ssh-keygen -t rsa -f ~/.ssh/id_rsa         (default location)

When creating a new RSA key you can choose to leave the passphrase blank; press enter when asked to put in a passphrase. This will allow you to log into an SSH server without entering a passphrase. For stronger security add a second factor of authentication on the private keyfile and choose a passphrase.

Monday, December 9, 2013

Requiring RSA keys for SSHD

Many organizations or individuals make a best effort to prevent hackers from gaining access to their systems. However, some don't consider what kind of damage can be done when someone has obtained their password, using the traditional or default SSH daemon configuration.

In the case you are using a key alone, or a password -- when someone obtains either piece of information they can access your account through SSH. You can use PGP to encrypt your private key or an encrypted password database for your password, and always use a password that is never stored to add an additional layer of security. However, with both methods of authentication you have an additional piece of information a hacker must obtain to gain access to sensitive information.

Ignoring security leaves a system at the greatest risk to the most severe attacks. A strict access control schema for systems with sensitive data is essential even for when only one person is accessing that system. Investments into proactive security far outweigh the losses that happen with a breach, and the result is an overall increased profitability. If you are running a server that allows access for your organization only then this is the ideal place to implement this SSH security schema.

You can configure your SSH to require RSA keys, in sshd_config:

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile %h/.ssh/authorized_keys


# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Change to no to disable tunnelled clear text passwords
PasswordAuthentication no


UsePAM no

This makes it virtually impossible to brute force your account. If your organization or personal best practice does not include key management on your systems then it may be time for an adjustment in your security posture. Out of date keys belonging to accounts which no longer require access, or have too much access can prove problematic. Key management policies should be robust and require keys to be rotated out and audited on a regular frequency to eliminate any out of date security credentials, and find any accounts with access that is no longer required.

Monday, December 31, 2012

Seasons Greetings!

Hi there! I'm Dan and I'm a new addition to the community staff. I'm used to the cold winters of my hometown London, in the UK this time of year. However, I'm currently residing in lovely tropical Bolivia and everyday is a party, especially these last few weeks. Tonight, of course is the biggest party of all!

I feel the need to really take time to appreciate everyone around me, after not being crushed by some huge intergalactic alien 10 days ago. I'm grateful to share my joy of the new coming year (and the non-destruction of the earth!) with you all.

Here at Recompiled Networks we're working hard to improve our services and to provide quality to all of our customers all year round. While we sit around the fireplace, sharing good moments with our families and friends -- we can't help but think of all our customers. So as this year ends, and a fresh one begins, we hope success and prosperity comes to you, and your loved ones.

Thanks for being with us, have a happy new year!

Sunday, April 8, 2012

10MB and 100MB test files available...

2012-04-08 13:08:08 (88.8 MB/s) - `get.php?name=eggs' saved some new test files at:

Saturday, April 7, 2012

SSL Certificates are being updated

We are aware that some SSL certificates may be outdated. We have moved to 2048-bit and 4096-bit key strengths in our newest certificates. You can trust these certificates, here is what the new certs look like: