Next: , Previous: , Up: How to use GnuTLS in applications   [Contents][Index]

6.11 Selecting cryptographic key sizes

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 bitsRSA, DH and SRP parameter sizeECC key sizeSecurity parameter (profile)Description
<64<768<128INSECUREConsidered to be insecure
64768128VERY WEAKShort term protection against individuals
721008160WEAKShort term protection against small organizations
801024160LOWVery short term protection against agencies (corresponds to ENISA legacy level)
961776192LEGACYLegacy standard level
1122048224MEDIUMMedium-term protection
1283072256HIGHLong term protection (corresponds to ENISA future level)
1928192384ULTRAEven longer term protection
25615424512FUTUREForeseeable future

Table 6.7: Key sizes and security parameters.

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 parameter

When 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 bits

This 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)

Next: , Previous: , Up: How to use GnuTLS in applications   [Contents][Index]