[securityguide] Updated asymmetric certificate size suggestion

[Eric Christensen]

commit 9d4c9b0a6f8ea021dce8227548bceaa61827c4f6
Author: Eric H Christensen <sparks at redhat.com>
Date:   Tue Jun 17 10:35:04 2014 -0400

    Updated asymmetric certificate size suggestion

 en-US/Encryption.xml           |    2 +-
 en-US/Encryption_Standards.xml |    2 +-
 en-US/Using_GPG.xml            |    2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)
---
diff --git a/en-US/Encryption.xml b/en-US/Encryption.xml
index 5df7691..def7428 100644
--- a/en-US/Encryption.xml
+++ b/en-US/Encryption.xml
@@ -59,7 +59,7 @@
 		<para>A configuration change must occur before cryptographic logon can occur.  In the file <filename>/etc/ssh/sshd_config</filename> uncomment and modify the following lines so that appear as such:
 		<screen>PubkeyAuthentication yes
 AuthorizedKeysFile	.ssh/authorized_keys</screen>The first line tells the SSH program to allow public key authentication.  The second line points to a file in the home directory where the public key of authorized key pairs exists on the system.</para>
-		<para>The next thing to do is to generate the ssh key pairs on the client you will use to connect to the system.  The command <command>ssh-keygen</command> will generate an RSA 2048-bit key set for logging into the system.  The keys are stored, by default, in the <filename>~/.ssh</filename> directory.  You can utilize the switch <command>-b</command> to modify the bit-strength of the key.  2048-bits is probably okay but you can go up to, and possibly beyond, 8192-bit keys.</para>
+		<para>The next thing to do is to generate the ssh key pairs on the client you will use to connect to the system.  The command <command>ssh-keygen</command> will generate an RSA 2048-bit key set for logging into the system.  The keys are stored, by default, in the <filename>~/.ssh</filename> directory.  You can utilize the switch <command>-b</command> to modify the bit-strength of the key.  A 2048-bit certificate only provides 112 bits of security.  To get 128 bits of security requires a 3072-bit certificate and to get 256 bits of security one must use a 15,360-bit certificate.  Elliptical certificates (<abbrev>ECDSA</abbrev>) and elliptical ciphers can increase the security to 256 bits with smaller certificates.</para>
 		<para>In your <filename>~/.ssh</filename> directory you should see the two keys you just created.  If you accepted the defaults when running the <command>ssh-keygen</command> then your keys are named <filename>id_rsa</filename> and <filename>id_rsa.pub</filename>, the private and public keys.  You should always protect the private key from exposure.  The public key, however, needs to be transfered over to the system you are going to login to.  Once you have it on your system the easiest way to add the key to the approved list is by: <screen>$ cat id_rsa.pub >> ~/.ssh/authorized_keys</screen>  This will append the public key to the authorized_key file.  The <application>SSH</application> application will check this file when you attempt to login to the computer.</para>
 		<para>Similarly to passwords and any other authentication mechanism, you should change your <application>SSH</application> keys regularly.  When you do make sure you clean out any unused key from the authorized_key file.</para>
 	</section>
diff --git a/en-US/Encryption_Standards.xml b/en-US/Encryption_Standards.xml
index 361dfb3..732f9b9 100644
--- a/en-US/Encryption_Standards.xml
+++ b/en-US/Encryption_Standards.xml
@@ -63,7 +63,7 @@
 					<section>
 						<title>SSL/TLS</title>
 						<para>Transport Layer Security (TLS) and its predecessor, Secure Socket Layer (SSL), are cryptographic protocols that provide security  for communications over networks such as the Internet. TLS and SSL encrypt the segments of network connections at the Transport Layer end-to-end.  Several versions of the protocols are in widespread use in applications like web browsing, electronic mail, Internet faxing, instant messaging and voice-over-IP (VoIP).  TLS is an IETF standards track protocol, last updated in RFC 5246, that was based on the earlier SSL specifications developed by Netscape Corporation.</para>
-						<para>The TLS protocol allows client/server applications to communicate across a network in a way designed to prevent eavesdropping  and tampering. TLS provides endpoint authentication and communications confidentiality over the Internet  using cryptography. TLS provides RSA security with 1024 and 2048 bit strengths.</para>
+						<para>The TLS protocol allows client/server applications to communicate across a network in a way designed to prevent eavesdropping  and tampering. TLS provides endpoint authentication and communications confidentiality over the Internet using cryptography. TLS traditionally uses RSA keys which provide 112 bits of security with a 2048-bit certificate and 128 bits of security with a 3072-bit certificate.</para>
 						<para>In typical end-user/browser usage, TLS authentication is unilateral: only the server is authenticated (the client knows the server's identity), but not vice versa (the client remains unauthenticated or anonymous).</para>
 						<para>TLS also supports the more secure bilateral connection mode (typically used in enterprise applications), in which both ends of the "conversation" can be assured with whom they are communicating (provided they diligently scrutinize the identity information in the other party's certificate). This is known as mutual authentication, or 2SSL. Mutual authentication requires that the TLS client-side also hold a certificate (which is not usually the case in the end-user/browser scenario). Unless, that is, TLS-PSK, the Secure Remote Password (SRP) protocol, or some other protocol is used that can provide strong mutual authentication in the absence of certificates.</para>
 						<para>Typically, the key information and certificates necessary for TLS are handled in the form of X.509 certificates, which define required fields and data formats.</para>
diff --git a/en-US/Using_GPG.xml b/en-US/Using_GPG.xml
index e6ed3a1..1086c7a 100644
--- a/en-US/Using_GPG.xml
+++ b/en-US/Using_GPG.xml
@@ -68,7 +68,7 @@
     <screen>RSA keys may be between 1024 and 4096 bits long.
 What keysize do you want? (2048)</screen>
       
-      Again, the default is sufficient for almost all users, and represents a strong level of security.
+      Again, the default only provides 112 bits of security.  Increasing this to 3072 helps provide 128 bits of security and represents a stronger level of security.
     </para>
     <para>
       Next, choose when the key will expire. It is a good idea to choose an expiration date instead of using the default, which is none.  If, for example, the email address on the key becomes invalid, an expiration date will remind others to stop using that public key.