OpenPGP
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:
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:
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.
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
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
-
Can 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). - There is no corresponding option for HTML mail.
- File 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).
- 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.
-
Can 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 (
-
PGP / MIME as a clean technical solution ( MIME extension according to RFC 3156 )
- This 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).
- However, this procedure only protects the content of the mail, not its header data (e.g. sender, recipient, subject, date).
- The 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:
- 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
- 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)
- any existing subkeys (possibly with expiry date)
- Any additional information on the use of the key (preference of hash and encryption algorithms, preferred keyserver, URL of a key policy)
- 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
- that only the main key (together with a user ID) is certified, but not the subkeys
- 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
- RFC 2440 OpenPGP Message Format
- RFC 4880 OpenPGP Message Format
- RFC 5581 The Camellia Cipher in OpenPGP
- RFC 6637 Elliptic Curve Cryptography (ECC) in OpenPGP
- RFC 3156 MIME Security with OpenPGP
Web links
- IETF OpenPGP working group (ended)
- GnuPG - GNU Privacy Guard, a program according to the OpenPGP standard (multilingual)
- Verify PGP / MIME signatures manually
- Symantec PGP Product Family - formerly PGP Corporation (maker of the original PGP system)
- OpenPGP Alliance (English)
- The International PGP Home Page (obsolete, English)