doc/signatures.texi

   1 In this section we will provide some information about digital
   2 signatures, how they work, and give the rationale for disabling some
   3 of the algorithms used.
   4
   5 Digital signatures work by using somebody's secret key to sign some
   6 arbitrary data.  Then anybody else could use the public key of that
   7 person to verify the signature.  Since the data may be arbitrary it is
   8 not suitable input to a cryptographic digital signature algorithm. For
   9 this reason and also for performance cryptographic hash algorithms are
  10 used to preprocess the input to the signature algorithm. This works as
  11 long as it is difficult enough to generate two different messages with
  12 the same hash algorithm output. In that case the same signature could
  13 be used as a proof for both messages. Nobody wants to sign an innocent
  14 message of donating 1 @euro{} to Greenpeace and find out that he
  15 donated 1.000.000 @euro{} to Bad Inc.
  16
  17 For a hash algorithm to be called cryptographic the following three
  18 requirements must hold
  19 @enumerate
  20 @item Preimage resistance. That means the algorithm must be one way and given
  21 the output of the hash function @math{H(x)}, it is impossible to
  22 calculate @math{x}.
  23
  24 @item 2nd preimage resistance. That means that given a pair @math{x,y} with @math{y=H(x)} it is impossible
  25 to calculate an @math{x'} such that @math{y=H(x')}.
  26
  27 @item Collision resistance. That means that it is impossible to calculate random @math{x} and @math{x'} such
  28 @math{H(x')=H(x)}.
  29 @end enumerate
  30
  31 The last two requirements in the list are the most important in
  32 digital signatures. These protect against somebody who would like to
  33 generate two messages with the same hash output. When an algorithm is
  34 considered broken usually it means that the Collision resistance of
  35 the algorithm is less than brute force. Using the birthday paradox the
  36 brute force attack takes
  37 @iftex
  38 @math{2^{(\rm{hash\ size}) / 2}}
  39 @end iftex
  40 @ifnottex
  41 @math{2^{((hash size) / 2)}}
  42 @end ifnottex
  43 operations. Today colliding certificates using the MD5 hash algorithm
  44 have been generated as shown in @xcite{WEGER}.
  45
  46 There has been cryptographic results for the SHA-1 hash algorithms as
  47 well, although they are not yet critical.  Before 2004, MD5 had a
  48 presumed collision strength of @math{2^64}, but it has been showed to
  49 have a collision strength well under @math{2^50}.  As of November
  50 2005, it is believed that SHA-1's collision strength is around
  51 @math{2^63}.  We consider this sufficiently hard so that we still
  52 support SHA-1.  We anticipate that SHA-256/386/512 will be used in
  53 publicly-distributed certificates in the future.  When @math{2^63} can
  54 be considered too weak compared to the computer power available
  55 sometime in the future, SHA-1 will be disabled as well.  The collision
  56 attacks on SHA-1 may also get better, given the new interest in tools
  57 for creating them.
  58
  59 @subsection Supported Algorithms
  60 The available digital signature algorithms in @acronym{GnuTLS} are
  61 listed below:
  62
  63 @table @code
  64 @item RSA
  65 RSA is public key cryptosystem designed by Ronald Rivest, Adi Shamir
  66 and Leonard Adleman. It can be used with any hash functions.
  67
  68 @item DSA
  69 DSA is the USA's Digital Signature Standard. It uses only the SHA-1
  70 hash algorithm.
  71
  72 @end table
  73
  74 The supported cryptographic hash algorithms are:
  75
  76 @table @code
  77 @item MD2
  78 MD2 is a cryptographic hash algorithm designed by Ron Rivest.  It is
  79 optimized for 8-bit processors.  Outputs 128 bits of data.  There are
  80 several known weaknesses of this algorithm and it should not be used.
  81 Unfortunately some CA certificates signed with RSA-MD2 are still in
  82 use, but this is acceptable because the RSA-MD2 signature is not
  83 involved in certificate validation.
  84
  85 @item MD5
  86 MD5 is a cryptographic hash algorithm designed by Ron Rivest. Outputs
  87 128 bits of data. It is considered to be broken.
  88
  89 @item SHA-1
  90 SHA is a cryptographic hash algorithm designed by NSA. Outputs 160
  91 bits of data. It is also considered to be broken, though no practical
  92 attacks have been found.
  93
  94 @item RMD160
  95 RIPEMD is a cryptographic hash algorithm developed in the framework of
  96 the EU project RIPE. Outputs 160 bits of data.
  97
  98 @end table
  99
 100
 101 @subsection Trading Security for Interoperability
 102
 103 If you connect to a server and use GnuTLS' functions to verify the
 104 certificate chain, and get a @ref{GNUTLS_CERT_INSECURE_ALGORITHM}
 105 validation error (@pxref{Verifying X.509 certificate paths}), it means
 106 that somewhere in the certificate chain there is a certificate signed
 107 using @code{RSA-MD2} or @code{RSA-MD5}.  These two digital signature
 108 algorithms are considered broken, so GnuTLS fail when attempting to
 109 verify the certificate.  In some situations, it may be useful to be
 110 able to verify the certificate chain anyway, assuming an attacker did
 111 not utilize the fact that these signatures algorithms are broken.
 112 This section will give help on how to achieve that.
 113
 114 First, it is important to know that you do not have to enable any of
 115 the flags discussed here to be able to use trusted root CA
 116 certificates signed using @code{RSA-MD2} or @code{RSA-MD5}.  The only
 117 attack today is that it is possible to generate certificates with
 118 colliding signatures (collision resistance); you cannot generate a
 119 certificate that has the same signature as an already existing
 120 signature (2nd preimage resistance).
 121
 122 If you are using @ref{gnutls_certificate_verify_peers2} to verify the
 123 certificate chain, you can call
 124 @ref{gnutls_certificate_set_verify_flags} with the
 125 @code{GNUTLS_VERIFY_ALLOW_SIGN_RSA_MD2} or
 126 @code{GNUTLS_VERIFY_ALLOW_SIGN_RSA_MD5} flag, as in:
 127
 128 @example
 129   gnutls_certificate_set_verify_flags (x509cred,
 130                                        GNUTLS_VERIFY_ALLOW_SIGN_RSA_MD5);
 131 @end example
 132
 133 This will tell the verifier algorithm to enable @code{RSA-MD5} when
 134 verifying the certificates.
 135
 136 If you are using @ref{gnutls_x509_crt_verify} or
 137 @ref{gnutls_x509_crt_list_verify}, you can pass the
 138 @code{GNUTLS_VERIFY_ALLOW_SIGN_RSA_MD5} parameter directly in the
 139 @code{flags} parameter.
 140
 141 If you are using these flags, it may also be a good idea to warn the
 142 user when verification failure occur for this reason.  The simplest is
 143 to not use the flags by default, and only fall back to using them
 144 after warning the user.  If you wish to inspect the certificate chain
 145 yourself, you can use @ref{gnutls_certificate_get_peers} to extract
 146 the raw server's certificate chain, then use
 147 @ref{gnutls_x509_crt_import} to parse each of the certificates, and
 148 then use @ref{gnutls_x509_crt_get_signature_algorithm} to find out the
 149 signing algorithm used for each certificate.  If any of the
 150 intermediary certificates are using @code{GNUTLS_SIGN_RSA_MD2} or
 151 @code{GNUTLS_SIGN_RSA_MD5}, you could present a warning.