crypto.h

   1 /*
   2  * Copyright (c) 2008, Dave Korn.
   3  *
   4  *     This program is free software; you can redistribute it and/or modify
   5  *     it under the terms of the GNU General Public License as published by
   6  *     the Free Software Foundation; either version 2 of the License, or
   7  *     (at your option) any later version.
   8  *
   9  *     A copy of the GNU General Public License can be found at
  10  *     http://www.gnu.org/
  11  *
  12  * Written by Dave Korn <dave.korn.cygwin@gmail.com>
  13  *
  14  */
  15
  16 #ifndef SETUP_CRYPTO_H
  17 #define SETUP_CRYPTO_H
  18
  19 /* This module uses libgcrypt functionality to verify signatures
  20  * on downloaded setup.ini or setup.bz2 files.
  21  */
  22
  23 /* for HWND */
  24 #include "win32.h"
  25 class io_stream;
  26
  27 /*  This is currently the only public API exported by the module; it
  28   takes the contents of setup.ini or setup.bz2 in one (memory-based,
  29   for preference) io_stream, and the contents of the related signature
  30   file in another.  It is called from ini.cc/do_remote_ini() and returns
  31   true if the signature verified OK; if it returns false, you MUST NOT
  32   use the failed ini file - doubly so if it's a compressed stream!  */
  33 extern bool verify_ini_file_sig (io_stream *ini_file, io_stream *ini_sig_file, HWND owner);
  34
  35 /*
  36 5.2.2.  Version 3 Signature Packet Format
  37
  38    The body of a version 3 Signature Packet contains:
  39
  40      - One-octet version number (3).
  41
  42      - One-octet length of following hashed material.  MUST be 5.
  43
  44          - One-octet signature type.
  45
  46          - Four-octet creation time.
  47
  48      - Eight-octet Key ID of signer.
  49
  50      - One-octet public-key algorithm.
  51
  52      - One-octet hash algorithm.
  53
  54      - Two-octet field holding left 16 bits of signed hash value.
  55
  56      - One or more multiprecision integers comprising the signature.
  57        This portion is algorithm specific, as described below.
  58
  59    The concatenation of the data to be signed, the signature type, and
  60    creation time from the Signature packet (5 additional octets) is
  61    hashed.  The resulting hash value is used in the signature algorithm.
  62    The high 16 bits (first two octets) of the hash are included in the
  63    Signature packet to provide a quick test to reject some invalid
  64    signatures.
  65
  66    Algorithm-Specific Fields for RSA signatures:
  67
  68      - multiprecision integer (MPI) of RSA signature value m**d mod n.
  69
  70    Algorithm-Specific Fields for DSA signatures:
  71
  72      - MPI of DSA value r.
  73
  74      - MPI of DSA value s.
  75
  76    The signature calculation is based on a hash of the signed data, as
  77    described above.  The details of the calculation are different for
  78    DSA signatures than for RSA signatures.
  79
  80    With RSA signatures, the hash value is encoded using PKCS#1 encoding
  81    type EMSA-PKCS1-v1_5 as described in Section 9.2 of RFC 3447.  This
  82    requires inserting the hash value as an octet string into an ASN.1
  83    structure.  The object identifier for the type of hash being used is
  84    included in the structure.  The hexadecimal representations for the
  85    currently defined hash algorithms are as follows:
  86
  87      - MD5:        0x2A, 0x86, 0x48, 0x86, 0xF7, 0x0D, 0x02, 0x05
  88
  89      - RIPEMD-160: 0x2B, 0x24, 0x03, 0x02, 0x01
  90
  91      - SHA-1:      0x2B, 0x0E, 0x03, 0x02, 0x1A
  92
  93      - SHA224:     0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x04
  94
  95      - SHA256:     0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x01
  96
  97      - SHA384:     0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x02
  98
  99      - SHA512:     0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x03
 100
 101    The ASN.1 Object Identifiers (OIDs) are as follows:
 102
 103      - MD5:        1.2.840.113549.2.5
 104
 105      - RIPEMD-160: 1.3.36.3.2.1
 106
 107      - SHA-1:      1.3.14.3.2.26
 108
 109      - SHA224:     2.16.840.1.101.3.4.2.4
 110
 111      - SHA256:     2.16.840.1.101.3.4.2.1
 112
 113      - SHA384:     2.16.840.1.101.3.4.2.2
 114
 115      - SHA512:     2.16.840.1.101.3.4.2.3
 116
 117    The full hash prefixes for these are as follows:
 118
 119        MD5:        0x30, 0x20, 0x30, 0x0C, 0x06, 0x08, 0x2A, 0x86,
 120                    0x48, 0x86, 0xF7, 0x0D, 0x02, 0x05, 0x05, 0x00,
 121                    0x04, 0x10
 122
 123        RIPEMD-160: 0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 0x2B, 0x24,
 124                    0x03, 0x02, 0x01, 0x05, 0x00, 0x04, 0x14
 125
 126        SHA-1:      0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 0x2b, 0x0E,
 127                    0x03, 0x02, 0x1A, 0x05, 0x00, 0x04, 0x14
 128
 129        SHA224:     0x30, 0x31, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86,
 130                    0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x04, 0x05,
 131                    0x00, 0x04, 0x1C
 132
 133        SHA256:     0x30, 0x31, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86,
 134                    0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x01, 0x05,
 135                    0x00, 0x04, 0x20
 136
 137        SHA384:     0x30, 0x41, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86,
 138                    0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x02, 0x05,
 139                    0x00, 0x04, 0x30
 140
 141        SHA512:     0x30, 0x51, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86,
 142                    0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x03, 0x05,
 143                    0x00, 0x04, 0x40
 144
 145    DSA signatures MUST use hashes that are equal in size to the number
 146    of bits of q, the group generated by the DSA key's generator value.
 147
 148    If the output size of the chosen hash is larger than the number of
 149    bits of q, the hash result is truncated to fit by taking the number
 150    of leftmost bits equal to the number of bits of q.  This (possibly
 151    truncated) hash function result is treated as a number and used
 152    directly in the DSA signature algorithm.
 153
 154
 155 5.2.3.  Version 4 Signature Packet Format
 156
 157    The body of a version 4 Signature packet contains:
 158
 159      - One-octet version number (4).
 160
 161      - One-octet signature type.
 162
 163      - One-octet public-key algorithm.
 164
 165      - One-octet hash algorithm.
 166
 167      - Two-octet scalar octet count for following hashed subpacket data.
 168        Note that this is the length in octets of all of the hashed
 169        subpackets; a pointer incremented by this number will skip over
 170        the hashed subpackets.
 171
 172      - Hashed subpacket data set (zero or more subpackets).
 173
 174      - Two-octet scalar octet count for the following unhashed subpacket
 175        data.  Note that this is the length in octets of all of the
 176        unhashed subpackets; a pointer incremented by this number will
 177        skip over the unhashed subpackets.
 178
 179      - Unhashed subpacket data set (zero or more subpackets).
 180
 181      - Two-octet field holding the left 16 bits of the signed hash
 182        value.
 183
 184      - One or more multiprecision integers comprising the signature.
 185        This portion is algorithm specific, as described above.
 186
 187    The concatenation of the data being signed and the signature data
 188    from the version number through the hashed subpacket data (inclusive)
 189    is hashed.  The resulting hash value is what is signed.  The left 16
 190    bits of the hash are included in the Signature packet to provide a
 191    quick test to reject some invalid signatures.
 192
 193    There are two fields consisting of Signature subpackets.  The first
 194    field is hashed with the rest of the signature data, while the second
 195    is unhashed.  The second set of subpackets is not cryptographically
 196    protected by the signature and should include only advisory
 197    information.
 198
 199    The algorithms for converting the hash function result to a signature
 200    are described in a section below.
 201
 202
 203 5.2.4.  Computing Signatures
 204
 205    All signatures are formed by producing a hash over the signature
 206    data, and then using the resulting hash in the signature algorithm.
 207
 208    For binary document signatures (type 0x00), the document data is
 209    hashed directly.  For text document signatures (type 0x01), the
 210    document is canonicalized by converting line endings to <CR><LF>,
 211    and the resulting data is hashed.
 212
 213    When a signature is made over a key, the hash data starts with the
 214    octet 0x99, [ ... ]
 215
 216    A certification signature (type 0x10 through 0x13) [ ... ]
 217
 218    When a signature is made over a Signature packet (type 0x50), [ ... ]
 219
 220    Once the data body is hashed, then a trailer is hashed.  A V3
 221    signature hashes five octets of the packet body, starting from the
 222    signature type field.  This data is the signature type, followed by
 223    the four-octet signature time.  A V4 signature hashes the packet body
 224    starting from its first field, the version number, through the end
 225    of the hashed subpacket data.  Thus, the fields hashed are the
 226    signature version, the signature type, the public-key algorithm, the
 227    hash algorithm, the hashed subpacket length, and the hashed
 228    subpacket body.
 229
 230    V4 signatures also hash in a final trailer of six octets: the
 231    version of the Signature packet, i.e., 0x04; 0xFF; and a four-octet,
 232    big-endian number that is the length of the hashed data from the
 233    Signature packet (note that this number does not include these final
 234    six octets).
 235
 236    After all this has been hashed in a single hash context, the
 237    resulting hash field is used in the signature algorithm and placed
 238    at the end of the Signature packet.
 239
 240 */
 241
 242 #define RFC4880_SIGV3_HASHED_SIZE       5
 243 #define RFC4880_SIGV4_HASHED_OVERHEAD   6
 244
 245
 246 /*
 247 5.5.  Key Material Packet
 248
 249    A key material packet contains all the information about a public or
 250    private key.  There are four variants of this packet type, and two
 251    major versions.  Consequently, this section is complex.
 252
 253 5.5.1.  Key Packet Variants
 254
 255 5.5.1.1.  Public-Key Packet (Tag 6)
 256
 257    A Public-Key packet starts a series of packets that forms an OpenPGP
 258    key (sometimes called an OpenPGP certificate).
 259
 260 5.5.1.2.  Public-Subkey Packet (Tag 14)
 261 5.5.1.3.  Secret-Key Packet (Tag 5)
 262 5.5.1.4.  Secret-Subkey Packet (Tag 7)
 263
 264 5.5.2.  Public-Key Packet Formats
 265
 266    The version 4 format is similar to the version 3 format except for
 267    the absence of a validity period.  This has been moved to the
 268    Signature packet.  In addition, fingerprints of version 4 keys are
 269    calculated differently from version 3 keys, as described in the
 270    section "Enhanced Key Formats".
 271
 272    A version 4 packet contains:
 273
 274      - A one-octet version number (4).
 275
 276      - A four-octet number denoting the time that the key was created.
 277
 278      - A one-octet number denoting the public-key algorithm of this key.
 279
 280      - A series of multiprecision integers comprising the key material.
 281        This algorithm-specific portion is:
 282
 283        Algorithm-Specific Fields for RSA public keys:
 284
 285          - multiprecision integer (MPI) of RSA public modulus n;
 286
 287          - MPI of RSA public encryption exponent e.
 288
 289        Algorithm-Specific Fields for DSA public keys:
 290
 291          - MPI of DSA prime p;
 292
 293          - MPI of DSA group order q (q is a prime divisor of p-1);
 294
 295          - MPI of DSA group generator g;
 296
 297          - MPI of DSA public-key value y (= g**x mod p where x
 298            is secret).
 299
 300        Algorithm-Specific Fields for Elgamal public keys:
 301
 302          - MPI of Elgamal prime p;
 303
 304          - MPI of Elgamal group generator g;
 305
 306          - MPI of Elgamal public key value y (= g**x mod p where x
 307            is secret).
 308
 309 */
 310
 311 // Big enough to dump the coefficients of a
 312 // signing key of any reasonable size in ASCII
 313 // s-expr representation.
 314 #define GPG_KEY_SEXPR_BUF_SIZE  (8192)
 315
 316 #endif /* SETUP_CRYPTO_H */