Next: Advanced topics, Previous: Priority Strings, Up: How to use GnuTLS in applications [Contents][Index]

Because many algorithms are involved in TLS, it is not easy to set
a consistent security level. For this reason in Table 6.7 we
present some correspondence between key sizes of symmetric algorithms
and public key algorithms based on [*ECRYPT*].
Those can be used to generate certificates with
appropriate key sizes as well as select parameters for Diffie-Hellman and SRP
authentication.

Security bits | RSA, DH and SRP parameter size | ECC key size | Security parameter (profile) | Description |
---|---|---|---|---|

<64 | <768 | <128 | `INSECURE` | Considered to be insecure |

64 | 768 | 128 | `VERY WEAK` | Short term protection against individuals |

72 | 1008 | 160 | `WEAK` | Short term protection against small organizations |

80 | 1024 | 160 | `LOW` | Very short term protection against agencies (corresponds to ENISA legacy level) |

96 | 1776 | 192 | `LEGACY` | Legacy standard level |

112 | 2048 | 224 | `MEDIUM` | Medium-term protection |

128 | 3072 | 256 | `HIGH` | Long term protection (corresponds to ENISA future level) |

192 | 8192 | 384 | `ULTRA` | Even longer term protection |

256 | 15424 | 512 | `FUTURE` | Foreseeable future |

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
*2^{112}* 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 `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 guarantees that an
algorithm will remain unbreakable or that these values will remain
constant in time. There could be scientific breakthroughs that cannot
be predicted or total failure of the current public key systems by
quantum computers. On the other hand though the cryptosystems used in
TLS are selected in a conservative way and such catastrophic
breakthroughs or failures are believed to be unlikely.
The NIST publication SP 800-57 [*NISTSP80057*] contains a similar
table.

When using GnuTLS and a decision on bit sizes for a public key algorithm is required, use of the following functions is recommended:

- Function:
*unsigned int***gnutls_sec_param_to_pk_bits***(gnutls_pk_algorithm_t*`algo`, gnutls_sec_param_t`param`) `algo`: is a public key algorithm`param`: is a security parameterWhen generating private and public key pairs a difficult question is which size of "bits" the modulus will be in RSA and the group size in DSA. The easy answer is 1024, which is also wrong. This function will convert a human understandable security parameter to an appropriate size for the specific algorithm.

**Returns:**The number of bits, or (0).**Since:**2.12.0

- Function:
*gnutls_sec_param_t***gnutls_pk_bits_to_sec_param***(gnutls_pk_algorithm_t*`algo`, unsigned int`bits`) `algo`: is a public key algorithm`bits`: is the number of bitsThis is the inverse of

`gnutls_sec_param_to_pk_bits()`

. Given an algorithm and the number of bits, it will return the security parameter. This is a rough indication.**Returns:**The security parameter.**Since:**2.12.0

Those functions will convert a human understandable security parameter
of `gnutls_sec_param_t`

type, to a number of bits suitable for a public
key algorithm.

`const char *`gnutls_sec_param_get_name (gnutls_sec_param_t`param`)

The following functions will set the minimum acceptable group size for Diffie-Hellman and SRP authentication.

`void`gnutls_dh_set_prime_bits (gnutls_session_t`session`, unsigned int`bits`)`void`gnutls_srp_set_prime_bits (gnutls_session_t`session`, unsigned int`bits`)