[SCM] GNU gnutls branch, master, updated. gnutls_2_9_10-317-g08edf1b

[Nikos Mavrogiannopoulos]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU gnutls".

http://git.savannah.gnu.org/cgit/gnutls.git/commit/?id=08edf1b4f10d6b5d2a265d7210944f044f607729

The branch, master has been updated
       via  08edf1b4f10d6b5d2a265d7210944f044f607729 (commit)
      from  36c75f9fc791c1e32d1d324c0264857406b4a6f9 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
commit 08edf1b4f10d6b5d2a265d7210944f044f607729
Author: Nikos Mavrogiannopoulos <address@hidden>
Date:   Fri Jul 23 20:38:31 2010 +0200

    Simplified documentation.

-----------------------------------------------------------------------

Summary of changes:
 doc/cha-intro-tls.texi |   55 ++++++++++-------------------------------------
 1 files changed, 12 insertions(+), 43 deletions(-)

diff --git a/doc/cha-intro-tls.texi b/doc/cha-intro-tls.texi
index 9d180ad..2ab1b42 100644
--- a/doc/cha-intro-tls.texi
+++ b/doc/cha-intro-tls.texi
@@ -539,9 +539,14 @@ authentication.
 
 @end multitable
 
-The first column provides an estimation of the year until these
-parameters are considered safe and the rest of the columns list the
-parameters for the various algorithms.
+The first column provides a security parameter in a number of bits. This
+gives an indication of the number of combinations to be tried by an adversary
+to brute force a key. For example to test all possible keys in a 112 bit 
security parameter
address@hidden combinations have to be tried. For today's technology this is 
infeasible.
+The next two columns correlate the security
+parameter with actual bit sizes of parameters for DH, RSA, SRP and ECC 
algorithms.
+A mapping to @code{gnutls_sec_param_t} value is given for each security 
parameter, on
+the next column, and finally a brief description of the level.
 
 Note however that the values suggested here are nothing more than an
 educated guess that is valid today. There are no guarrantees that an
@@ -553,47 +558,11 @@ TLS are selected in a conservative way and such 
catastrophic
 breakthroughs or failures are believed to be unlikely.
 
 NIST publication SP 800-57 @xcite{NISTSP80057} contains a similar
-table that extends beyond the key sizes given above.
+table.
 
address@hidden @columnfractions .15 .20 .20 .20
-
address@hidden Bits of security
address@hidden Symmetric key algorithms
address@hidden RSA key size, DSA, DH and SRP prime size
address@hidden ECC key size
-
address@hidden 80
address@hidden 2TDEA
address@hidden 1024
address@hidden 160-223
-
address@hidden 112
address@hidden 3DES
address@hidden 2048
address@hidden 224-255
-
address@hidden 128
address@hidden AES-128
address@hidden 3072
address@hidden 256-383
-
address@hidden 192
address@hidden AES-192
address@hidden 7680
address@hidden 384-511
-
address@hidden 256
address@hidden AES-256
address@hidden 15360
address@hidden 512+
-
address@hidden multitable
-
-The recommendations are fairly consistent.
-
-When using @acronym{GnuTLS} and 
-bit sizes are required as input it is recommended to use the following
-functions:
+When using @acronym{GnuTLS} and a decision on bit sizes for a public
+key algorithm is required, use of the following functions is  
+recommended:
 @itemize
 
 @item @ref{gnutls_pk_bits_to_sec_param}


hooks/post-receive
-- 
GNU gnutls