OpenPGP

from Wikipedia, the free encyclopedia

OpenPGP is a standardized data format for encrypted and digitally signed data. The format of certificates , which are commonly referred to as " keys ", is also specified .

It is based on the format introduced by PGP 5 and is standardized in RFC 4880 . With RFC 5581 was Camellia (another symmetric encryption algorithm) are added. RFC 6637 added Elliptic Curve Cryptography to OpenPGP . However, these extensions are expressly specified as "optional". An OpenPGP-compliant application is therefore not forced to implement these two extensions.

General

OpenPGP is a binary format . An OpenPGP message consists of one or more data sets ( English records ), but for historical reasons they are referred to as packets in the original documentation .

The PGP data format has been continuously expanded over time and exists in various downwardly compatible versions. Essentially, a distinction is made between an “old” format (used by PGP up to version 2.6) and a “new” format (from PGP version 3). However, newer PGP versions can read messages in the old format and - if the content can also be expressed in the old format - optionally also generate messages in the old format.

Each packet begins with a byte called a packet tag , which defines the type and length of the subsequent packet. The following package types have been specified so far:

OpenPGP packet types according to RFC 4880
number Type Remarks
0 Reserved A package of this type is not allowed.
1 Public-Key Encrypted Session Key Packet Contains the session key ( encrypted with the recipient's public key), which is used to encrypt the actual user data (in packet type 9).
2 Signature package
3 Symmetric-Key Encrypted Session Key Packet Contains the key (encrypted with a symmetrical cryptographic algorithm) with which the actual user data (in packet type 9) is encrypted.
4th One-Pass Signature Package
5 Secret-Key Packet Contains a private key
6th Public-key packet Contains a public key
7th Secret subkey packet
8th Compressed data packet Contains data compressed with zlib ( RFC 1950 ), Deflate ( RFC 1951 ) or Bzip2 .
9 Symmetrically Encrypted Data Packet CFB -encrypted data
10 Marker packet
11 Literal data packet contains unencrypted binary or text data and a file name under which the data can be saved.
12 Trust package
13 User ID packet usually contains the name and email address of a key holder
14th Public subkey packet
17th User Attribute Packet contains further metadata about the key holder, e.g. B. a JPEG image. Further metadata types have not yet been specified.
18th Sym. Encrypted and Integrity Protected Data Packet Can be used instead of packet type 9 to generate encrypted data with protection against accidental or intentional alteration. This protection ( modification detection code , called MDC) is cryptographically weaker than a digital signature or a MAC , but easier to generate and better than no protection at all.
19th Modification Detection Code Packet Contains the SHA1 checksum of the data stream encrypted with packet type 18.
60 to 63 Private or Experimental Values

Since the “old” OpenPGP format only has 4 bits for coding the packet type, it can only contain packet types up to 15. In the "new" format, 6 bits are available for coding the packet type, which is sufficient for coding the possible values ​​0 to 63.

Some packet types in turn contain a version identifier, the type and number of data contents i. d. Usually increase with increasing version number.

Encryption

The user data is always encrypted with a symmetrical encryption algorithm and a random "session key" and stored in a type 9 packet. This "session key" is then again encrypted asymmetrically (packet type 1) or symmetrically (packet type 3) and placed in front of the encrypted user data.

Package type 1: "Public-Key Encrypted Session Key"

An encrypted OpenPGP message can contain zero, one or more type 1 packets. Usually a type 1 packet is generated for each recipient of an OpenPGP message.

A type 1 package contains the following data:

  • A version identifier. Only version 3 is currently defined.
  • an 8-byte key ID of the key, so that a recipient can more easily find the packet intended for him. However, it is also possible to specify a null ID so that the recipient has to try out all private keys.
  • 1 byte that encodes the public key algorithm used
  • the encrypted session key

The following public key algorithms are possible:

Public key algorithms
ID algorithm Remarks
1 RSA for encryption and signing
2 RSA only for encryption
3 RSA  only for signing
16 Elgamal  only for encryption
17th  DSA  only for signing
18th ECDH defined in RFC 6637
19th ECDSA defined in RFC 6637
20th reserved
21st reserved for Diffie-Hellman (X9.42, as defined for IETF-S / MIME)
100 ... 110 reserved for private / experimental algorithms

Different elliptical curves exist for ECC keys. These are identified by their OID , so that adding new curves does not require any changes to the OpenPGP standard.

ECC curves for OpenPGP
Surname Bit length OID Remarks
NIST curve P-256 256 1.2.840.10045.3.1.7 defined in RFC 6637
NIST curve P-384 384 1.3.132.0.34
NIST curve P-521 521 1.3.132.0.35
Ed25519 255 1.3.6.1.4.1.11591.15.1 Since GnuPG 2.1.0, no RFC yet
Brainpool P256r1 256 1.3.36.3.3.2.8.1.1.7
Brainpool P384r1 384 1.3.36.3.3.2.8.1.1.11
Brainpool 512r1  512 1.3.36.3.3.2.8.1.1.13
secp256k1 256 1.3.132.0.10 Since GnuPG 2.1.0

Package type 3: "Symmetric-Key Encrypted Session Key"

An encrypted OpenPGP message can contain zero, one or more packets of type 3. These are used to encrypt the session key not with the public key of the recipient, but with a symmetrical key that is generated from a passphrase. A type 3 packet is generated for each passphrase.

A type 3 package contains the following data:

  • A version identifier. Only version 4 is currently defined.
  • A byte that encodes the symmetric encryption algorithm
  • An identifier of variable length that specifies how the key is derived from the passphrase ("string-to-key specifier")
  • possibly the one with the above Procedure encrypted session key
Symmetrical cipher algorithms
ID algorithm Key length Remarks
0 unencrypted - not allowed for package type 3
1 IDEA 128 bit only algorithm in PGP 2.6
2 TripleDES (DES-EDE) 168 bits must be implemented according to the RFC
3 CAST5 128 bit Default algorithm in GnuPG 2.0
4th Blowfish 128 bit 16 rounds
5… 6 reserved
7th AES 128 bit Default algorithm since GnuPG 2.1
8th 192 bits
9 256 bit
10 Twofish 256 bit
11 Camellia 128 bit defined since RFC 5581
12 192 bits
13 256 bit
100 ... 110 reserved for private / experimental algorithms

However, all algorithms except TripleDES are optional, a standard-compliant implementation only needs to be able to use TripleDES. RFC 4880 recommends that each implementation master CAST5 and AES-128.

Applications

Two of the main uses are signing and encrypting emails . OpenPGP messages must be suitably coded for this, since an email according to RFC 5322 may only consist of printable characters from the ASCII character set and a few control characters.

There are essentially two formats for this:

  • the older PGP / INLINE as the compatibility format
    • Pro.svgCan also be used (although not without problems) with mail programs that do not know OpenPGP (including webmail ). Due to its structure, the e-mail is generated as a normal text mail ( Content-Type: text/plain), which contains encrypted text as Radix-64 encoded text ( Base64 plus checksum; original text format from PGP); Signed text is inserted as a plain text signature (introductory line, normal text, signature data as Radix-64). This only enables the signing and encryption of simple mail text (mail body).
    • Contra.png There is no corresponding option for HTML mail.
    • Contra.pngFile attachments can, however, be encrypted and / or signed in advance (this is done by the mail programs; in the case of webmail, you have to do this yourself without a corresponding browser add-on). However, the signatures then do not guarantee the integrity of the mail as a whole. Signed parts can be removed unnoticed, data signed in other contexts can be added (which would only be noticed if one took the trouble to compare the time stamps of the individual signatures).
    • Contra.png One of the disadvantages of PGP / Inline is that mail programs that do not understand OpenPGP display the signature in the text, which confuses many recipients.
  • PGP / MIME as a clean technical solution ( MIME extension according to RFC 3156 )
    • Pro.svgThis procedure also covers file attachments and HTML mail. For the mail body and all attachments it can be specified individually whether they should be encrypted and / or signed; technically only one signing and / or encryption is carried out (with PGP / Inline for the text part and each file attachment separately).
    • Neutral.svg However, this procedure only protects the content of the mail, not its header data (e.g. sender, recipient, subject, date).
    • Contra.pngThe disadvantage of PGP / MIME is that mail programs (or webmail implementations) that do not even support the basic standard from 1995 ( RFC 1847 ), which defines the basic e-mail format for encrypted or signed content, can be empty in case of doubt Show mail with file attachments, which is even more irritating and even less user-friendly than a Radix-64 signature in the text.

Some mail programs offer the option of specifying the format in which OpenPGP messages are to be sent to the respective address for the address book entries. In this way one can minimize the disadvantages of both methods.

OpenPGP and S / MIME (which uses X.509 certificates) are the two most important standards for email encryption. Another main use of OpenPGP is to secure the software distribution (package management) of e.g. B. Linux through digital signatures.

history

OpenPGP was created in 1998 as a reaction to various developments:

  • the algorithms used in PGP ( IDEA and RSA ) were patented and could not be used arbitrarily. In particular, there were laws in the USA that forbade the export of strong encryption (40 bit or more).
  • The PGP program was sold commercially by PGP Inc., and there were unsubstantiated rumors that a back door was built into the program because it had a so-called ADK (Additional Decryption Key) function.
  • In late 1997, PGP Inc. was taken over by Network Associates Inc. (NAI), which were a member of the Key Recovery Alliance .

The OpenPGP format is now implemented by many products. Prominent representatives are the commercial PGP and the free open source program GnuPG (under the GNU GPL ).

The S / MIME format, which is also widespread, uses X.509 certificates and is therefore fundamentally incompatible with OpenPGP, even if it uses the same cryptographic procedures at the lowest level. There are programs that can convert OpenPGP keys in RSA format into X.509 keys (and vice versa: pem2openpgp from the monkeysphere package); however, this conversion only affects the raw key material; the certifications by third parties are lost. It is also possible to use the same key for SSH (e.g. using GnuPG).

There is also the OpenPGP Alliance as an association of several manufacturers who feel committed to the OpenPGP format. Dominik Schürmann has been responsible for this site since August 2016.

Cryptographic procedures

Encryption

OpenPGP uses a hybrid encryption that combines the advantages of asymmetric cryptosystems (secure key transmission) with those of symmetric cryptosystems (high speed).

Instead of using just one key for both encryption and decryption, as is the case with a symmetric system, an asymmetric system has a key pair consisting of two related keys, one public and one secret. Data that has been encrypted with the public key can only be decrypted again with the secret key; it is not possible to cancel the encryption with the public key. With the asymmetric procedure, a symmetric session key is encrypted, which in turn is used to encrypt the actual data.

The symmetrical encryption is always carried out with a modified CFB mode . The actual initialization vector consists only of zero bytes, for which the plain text is preceded by 10 (for block ciphers with 64-bit block size) or 18 (for 128-bit block size) bytes. These consist of a block of random data and the repetition of the first two random bytes. This redundancy makes it possible to recognize during decryption (with an error probability of 1: 65536 = 0.0015%) whether it was decrypted with the correct key.

signature

In addition to encryption, OpenPGP also supports digital signatures with which recipients can determine the authenticity and authenticity of messages. For this purpose, the sender creates a checksum (also called hash value ) of the data, which is then encrypted with the private key (the signed data remains untouched). The recipient can check the signature with the sender's public key.

Algorithms

OpenPGP is currently standardized in RFC 4880 , the successor to RFC 2440 . RFC 4880 specifies that an implementation must support the Elgamal encryption method , DSA , Triple DES and SHA-1 . It is also recommended there that implementations support the encryption and signature procedures described in PKCS # 1 v1.5, based on the RSA cryptosystem , as well as AES-128 , CAST-128 and IDEA . There are also a number of other methods that can be used with OpenPGP. The standard was expanded to include Camellia in 2009 by RFC 5581 . In 2012, RFC 6637 added support for Elliptic Curve Cryptography ( ECDSA , ECDH ).

Key authentication

Public keys can be signed (“certified”) by other key owners. The signer / certifier thus proves that he has checked both the key (i.e. the fingerprint) and the user ID contained in the key (for which, however, there are no fixed rules). If a public key has several user IDs, then these must be certified individually. In contrast to S / MIME, this signing is not based on a hierarchical system in which only a higher-level authority is allowed to sign keys from subordinate authorities, but rather from a network of trust ( web of trust ) in which each participant can sign the keys of others. The statement made (implicitly) with the signature about the authenticity of the key and the respective identity (name, e-mail, comment) enables third parties to assess the authenticity of the certificate. For example, if B trusts A's certifications (either completely or partially), B could also trust the public key of subscriber C, who is unknown to him, if this key was certified by A. The certification only relates to the authenticity of the key; Whether A also trusts C's certifications cannot be seen from A's signature and is irrelevant for A's certification of C. The validity of certificates is public information, the trust of users in others is private information. Unfortunately, key validity and certification trust are very often confused with one another.

Another, simpler method of verifying the authenticity of a key is to compare the fingerprint . This is a checksum of the key data (public master key plus its generation time stamp) in hexadecimal form (for example "72F0 5CA5 0D2B BA4D 8F86 E14C 38AA E0EB"), which can be easily compared in a direct conversation, by telephone or by letter .

Structure of the certificates

OpenPGP certificates (the current version 4) consist of a number of components. Your data is not certified in its entirety, but in individual components, partly by the key owner and by third parties, partly only by the key owner. This means that a certificate can change over time. Components can be added, changed and deleted. The most important components of an OpenPGP certificate are:

  1. Exactly one public master key (to which the fingerprint refers, which identifies the key as a whole), with the date of creation and, if applicable, the expiry date
  2. one or more user IDs (text describing the user, typically in the format first name last name (comment) <e-mail address> , possibly with expiry date)
  3. any existing subkeys (possibly with expiry date)
  4. Any additional information on the use of the key (preference of hash and encryption algorithms, preferred keyserver, URL of a key policy)
  5. Signatures of the key owner or of third parties confirming the authenticity of the components mentioned or revoking their validity; Signatures have a creation date and possibly an expiration date

Third parties only sign the combination of the master key and a user ID; therefore each user ID has to be signed individually. A third party is free to decide whether to sign all user IDs. The key owner signs everything. Unsigned components are worthless and are ignored. This allows the owner to change his preferences, additional information and validity periods without authorization. He can add and revoke subkeys and user IDs. OpenPGP software automatically accepts subkeys (if they are self-certified), but not user IDs. If you have your key certified by third parties and then add an email address (which is not certified by third parties), the users of the certificate will receive a warning if they want to encrypt the added email address. The display of the most important elements in GnuPG (--list-sigs): 

     pub    1024D/0x12345678 2005-09-05
            D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 1234 5678

     uid    Vorname Nachname <vorname.nachname@example.org>
     sig    0x12345678      Vorname Nachname <vorname.nachname@example.org>
     sig    0x87654321      Zertifizierer <zertifizierer@example.org>

     uid    Vorname Nachname (Geschäftsführer der Beispiel GmbH) <vorname.nachname@example.net>
     sig    0x12345678      Vorname Nachname <vorname.nachname@example.org>
     sig    0x87654321      Zertifizierer <zertifizierer@example.org>

     sub    2048R/0x51B279FA 2010-03-04 [verfällt: 2013-03-03]
     sig    0x12345678      Vorname Nachname <vorname.nachname@example.org>

It can be seen that there is only one master key ( pub ), that it is a 1024-bit DSA key and when this master key was generated. His fingerprint is underneath. The ID, which is mostly used to identify keys, is the last part of the fingerprint. Then two user IDs ( uid ) can be seen, both of which contain a name and an e-mail address and which have both been signed by the associated key itself and by another key. Only one of the user IDs contains a comment, in this case a job position. In this way, an organizationally appropriately qualified key of a company (e.g. that of the managing director) can certify the position of employees of the company towards third parties who trust the first key. It can also be seen that subkeys ( sub ) are only signed by their master key, but not by third parties.

Unlike X.509, the individual components of the certificate are combined without cryptography. The cryptographic security is only located within the component. You can therefore delete parts of a certificate unnoticed. This means that the user can generally not be sure that a certificate that he (as usual) obtained from an insecure source is complete. To provide this security, a certificate can be exported to a file and then signed.

Qualified signatures according to the signature law

The German Signature Act (SigG) differentiates between electronic signatures , advanced electronic signatures and qualified electronic signatures . The latter are the actual content of the law, the first two groups are only used for delimitation. The SigG places both technical and organizational requirements on the recognition of qualified signatures. Currently (2012) the certification service providers do not offer any qualified certificates based on OpenPGP, so it is not possible to generate qualified signatures with OpenPGP. There are also technical reasons for this. The current concept of OpenPGP includes

  1. that only the main key (together with a user ID) is certified, but not the subkeys
  2. that one can generate new subkeys with a master key.

The signature law requires that the private keys of qualified certificates are stored in hardware from which they cannot be read. These are typically smart cards . Since the current version of OpenPGP treats the signatures of subkeys in the same way as those of master keys, normal OpenPGP keys are in principle not suitable for qualified signatures. But even if an atypical OpenPGP key was generated that complies with this requirement, the hardware and software used for its generation and storage would have to be checked by a body recognized by the BSI to determine whether it meets the security requirements of the law. The cost of such a check is another obstacle to the availability of OpenPGP for qualified signatures.

The German Signature Act was replaced by the Trust Services Act on July 29, 2017 .

Standards

Web links

Individual evidence

  1. ↑ https://lists.gnupg.org/pipermail/gnupg-devel/2014-January/028141.html
  2. ↑ validity vs. Trust (openpgp-schulungen.de)