/**

@page Security_intro_PKC Public Key Cryptography 

\n

Public key (sometimes called @ref asymmetric) cryptography allows encrypted messages to be sent without the need to establish a

shared secret key. It involves the use of two keys called a key pair: a private key and a public key. The private key is 

kept secret, and a public key is made publically available. 

All entities using such a system would typically possess a key pair. They will use these keys either for @ref encryption or 

@ref decryption. In any case, if one of the keys is used for @ref encryption, then only the other key can be used for @ref decryption. 

So, in public key cryptography, to send a message in an encrypted form to a receiver, the sender:

@li Gets hold of the receiver's public key.

@li Encrypts the message with the receiver's public key.

@li Sends the encrypted message.

The receiver then decrypts the message using its private key. Only the receiver, who has access to the corresponding 

private key, can decrypt it.

That is the basic process used for a pure PKC system. In the real world, however, public key cryptography is typically 

used in conjunction with traditional symmetric key cryptography. This is done in order to reduce key management problems 

while at same time taking advantage of the superior speed of the latter. The method for doing this is called a digital 

envelope: a random symmetric private secret key is generated, the message is encrypted with this secret key using a 

symmetric algorithm, and then the secret key is encrypted with the receiver's public key using an @ref asymmetric algorithm.

The other main use for public key cryptography is in signing (see: @ref Security_signatures).

While public key cryptography ensures that only the entity with access to the corresponding key will be able to read the 

message or could have signed a given message, it gives no assurance that this entity is/are actually the entity they 

claim to be. This is where certificates come in. @ref Security_intro_certificates are needed to solve the problem of 

@ref authentication.