To understand the working mechanism of PGP, it is necessary to have an idea about the basic concepts of cryptography, in particular – about symmetric and asymmetric approaches to encryption. The explanations below are of an informative nature, since within the framework of this section, we will not delve into cryptography and the mathematical methods used in it. To simplify perception, the encryption process should be understood as a kind of black box (actually a mathematical expression), passing through which data, under the influence of keys (essentially variables in the equation), is either encrypted or decrypted. PGP – Pretty Good Privacy – is the most common and popular data encryption technology. In the network, you can often find such abbreviations as PGP, OpenPGP, GPG (GnuPG). If we do not take into account the details, then all are close relatives and are built on the same principles, due to which they are interchangeable and mutually compatible. This section does not provide a historical reference, but if there is an interest in history, you can familiarize yourself with the personality of Phillip Zimmerman – the creator of PGP. The main difference between the asymmetric method and the symmetric method is that even if a third party intercepts a message encrypted with a public key, it will not be possible to decrypt it without the private part.
A significant disadvantage is that the asymmetric approach is quite resource-intensive, so it is simply impractical to use it for a large amount of data. However, this method has found application in connection with symmetric encryption – such a tandem is often called hybrid encryption. In this context, it assumes that some session is established between the data exchange participants, during which an exclusively symmetric method is used to optimize the time spent on data encryption and decryption. Symmetric keys are sent using an asymmetric encryption mechanism – that is, symmetric keys are encrypted with the public key of the recipient, and in this way the problem of spreading secrets of the symmetric method is solved.
Assumes that both the sender and receiver use the same key for both encryption and decryption. That is. anyone with such a key can easily read all the data they encrypt.
Although this method is the fastest in terms of working with data, it has one critical drawback – the problem of secure key distribution. In fact, the only safe way to pass the key to the other party is to transfer it personally on some physical medium, which in today’s reality is extremely inconvenient. Therefore, in its pure form, this method is not used and always uses asymmetric encryption, which solves the problem of secure distribution of symmetric keys.
Assumes that the receiver and sender have a key pair. Each key pair includes:
It should be noted that at this point there is often a misconception that only a private key can be decrypted, and only a public key – to encrypt. This is fundamentally wrong – there are no such technical restrictions. Both parts of the key are absolutely equal, the division into public and private parts is conditional, and if you wish, you can use the public key as private, and the private key as public.
First of all, PGP should be perceived not as a single algorithm, but as a sequence of several algorithms. Depending on the implementation and even the version for each stage of this sequence, different variations of algorithms can be used.- At the same time, both the original PGP technology and non-proprietary versions such as OpenPGP are fully compatible with each other.
A one-time symmetric key is generated automatically using a random number generator
It generally looks like this:
Creating a data hash.
Creating a one-time symmetric key *
Signature of the hash obtained in step 1 with the private key of the sender.
Encrypt compressed data with a single session symmetric key.
Encryption of a one-time key and an encrypted message with the recipient’s public key.
Signature verification (recipient tries to decrypt signature with sender’s public key)
Decryption of a symmetric key
Decrypt data with your private key
Getting a data hash
Integrity check (comparison of two received hashes)
The signature check allows you to make sure that the hash was sent by the expected entity or user. If the signature verification fails, such notification may not be considered valid. To make sure that the data arrived without corruption or interference, the two hashes can be compared. If the sent and received hashes are different, the data is considered compromised and cannot be considered reliable.
Key servers are separate resources that store data about registered keys linked to the owner’s ID or email. There are both public servers, where anyone can export their keys, and closed. The latter are often tied to certain programs or services that allow the end user to encrypt. For example, the same FlowCrypt stores the public keys of its users on the server attester.flowcrypt.com. It should be noted that the FlowCrypt server cannot be considered completely closed, because anyone wants to know the id or email. can look for public keys there.
Key-servers should be considered as an optional feature: if the goal of creating an asymmetric key pair was to allow a limited group of people to communicate, it will be enough to exchange public keys within that group.
In addition, ECDSA / EdDSA offers several variations of algorithms to choose from. In short:
ed25519 (cv25519) – uses EdDSA, the default is standard.
brainpool – uses ECDSA, developed by a large community of German cryptographers.
brainpool – uses ECDSA, developed by a large community of German cryptographers.
In most cases, ed25519 or brainpool is chosen, because the presence of NIST in the official US guidelines leads many users to believe that somewhere within this variation there is a loophole for the secret services. RSA and DSA offer to choose the length of the key, and in this choice should be based on the real requirements for cryptocurrency and speed. It’s important to remember that even the longest keys can be hacked, and security is a delicate balance between paranoia and minimizing risk.
Most often, PGP keys are found in the forwarding of messages (banal email), but they are not limited to this field of application. Various repository management systems (GitLab, GitHub, Bitbucket) also support PGP for accessing repositories and commit signatures.
There are many ways to generate your key pair. Often programs like FlowCrypt offer to create a pair of keys for the user. The advantages include full automation of the process and location of the key on a separate key-server, rather than the default for many keyserver.ubuntu.com. However, for more control, it is better to do the generation yourself – so in case of compromise, you can quickly recall the lost key and the generation options become more. The most popular key management programs are Kleopatra and the gpg console solution.
If no PGP keys have been created on the machine before, Cleopatra will prompt you to create or import them. We will not dwell on imports, because everything is intuitive there, but I would like to draw attention to some moments of key creation.
At the bottom, immediately click on Advanced Settings and see that they offer a variety of algorithms.
In principle, it is permissible to leave everything as default. You can read more about these algorithms in the section below. Also pay attention to the Valid until check mark. Depending on the case, it can be removed or left. Click Create, after which Cleopatra will offer to make a backup of the private key, which we recommend not to refuse.
To get the public key, simply select the desired pair from the list and press the large Export button. It is important to note that Cleopatra does not send the public key to the key server automatically! All keys generated by the program will be available only within the local system for programs that support PGP (eg gpg, Thunderbird, other key managers). If you want to make the public key public – you need to left-click on the desired pair from the list and select the Publish on server option. It is worth noting that from the moment of publication to the availability of the public key may take several hours.
In general, Cleopatra is quite a self-sufficient tool. If for some reason you do not have the ability or desire to use plugins or separate programs to encrypt messages, it is enough to import into Cleopatra public keys of the desired entities or users. With them, Notepad can encrypt text with any available public key of the recipient, and already encrypted text can be sent in any convenient way.
In the console version, just gpg / gpg2. Usually the package is already in the system, but if this is not found, you can use the command
sudo apt install gnupg
The utility itself has a rather expressive –help and man manual, so a very dry how-to will be given here.
Generating keys can be done in several ways:
sudo git –gen-key – will ask only the name, email and enter the password, the other parameters will be the default (algorithm – RSA, key expiration date – two years).
sudo gpg –full-generate-key – gives more flexibility in creating keys, allows you to choose the encryption algorithm, the expiration date of the keys, as well as a bonus – the ability to leave a comment on the keys. The latter is quite useful if, for example, the user has several boxes and uses different key pairs for them. Then the sender can use the comment to determine which of the public keys to use for which mail.
Once the keys are generated, they will only be available on the local system. To share them with the world, you need to select a key server and send it there. This is done as follows:
sudo gpg –send-keys KEY_FINGERPRINT або sudo gpg –keyserver KEYSERVER –send-keys KEY_FINGERPRINT
Where KEYSERVER is the address of our server (by default hkps.pool.sks-keyservers.net), and KEY_FINGERPRINT is the imprint of the required key.
You can find it out through the command:
sudo gpg –list-keys
For a better understanding, let’s take the key as an example:
pub rsa3072 2022-04-30 [SC [expires: 2024-04-29] 980A28B56D8DD95B3B954 D8A2F86AF60ED1C317 uid [ultimate] test-user-1984 <[email protected]> sub rsa3072 2022-04-30 [E] [expires: 2024-04-29]
We will understand what pub and sub keys are below, while we will just consider what the conclusion tells us.
pub/sub – key type
rsa3072 – the instruction which algorithm was used for creation of a key, in our case it is RSA with key length 3072
2022-04-3 – date of creation
[SC] – usage flags, because keys can be used for different purposes, what they are intended for is always indicated opposite them: C – key certificationS – sign dataE – encrypt communicationsstorageA – authenticationActually, there are more such flags, and they are set in the hex system, but detailed analysis goes beyond the basic framework of the course. If you want to get acquainted with the device of PGP keys, you should read the article https://davesteele.github.io/gpg/2014/09/20/anatomy-of-a-gpg-key/
[expires: 2024-04-29] – the date when the key ceases to be valid, ie. it will expire
980A28B56D8DD95B3B9549D8A2F86AF60ED1C317 – fingerprint, unique key print
uid – user ID, usually given by name and address[ultimate] – key trust status. For personally generated it will always be ultimate, while exported new keys can be marked as undefined, never, marginally, fully, ultimately. All these statuses are related to the Web of Trust, which can be read below.
In fact, PGP has long since abandoned the single key pair and now it’s more like a connection. Some keys are used for signing, some for encryption, others for access to resources. At the same time, there is a hierarchy between them: at the head is always the root, verified and trusted key. As a rule, they try not to use these keys for encryption or signatures, instead they use sub-keys created on its basis. Roots are used for certificates. Such a certificate states that such a user or entity is the owner of such a key, all sub-keys (listed) which are also considered valid and trusted, and can be used for something. Why complicate life so much and why not create a simple pair of PGP keys for each case? It’s all about the Web of Trust device. For a key to be considered trusted, it must be guaranteed by a number of users, and the more users believe the key is valid, the more Web of Trust sites will be quoted. If for some reason the key needs to be replaced, you will have to earn trust again, which is not always suitable for the type of tasks. This problem is completely solved by sub-keys. When it is revoked or replaced, it is enough to update the data in the certificate and from now on the new sub-key will enjoy the trust level that has the root key, and the remote sub-key will have a reference in its parent, but will no longer appear in the certificate. accordingly, will be considered valid.
Speaking of PGP, it is impossible not to touch on the topic of Web of Trust at least instantly. In general, there are two main models of authentication (authentication) of keys / user certificates:
x.509 PKI – a centralized system is based on the fact that there are a number of resources (CA – certificate authority), which issue certificates and which are trusted by all network members.
Web of trust – a decentralized system, where trust in the certificate is determined by the attitude of network members to a particular certificate.