History
Public-key encryption makes key-management much easier. It was invented in 1976 by two Stanford mathematicians, Whitfield Diffie and Martin Hellman. Their discovery can be phrased simply: enciphering schemes should be asymmetric. For thousands of years all ciphers were symmetric—the key for encrypting a message was identical to the key for decrypting it, but used, so to speak, in reverse. To change “5 100 100 5 15 55” or “6 120 120 6 18 66” back into “attack,” for instance, one simply reverses the encryption by dividing the numbers with the key, instead of multiplying them, and then replaces the numbers with their equivalent letters. Thus sender and receiver must both have the key, and must both keep it secret. The symmetry, Diffie and Hellman realized, is the origin of the key-management problem. The solution is to have an encrypting key that is different from the decrypting key—one key to encipher a message, and another, different key to decipher it.
Description
This idea centered on the premise of making the encryption and decryption keys different – where the knowledge of one key would not allow a person to find out the other. Public key encryption algorithms are based on the premise that each sender and recipient has a private key, known only to him/her and a public key, which can be known by anyone. Each encryption/decryption process requires at least one public key and one private key. A key is a randomly generated set of numbers/ characters that is used to encrypt/decrypt information.
Just as you prove your identity through a handwritten signature offline, you use a digital signature to prove your identity online. But without seeing a person sign the document, how can you prove it’s the right person?
This is where public-key cryptography comes in. A large piece of data set to be encoded – for instance, a document – is run through a complicated mathematical computation to generate a single large number, called a hash. The original data and the hash are inextricably linked. If either changes, the hash won’t match and the message cannot be decoded.
To digitally sign a document, a hash is taken of the document and then signed with a user’s (let’s call him Bob) private key. Data scrambled with Bob’s private key can only be unscrambled with Bob’s public key. Any entity can verify the validity of the document by unscrambling the hash with Bob’s public key and checking that against another hash computed from the received data.
If the hashes match, the data was not tampered with and Bob’s digital signature is on it. But because I didn’t watch Bob sign the document, I don’t know that it wasn’t signed by an imposter. This issue is solved because only Bob has his private key, and so he is the only one who could have signed the document.
How do I know I have the correct key to verify the signature? This is where the concept of trust enters the system, creating the need for a certificate authority to verify online identity.
The certificate authority is like an online passport bureau – a trusted entity that makes the PKI system work. The private key is securely generated by Bob, and after verifying Bob’s identity, the certificate authority signs Bob’s public key with its own private root key. The combination of Bob’s public key and the signature of the certificate authority completes Bob’s digital certificate. Bob’s digital certificate is his online passport, validated by the certificate authority’s watermark.
Let’s look at how all this works together in a simple transaction. Bob wants to send Alice a confidential e-mail. Bob would use Alice‘s public key, stored in her certificate, to scramble the message. When Alice receives the message, she uses her private key to unscramble it. Because no one else possess Alice‘s private key, only she can unscramble the message.
The process is similar in complex transactions. Let’s say Bob wants to let Alice order products from his Web site. When Alice is ready to buy, Bob requests that she prove her identity. Alice signs the order with her private key, which was issued by a certificate authority we’ll call TrustCo. She then sends the package consisting of the order and the digital signature to Bob.
Bob needs to get Alice’s and TrustCo’s digital certificate to verify the signature. He validates Alice‘s certificate by verifying TrustCo’s signature (remember TrustCo signs Alice‘s public key, thus forming the certificate), and then uses Alice‘s certificate to validate the signature on the order. If all those tests pass, Alice is actually Alice.
Uses
Public-key cryptography and digital signatures make e-money possible. Banks and customers would have public-key encryption keys. Banks and customers use their keys to encrypt (for security) and sign (for identification) blocks of digital data that represent money orders. A bank “signs” money orders using its private key and customers and merchants verify the signed money orders using the banks’ widely published public key. Customers sign deposits and withdraw using their private key and the bank uses the customer’s public key to verify the signed withdraws and deposits.
Major parts
Plaintext –this is the text message to which an algorithm is applied.
Encryption Algorithm – it performs mathematical operations to conduct substitutions and transformations to the plaintext.
Public and Private Keys – these are a pair of keys where one is used for encryption and the other for decryption.
Ciphertext – this is the encrypted or scrambled message produced by applying the algorithm to the plaintext message using key.
Decryption Algorithm – This algorithm generates the ciphertext and the matching key to produce the plaintext.
The Encryption Process
• The process of encryption begins by converting the text to a pre hash code. This code is generate using a mathematical formula.
• This pre hash code is encrypted by the software using the sender’s private key. The private key would be generated using the algorithm used by the software.
• The encrypted pre hash code and the message are encrypted again using the sender’s private key.
• The next step is for the sender of the message to retrieve the public key of the person this information is intended for.
• The sender encrypts the secret key with the recipient’s public key, so only the recipient can decrypt it with his/her private key, thus concluding the encryption process.
The Decryption Process
• The recipient uses his/her private key to decrypt the secret key.
• The recipient uses their private key along with the secret key to decipher the encrypted pre hash code and the encrypted message.
• The recipient then retrieves the sender’s public key. This public key is used to decrypt the pre hash code and to verify the sender’s identity.
• The recipient generates a post hash code from the message. If the post hash code equals the pre hash code, then this verifies that the message has not been changed en-route.
Resources ::
[2] http://www.networkworld.com