Electronic signature for dummies: what it is and how not to choke. Part 2
Part 1
Continuing to reveal secret knowledge about digital signature in simple language, let us examine what we need for convenient and efficient work with them, as well as the main difference between the S / MIME + X.509 and PGP camps.
')
Before considering the features of these two large camps, it is worth considering what information the recipient needs to verify the signature (and our encrypted hash can already be called a signature), and in what form it can be transferred to it.
Each of the pieces of information can be passed along with the public key, or with our signature, or both, and with this, for greater convenience. Of course, you can not share information on the transmitted with the public key and transmitted with the signature. But then each time sending the signed information, we send the same thing. As if to each paper letter we send (even a short one, in two lines), we would add the addition “Hello! This is me, V. Pupkin, whom you met on the Red Square of Moscow, where we met, then went to a restaurant, then <...> ". Agree, slightly uncomfortable.
But back to our information needed to verify the signature.
Let's start with a simple one: information that will allow us to find out who made this signature. As we have already agreed, asymmetric encryption allows us to uniquely link our public key and the received signature. The trouble is that the public key itself is a set of bytes. At the same time, he, of course, is associated with a closed one, which we (that is, the sender) own, but this connection is not obvious to the recipient. He has a set of bytes from V. Pupkin, from I. Petrov, from S. Sidorov ... And from a dozen other people. And how should he identify them? Keep a separate registry for who owns a set of bytes? This is what turns out the second registry (besides where it should be recorded, with which hash function which hash was made)! And again, uncomfortable!
So, you need to associate each public key with information about who owns this key, and send it all in one package. Then the registry problem is solved by itself - the package (and if more correctly, the container) with the public key can be simply viewed and immediately understood its ownership.
But this information still needs to be linked with the signature that came to the recipient. How to do it? It is necessary to build another container, this time for the transfer of the signature, and in it to duplicate information about who created this signature.
Continuing our analogy with a beautiful lock, we write on the key "This key opens the lock of V. Pupkin". And on the castle, too, write "Castle V. Pupkin." Having such information, the recipient of our box will not insert each of his keys at random into our lock, but will take our key and immediately open it.
Now, using the transferred information, during verification you can find the container of the public key, take the key from there, decrypt the hash and ...
And actually, that "and"? After all, we have not yet solved the problem, how to convey to the recipient information about what hash function was used for the hash, but this information is necessary for verification of the signature! It can be solved quite simply: put this information in a container with our public key. After all, a bunch of “hashing - encrypting the result of hashing” is considered a procedure for creating a digital signature, and its result is a signature. So, it seems quite logical to combine the hash encryption algorithm and the hash function with which it is formed into a bundle. And it is also necessary to deliver this information in conjunction.
Now, briefly go back to the information on the signer. What kind of information should this be? FULL NAME? No, V. Pupkin many. Full name + year of birth? So V. Pupkin born on the same day also abound! Moreover, it can be Vasily, Victor, or even Vasilisa or Victoria Pupkin. So, there should be more information. It should be so much so that the coincidence of all the parameters by which we identify the person, was the most incredible.
Of course, such a package of information is possible to create. That's just working with him is already difficult. After all, our public key containers must be sorted, stored, used, in the end. And if for each use you have to specify fifty parameters, then already on the second container it will become clear that something needs to be changed. The solution to this problem, of course, was found.
To understand what it was, let us turn to the paper document that we all have: to the passport. In it you can find and name, and date of birth, and gender, and a lot of other information. But, most importantly, you can find a series and number in it. And it is the series and the number are the unique information that is convenient to consider and sort. In addition, they are significantly shorter than all the rest of the information combined, and still allow you to identify the person.
Applying the same approach to public key containers, we get that each container must have a certain number, a sequence of characters, unique to it. This sequence of characters is usually called an identifier , and the containers themselves are called certificates , or simply keys.
This is where the fundamental differences in the ideologies of OpenPGP and S / MIME + X.509 begin. For a brief understanding of them, let’s return to our passport analogy.
You can use your passport when you buy tickets, when you draw up documents, to issue a pass to any territory and even to the territory of other countries! That is, you use it to identify your personality in the most diverse, often completely unrelated to each other, places, with a variety of people. And everywhere your passport is accepted. The guarantor of the fact that you are you is a third party in your relations with others: the state. It gave you your passport, specially issued, signed and certified, and that is why your passport is such a universal document.
On the other hand, in a circle of friends, or within a company, you just have to introduce yourself like this: “B. Pupkin from your group at the institute "or" V. Pupkin from the sales department. And the people with whom you contact in this circle no longer need a third party, they already remember Pupkin from the group with whom they had been studying for five years, or Pupkin from the sales department with whom they recently went to dinner, and the information you provided is quite enough.
You can also divide these two camps.
X.509 certificate is an analogue of our passport. Here certificates are issued to you by a harsh third party, the guarantor of your identity: the Certification Authority (CA). The person who receives your signatures can always contact the CA and ask for information of interest to him on this particular certificate.
PGP (and the OpenPGP standard, which appeared later) was created on the basis of the so-called trust networks. Such an idea implies that signatures are exchanged by people who do not need a third party for their relationship, but only protection from bad individuals is needed.
Of course, over time, this division has become quite conditional, since at the moment both in S / MIME + X.509 and PGP, you can use the methods of the rival camp. But nevertheless, the standards developed for a rather long time in parallel and developed to the extent that mutual compatibility between them became impossible.
The standard S / MIME + X.509 became more popular as a standard, due to its participation in a more competent third party, however, PGP also has a certain number of trumps in its bosom, with the help of which it does not die, but continues to develop successfully .
More detailed consideration of each of the formats, as well as recommendations, when, where and which of them you can read in the following articles.
Part 3
Continuing to reveal secret knowledge about digital signature in simple language, let us examine what we need for convenient and efficient work with them, as well as the main difference between the S / MIME + X.509 and PGP camps.
')
Before considering the features of these two large camps, it is worth considering what information the recipient needs to verify the signature (and our encrypted hash can already be called a signature), and in what form it can be transferred to it.
Each of the pieces of information can be passed along with the public key, or with our signature, or both, and with this, for greater convenience. Of course, you can not share information on the transmitted with the public key and transmitted with the signature. But then each time sending the signed information, we send the same thing. As if to each paper letter we send (even a short one, in two lines), we would add the addition “Hello! This is me, V. Pupkin, whom you met on the Red Square of Moscow, where we met, then went to a restaurant, then <...> ". Agree, slightly uncomfortable.
But back to our information needed to verify the signature.
Let's start with a simple one: information that will allow us to find out who made this signature. As we have already agreed, asymmetric encryption allows us to uniquely link our public key and the received signature. The trouble is that the public key itself is a set of bytes. At the same time, he, of course, is associated with a closed one, which we (that is, the sender) own, but this connection is not obvious to the recipient. He has a set of bytes from V. Pupkin, from I. Petrov, from S. Sidorov ... And from a dozen other people. And how should he identify them? Keep a separate registry for who owns a set of bytes? This is what turns out the second registry (besides where it should be recorded, with which hash function which hash was made)! And again, uncomfortable!
So, you need to associate each public key with information about who owns this key, and send it all in one package. Then the registry problem is solved by itself - the package (and if more correctly, the container) with the public key can be simply viewed and immediately understood its ownership.
But this information still needs to be linked with the signature that came to the recipient. How to do it? It is necessary to build another container, this time for the transfer of the signature, and in it to duplicate information about who created this signature.
Continuing our analogy with a beautiful lock, we write on the key "This key opens the lock of V. Pupkin". And on the castle, too, write "Castle V. Pupkin." Having such information, the recipient of our box will not insert each of his keys at random into our lock, but will take our key and immediately open it.
Now, using the transferred information, during verification you can find the container of the public key, take the key from there, decrypt the hash and ...
And actually, that "and"? After all, we have not yet solved the problem, how to convey to the recipient information about what hash function was used for the hash, but this information is necessary for verification of the signature! It can be solved quite simply: put this information in a container with our public key. After all, a bunch of “hashing - encrypting the result of hashing” is considered a procedure for creating a digital signature, and its result is a signature. So, it seems quite logical to combine the hash encryption algorithm and the hash function with which it is formed into a bundle. And it is also necessary to deliver this information in conjunction.
Now, briefly go back to the information on the signer. What kind of information should this be? FULL NAME? No, V. Pupkin many. Full name + year of birth? So V. Pupkin born on the same day also abound! Moreover, it can be Vasily, Victor, or even Vasilisa or Victoria Pupkin. So, there should be more information. It should be so much so that the coincidence of all the parameters by which we identify the person, was the most incredible.
Of course, such a package of information is possible to create. That's just working with him is already difficult. After all, our public key containers must be sorted, stored, used, in the end. And if for each use you have to specify fifty parameters, then already on the second container it will become clear that something needs to be changed. The solution to this problem, of course, was found.
To understand what it was, let us turn to the paper document that we all have: to the passport. In it you can find and name, and date of birth, and gender, and a lot of other information. But, most importantly, you can find a series and number in it. And it is the series and the number are the unique information that is convenient to consider and sort. In addition, they are significantly shorter than all the rest of the information combined, and still allow you to identify the person.
Applying the same approach to public key containers, we get that each container must have a certain number, a sequence of characters, unique to it. This sequence of characters is usually called an identifier , and the containers themselves are called certificates , or simply keys.
This is where the fundamental differences in the ideologies of OpenPGP and S / MIME + X.509 begin. For a brief understanding of them, let’s return to our passport analogy.
You can use your passport when you buy tickets, when you draw up documents, to issue a pass to any territory and even to the territory of other countries! That is, you use it to identify your personality in the most diverse, often completely unrelated to each other, places, with a variety of people. And everywhere your passport is accepted. The guarantor of the fact that you are you is a third party in your relations with others: the state. It gave you your passport, specially issued, signed and certified, and that is why your passport is such a universal document.
On the other hand, in a circle of friends, or within a company, you just have to introduce yourself like this: “B. Pupkin from your group at the institute "or" V. Pupkin from the sales department. And the people with whom you contact in this circle no longer need a third party, they already remember Pupkin from the group with whom they had been studying for five years, or Pupkin from the sales department with whom they recently went to dinner, and the information you provided is quite enough.
You can also divide these two camps.
X.509 certificate is an analogue of our passport. Here certificates are issued to you by a harsh third party, the guarantor of your identity: the Certification Authority (CA). The person who receives your signatures can always contact the CA and ask for information of interest to him on this particular certificate.
PGP (and the OpenPGP standard, which appeared later) was created on the basis of the so-called trust networks. Such an idea implies that signatures are exchanged by people who do not need a third party for their relationship, but only protection from bad individuals is needed.
Of course, over time, this division has become quite conditional, since at the moment both in S / MIME + X.509 and PGP, you can use the methods of the rival camp. But nevertheless, the standards developed for a rather long time in parallel and developed to the extent that mutual compatibility between them became impossible.
The standard S / MIME + X.509 became more popular as a standard, due to its participation in a more competent third party, however, PGP also has a certain number of trumps in its bosom, with the help of which it does not die, but continues to develop successfully .
More detailed consideration of each of the formats, as well as recommendations, when, where and which of them you can read in the following articles.
Part 3
Source: https://habr.com/ru/post/97283/
All Articles