iTranslated by AI

The content below is an AI-generated translation. This is an experimental feature, and may contain errors. View original article
🔐

A Review of Public Key Infrastructure

に公開

This is a follow-up to my previous article, "Never Hand Over the Private Key of Public-Key Cryptography." As I am currently organizing my cryptography-related environment, I'm writing this article partly as a review for myself.

Note that this article is based on a Japanese document titled "OpenPGP and PKI," which was previously published on OpenPKSD.org (Internet Archive). If you're interested, you might want to dig through the archives from that time.

Symmetric-Key and Public-Key Cryptography

First, let's recap from the previous time.

The characteristics of symmetric-key cryptography are as follows:

  1. High processing speed for encryption and decryption
  2. Data size is almost the same for plaintext and ciphertext
  3. The key must be shared among those exchanging ciphertexts and must not be known to third parties

And the characteristics of public-key cryptography are as follows:

  1. Processing speed for encryption and decryption is slower compared to symmetric-key cryptography
  2. Ciphertext size tends to be huge relative to the plaintext
  3. Users only need to share the public key, and the public key may be known to third parties

This last item is the greatest merit of public-key cryptography. Not sharing a "secret" with the party you are exchanging data with means there are fewer points of attack from an attacker's perspective. For example, the recommendation to use cryptographic software or devices employing public-key cryptography (rather than password authentication) for remote service authentication is due to this benefit[1].

https://text.baldanders.info/remark/2020/09/authenticator-and-aal/

Whose Public Key Is It?

In public-key cryptography, if you are only establishing an encrypted session using something like Diffie–Hellman key exchange, you don't really need to worry about "whose public key it is," and you could even create an ephemeral key pair[2] every time (most modern encrypted communication trends are variations of this).

However, if you are going to perform data encryption or digital signatures, you need to create and operate a persistent[3] key pair, and you must prove "who owns" the public key you expose to others. This is because anyone can create a public key.

The mechanism to prove (certificate) "whose public key is this" is the "Public Key Infrastructure (PKI)."

Public Key Infrastructure

Finally caught up to the title (lol).

Three Functions of Public Key Infrastructure

There are mainly three functions required for a Public Key Infrastructure.

  1. Register the key owner[4] and issue a public key certificate.
  2. Store public key certificates for verification.
  3. Revoke the public key certificate if the public key is compromised or no longer valid.

In other words, any system or service that fulfills these functions can be said to meet the requirements of a Public Key Infrastructure.

In the following sections, I will briefly introduce X.509 and OpenPGP, which are representative Public Key Infrastructures.

X.509 Public Key Infrastructure

X.509 was originally a standard for general online authentication based on the OSI X.500 directory system, but it has undergone revisions to allow for more flexible operation. Since the public key infrastructure used in many scenarios, such as the HTTPS encryption protocol for web services, is X.509, many people recognize "PKI = X.509."

In X.509, an issuing organization called a Certificate Authority (CA) handles everything from the issuance to the revocation of certificates. Furthermore, Certificate Authorities have a hierarchical structure, forming a tree-shaped chain through mutual authentication between CAs. Because of this, X.509 is sometimes called a hierarchical PKI.

OpenPGP as a Public Key Infrastructure

OpenPGP is a standard for cryptographic technology (RFC 4880) originating from the cryptographic software PGP, but it fulfills the three functions of a public key infrastructure mentioned earlier.

While OpenPGP does not have an authoritative body like a Certificate Authority, it is established by users directly performing mutual authentication with one another[5]. This mechanism of OpenPGP is called the "web of trust." A peer-to-peer relationship centered on the user forms a mesh-like chain.

X.509 and OpenPGP

A comparison between X.509 and OpenPGP would look like this:

Feature X.509 OpenPGP
PKI form hierarchical PKI web of trust
Public key authenticator Specialized agency (CA) User
Trust point Root CA User themselves (acquaintance)
Authentication chain structure Tree-type User-centric type
Basis for authenticating authenticators Choice by the user User themselves
Management of certificate revocation Available Incomplete
Cost High Low

To supplement on certificate revocation, in OpenPGP, the key owner revokes the certificate and distributes the revoked public key. Users who do not receive the revoked public key will continue to perform encryption or signature verification using the pre-revocation public key. This is why it is called "incomplete"[6].

There might be differing opinions regarding cost. For a small team, OpenPGP, which allows for ad hoc operation, is certainly low-cost. However, for large organizations or when dealing with an unspecified large number of people, OpenPGP might become unmanageable, and trying to force it could result in complexity that bounces back as a cost.

In X.509, the merit is that it is easy to operate top-down by centralizing authority and responsibility in the Certificate Authority. On the other hand, I believe OpenPGP is suitable for operation within a relatively small team of acquaintances.

So, let's understand the characteristics of our tools well and use them appropriately.

Reference Pages

https://text.baldanders.info/openpgp/web-of-trust/

https://text.baldanders.info/remark/2020/07/requirement-for-encryption/

References

https://www.amazon.co.jp/dp/B015643CPE

脚注
  1. In this article, please note that I am discussing digital signatures collectively as a type of public-key cryptography. ↩︎

  2. The set of a private key and a public key created in public-key cryptography is sometimes called a "key pair." ↩︎

  3. "Persistent" here means operating across a single session or domain. If data signed or encrypted in the past is to be used in the future, the cryptographic keys used for signing/encryption must be maintained similarly. ↩︎

  4. For convenience, the person among the key users who created the target key pair is called the "key owner." The key owner can also be described as the person who holds the private key. ↩︎

  5. Although not common in Japan, overseas events called "[key signing parties](https://en.wikipedia.org/wiki/Key_signing_party "Key signing party - Wikipedia")" are held during meetups and other occasions. It seems that people exchange public key fingerprints as a substitute for business cards. ↩︎

  6. PGP/OpenPGP key servers were conceived to improve the distribution status of public keys, including certificate revocation, and have many years of operational experience. However, in recent years, attacks that could be called "signature bombs" have been observed on public keys on key servers, and public key distribution is still a matter of debate. Additionally, GnuPG, an OpenPGP implementation, has started strengthening its integration with LDAP. ↩︎

GitHubで編集を提案

Discussion