sizes. we present some correspondence between key sizes of symmetric algorithms and public key algorithms based on [*note ECRYPT::]. Those can be used to generate certificates with appropriate key sizes as well as select parameters for Diffie-Hellman and SRP authentication. SecurityRSA, DH ECC Security Description bits and SRP key parameter parameter size (profile) size ----------------------------------------------------------------- <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 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 [*note 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 * *note 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 *note gnutls_dh_set_prime_bits:: (gnutls_session_t SESSION, unsigned int BITS)’ ‘VOID *note gnutls_srp_set_prime_bits:: (gnutls_session_t SESSION, unsigned int BITS)’