diff -r 000000000000 -r 2c201484c85f cryptomgmtlibs/securitydocs/doxygen_docs/Security_intro_PKC.dox
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/cryptomgmtlibs/securitydocs/doxygen_docs/Security_intro_PKC.dox	Wed Jul 08 11:25:26 2009 +0100
@@ -0,0 +1,35 @@
+/**
+@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.
+
+
+
+*/
\ No newline at end of file