In comparison to symmetrical cryptography, asymmetrical algorithms are based on two keys. In terminology keys are called: private and public. Message or data set can be encrypted by using one of them and decrypted by the remaining one. Thank's to this solution one part of key-set can be published and used for users to encrypt messages. If the second key is kept secret, owner can be sure that only he can read the message. Algorithms are built in such a way, that having only one key it is very hard to compute the second one.
The RSA public-key cryptosystem offers both encryption and digital signatures (authentication). Ronald Rivest, Adi Shamir, and Leonard Adleman developed the RSA system in 1977 and the name of it comes from the first letter in each of its inventors' last names.
The RSA algorithm works as follows: two large primes, p and q, are taken and n = pq is computed; n is called the modulus. Than the number, e, less than n and relatively prime to (p-1)(q-1) is taken As a result e and (p-1)(q-1) have no common factors except 1. Another numberThank's to the algorithm, it is currently difficult to obtain the private key d from the public key (n, e). However if one could factor n into p and q, then one could obtain the private key d.The lenght of a key can be defined. The longest possible value is 2048 bits, what in comparison with symmetrical cryptography algorithms is much bigger. Thus the security of the RSA system is based on the assumption that factoring is difficult. More information about RSA is available on a following link.
Another important feature concerning private / public keys is speed. The whole process is much slower. Although it has not a very big difference on a small data sets, but when speaking about big files or data, it is much more important.
In order to create a priviate key, commend openssl genrsa needs to be used.
On the picture below also private key content is presented.
The public key is computed from the private one by using commend openssl rsa .
On the picture below also public key content is presented.
The file rsa_example.txt is used in this case. The output file is called asymmetrical.rsa.
The whole process was conducted by using the following commends:
openssl rsautl -sign for encryption
and openssl -verify for decryption
| Back to the the "Workshop 1" site, or to the home page |
Both two types of cryptographic algorithms have advantages and disadvantages. On one hand very fast and efficient symmetrical solutions seem not to give security on a desired level. This issue is provided by asymmetrical tools, which in contrary are much slower. It was a great invention to combine these two ideas into one protocol, which is now used in many applications.
Main idea of this process is presented on the picture below. As a result two people A and B (or computers) from different
places can communicate with eachother fast on a very secure level.

The main idea is presented in the following example. In this case I pretend that I have two personalities and want to tell something to the second one. Suppose that one is called "left" and the second "right". Although it can be seen as a mental desease, I am in perfect fit (at least I hope so). I will use the same RSA keypair as in the previous examples.
Let's get down to work! This is "left" side: I have the "right"'s public key and want to tell that I cannot sleep because "right" side of me is snoring. I created a message message.txt. Than I encrypted this file by using symmetrical algorithm 3DES. Now I need to encrypt the password by using "right"'s public key and send it pass.txt along with the encrypted message pass.enc. In this way only addressee can read my to secret message. All commands have been used before, so I present only result table.
Now I change my personality and become "right" side. I recieved two files, one with the message message.enc and second with the password pass.txt.
Password is encrypted with my public key, and message is encrypted with 3DES symmetrical algorithm. Now I need to compute the password
and read the message.
By using the same commends as in previous examples I compute message from ??? I do not know!
Authentication is any process through which one proves and verifies certain information. Sometimes one may want to
verify the origin of a document, the identity of the sender, the time and date a document was sent and/or signed,
the identity of a computer or user, and so on. A digital signature is a cryptographic means through which many of
these may be verified. The digital signature of a document is a piece of information based on both the document
and the signer's private key. It is typically created through the use of a hash function and a private signing
function (encrypting with the signer's private key). In this way the whole process is efficient and secure.
Suppose Alice wants to send a signed document or message to Bob. The first step is generally to apply a hash function
to the message, creating what is called a message digest. The message digest is usually considerably shorter than the
original message. In fact, the job of the hash function is to take a message of arbitrary length and shrink it down
to a fixed length. To create a digital signature, one usually signs (encrypts) the message digest as opposed to the
message itself. This saves a considerable amount of time, though it does create a slight insecurity (addressed below).
Alice sends Bob the encrypted message digest and the message, which she may or may not encrypt. In order for Bob to
authenticate the signature he must apply the same hash function as Alice to the message she sent him, decrypt the
encrypted message digest using Alice's public key and compare the two. If the two are the same he has successfully
authenticated the signature. If the two do not match there are a few possible explanations. Either someone is trying
to impersonate Alice, the message itself has been altered since Alice signed it or an error occurred during transmission.
Information taken from
http://www.rsasecurity.com/rsalabs/faq/2-2-2.html
First,Sender computes the hash check-sum of the document and encrypt it with his private key. In this way he signes the document. Document (encrypted with the Receiver public key) is sent together with the signature. Than after encrypting document Reciever comutes hash check-sum of it, decrypts signature by using Sender's public key and compares these values. If they match he can be sure that message was written by Sender and reached the destination without any changes.
In the previous example Reciever ("right" side) was not sure who sent a message and if the message was changed during it's journey on the net. Now we upgrade the proccess, so that everything for reciever will be clear.
First I created a message digsign_example.txt, then I computed the hash check-sum of it (SHA1).
I need encrypt them by using two different keys. The document (digsign_example.txt) needs to be encrypted with Reciever public key
and hash check-sum with my private key. Suppose that public keys are published to both sides of process. I sent two files: one is
encrypted message digsign_example.encand second is encrypted hash check-sum of the document digsign_hash.enc.
The commends used are as follows:
Now the Reciever has to compute the message, count hash check-sum of it, decrypt the signature's file and compare it these
two files are the same.
The commends used are as follows:
| Back to the the "Workshop 1" site, or to the home page |