The translator is pressed: encrypt and decrypt the algorithm using the same key, referred to as a symmetric encryption algorithm; the encryption and decryption use of different keys, referred to as asymmetric encryption algorithms, the public key system is an asymmetric encryption algorithm. For symmetric encryption, it is necessary to focus on the symmetric key. For public key algorithms, it is necessary to focus on the private key. Public key encryption algorithm, as well as derived digital signatures, digital certificate technology, not only widely used in Internet messaging, such as SSL / TLS in the HTTPS protocol, but also more and more attention in single-machine systems, such as Windows XP devices Digital signatures are required for program, .NET's GAC Assembly. Microsoft starts from Windows98 / NT4, providing Cryptograph API, supports asymmetric encryption algorithms such as DES, RC2, RC4, IDEA and RSA public key systems, and MD5, SHA, MAC, etc. (Digest, also known as Hash , Hash) algorithm. This article is translated from: http://developer.netscape.com/tech/security/ssl/howitworks.html
This is a vivid and shallow article that is very helpful for understanding the working principle of public key systems. There is a translation of 9CBS:
http://www.9cbs.net/develop/Article/27/27524.SHTM But I think the key places in the article are not accurate enough. On the basis of the upper translation, the key term adopts general translation, and a few places use it, and there is an English original, and there is a local translation. You can compute the original. I hope to help friends who are interested in public key systems.
BTW: All symmetrical encryption and asymmetrical encryption mentioned above, their plus solution algorithms are public, as long as they don't know the key, the algorithm designer has confidence to make the encryption result will not be easily crackd, this is completely related to WAPI Different :).
The following is a translation of Chinese and English:
Public key encryption is a technique that uses a pair of asymmetric keys for encryption and decryption Each pair of keys consists of a public key and a private key The public key is made public by distributing it widely The private key is never distributed...; IT IS Always Kept Secret. Public key encryption is a technique using a pair of asymmetric key encryption or decryption. Each pair of keys consists of a public key and a private key. The public key is widely released. The private key is hidden and does not open.
Data that is encrypted with the public key can be decrypted only with the private key. Conversely, data encrypted with the private key can be decrypted only with the public key. This asymmetry is the property that makes public key cryptography so useful. With the public The encrypted data can only be decrypted by the private key. Conversely, data using private key encryption can only decrypt with public key. This asymmetric characteristic makes the public key encryption are useful.
Using public key cryptography for authentication Using public key encryption method authentication
Authentication is the process of verifying identity so that one entity can be sure that another entity is who it claims to be. In the following example involving Alice and Bob, public key cryptography is easily used to verify identity. The notation {something} key means That Something Has Been Encrypted or Decrypted Using Key. Verification is a process of verifying identity so that one party can confirm that the other party is indeed claimed. In the following examples, A and B, public key encryption will easily check the identity. Symbol {data} key means "data" has been encrypted or decrypted using Key. ... Suppose Alice wants to authenticate Bob Bob has a pair of keys, one public and one private Bob discloses to Alice his public key (the way he does this is discussed later) Alice then generates a random message and sends it to Bob:
A-> b Random-Message
Bob Usess His Private Key To Encrypt The Message and Returns The Encrypted Version To Alice:
B-> a {random-message} BOBS-PRIVATE-KEY
. Alice receives this message and decrypts it by using Bob's previously published public key She compares the decrypted message with the one she originally sent to Bob; if they match, she knows she's talking to Bob An imposter presumably would not know Bob's private key. And Would Thereforept the Random Message for Alice to Check. If you want to test B. B has a pair of keys, one is open, the other is private. B is revealed to the public key of him. A random information is sent to B.
A-> B: Random Message
B Use his private key encryption information to return the encrypted information back to A.
B -> A: {Random-Message}
A received this information and then decrypts the public key disclosed in front of B. He compares information after decryption and the information he was originally sent to B. If they are exactly the same, they will know that they are talking to B. Any middle person will not know the private key of B, and the random information of the secret examination is not properly added.
But wait, there's more, etc., things have not yet finished
Unless you know exactly what you are encrypting, it is never a good idea to encrypt something with your private key and then send it to somebody else. This is because the encrypted value can be used against you (remember, only you could have done the Encryption Because Only You Have The Private Key). Encrypt some information with the private key, and then send it to others not a good idea unless you know the meaning of this information. Because encrypted information may be used to deal with you (remember, others know that this information is you encrypted, because only you have an encrypted private key). . So, instead of encrypting the original message sent by Alice, Bob constructs a message digest and encrypts that A message digest is derived from the random message in a way that has the following useful properties:
The digest is difficult to reverse. Someone trying to impersonate Bob could not get the original message back from the digest. An impersonator would have a hard time finding a different message that computed to the same digest value.
Therefore, replacing the original information sent directly to Jia A A, B is created a summary and encrypts the summary. The information summary is made by any information and has the following useful features:
1. It is difficult to restore raw information from this summary value. Anyone else is worthwhile to get the original information even if it is disguised into B;
2. Different information is difficult to calculate the same summary value;
By using a digest, Bob can protect himself. He computes the digest of the random message sent by Alice and then encrypts the result. He sends the encrypted digest back to Alice. Alice can compute the same digest and authenticate Bob by decrypting Bob's message and Use summary, B can protect yourself. He calculates the summary of any information sent by A, encrypts the summary value, and then transmits the summary value of the encrypted. A can calculate the same summary value and decrypt the information of B, and finally certify B. (Translator Note: Summary (Digest) Algorithm is also called a hash (HASH) algorithm)
Getting Closer further discussion
The technique just described is known as a digital signature. Bob has signed a message generated by Alice, and in doing so he has taken a step that is just about as dangerous as encrypting a random value originated by Alice. Consequently, our authentication protocol needs One more twist: Some (or all) of the data needed to beoriginated by bob.a-> b Hello, Are you bob? b-> a alice, this is bob {digest [alice, this is bob]} BOBS- PRIVATE-Key
When he uses this protocol, Bob knows what message he is sending to Alice, and he does not mind signing it. He sends the unencrypted version of the message first, "Alice, This Is Bob." Then he sends the digested-encrypted Version Second. Alice SECOND. Alice Can Easily Verify That Bob Is Bob, And Bob Hasn't Signed Anyhes He Doesn't Want To.
The technology just discussed is called a digital signature. B is signed directly on the information generated by A, which is equally dangerous to make any information generated by the encrypted A. So our verification agreement also needs to add some techniques: some or all of the information needs to be generated by B:
->: Hello, are you B? B-> A: A, I am {Abstract [A, I am B]}} private key
With this agreement, B knows the information of the information he sent to Jia, he does not mind signing it above. He first sends the information that is not encrypted, "A, I am B", and then send the encrypted summary of the information. A can be very convenient to verify that B is B is, and B has not signed on the information he doesn't want to sign.
Handing out public keys distributes public key
How does Bob Hand Out His Public Key In a trustworthy way? Let's say the authentication protocol looks like this:
A-> b Hellob-> a hi, i'm bob, bobs-public-keya-> b prot itb-> a alice, this is bob {digest [alice, this is bob]} BOBS-PRIVATE-KEY
So, how is B to submit his public key in a trusted manner? See the verification protocol as shown below:
->: Hello-> A: Hey, I am B, B. Public Keicle -> B: Please prove B-> A: A, I am {Abstract [A, I am B]}
With this protocol, anybody can be Bob. All you need is a public and private key. You lie to Alice and say you are Bob, and then you provide your public key instead of Bob's. Then you prove it by encrypting something with the private Key You Have, And Alice Can't Tell You're Not Bob. Use this protocol, anyone can become "B". As long as you have a pair of public keys and private keys. You are deceived, saying that you are B, just provide your public key, not the public key of B. Then, you send the information encrypted with your private key to prove your identity. A could not find that you are not B. To Solve this Problem, The Standards Community Has Invented An Object Called A Certificate. A Certificate Has The Following Content:
THE CERTIFICATE ISSUER's Name the entity for whom the certificate is being issued (aka the subject) The public key of the subjects Some Time Stamps
The certificate is signed using the certificate issuer's private key. Everybody knows the certificate issuer's public key (that is, the certificate issuer has a certificate, and so on ...). Certificates are a standard way of binding a public key to a name .
In order to solve this problem, standardization organizes the certificate invented the certificate. A certificate has the following content:
The name of the certificate issuer is sent to the certificate (also known as the subject) theme of the public key to some timestamp
Certificate uses the issuer's private key encryption. Everyone knows the public key of the certificate issuer (that is, the issuer of each certificate also has a certificate to push). Certificate is a standard way to bind a public key with a name.
By using this certificate technology, everybody can examine Bob's certificate to see whether it's been forged Assuming that Bob keeps tight control of his private key and that it really is Bob who gets the certificate, then all is well Here is the amended protocol..:
A-> B Hellob-> a hi, i'm bob, bobs-certificatea-> b prot thereb-> a alice, this is bob {digest [alice, this is bob]} Bobs-Private-Key
Now when Alice receives Bob's first message, she can examine the certificate, check the signature (as above, using a digest and public key decryption), and then check the subject (that is, Bob's name) and see that it is indeed Bob. She can then trust that the public key is Bob's public key and request Bob to prove his identity. Bob goes through the same process as before, making a message digest of his design and then responding to Alice with a signed version of it. Alice can Verify Bob's Message Digest by Using The Public Key Taken From The Certificate and Checking The Result. By using certificate technology, everyone can check B's certificate and determine whether it is forged. Suppose B is controlled his private key, and he is indeed a certificate of the certificate, it is good. The following is a revised agreement:
->: Hello B-> A: Hey, I am B, B. Certificate A-> B: Please prove B-> A: A, I am {Abstract [A, I am B } Of the private key of B
Now when I receive the first information of B, he can check the certificate, verify the signature on the certificate (as mentioned above, using summary and public key decryption), check the subject in the certificate (here is the name of B), determined B. He can believe that the public key is the public key of B, then ask B to prove its identity. B is made by the process described above, making an information summary, replied by a signature version. A can be used by using the information summary of the public key test from the certificate, and the results are compared.
A Bad Guy - Let's Call Him Mallet - Can Do The Following:
A-> M Hellom-> a hi, i'm bob, bobs-certificatea-> m prot itm-> a ????
But Mallet Can't Satisfy Alice In The final message. Mallet Doesn't Have Bob's Private Key, So He Can't Construct A Message That Alice Will Believe Came from Bob.
Suppose there is a bad kid, we call him h, he can do this:
-> h: Hello H -> A: Hello, I am B, B Certificate A-> H: Please prove H -> A:? ? ?
H can't satisfy the last information of A. He doesn't have a private key of B, so he can't build a letter from B.
Exchanging a secret switched key (Secret)
Once Alice Has Authenticated Bob, She Can Do Another Thing - She Can Send Bob A Message That Only Bob Can Decode: A-> B {Secret} Bobs-Public-Key
The only way to find the secret is by decrypting the above message with Bob's private key. Exchanging a secret is another powerful way of using public key cryptography. Even if the communication between Alice and Bob is being observed, nobody but Bob can get the secret .
Once the armor has verified B, he can do additional things - send it to the other B can decrypt, read (another) key:
->: {secret}
Only the above information can be decrypted to obtain the Secret (another key). The exchange (additional) key is another powerful means provided by the public key cryptography. Even the communication between A and B is listened, only B can get the key.
This technique strengthens Internet security by using the secret as another key, but this time it's a key to a symmetric cryptographic algorithm (such as DES, RC4, or IDEA). Alice knows the secret because she generated it before sending it to Bob. Bob . knows the secret because Bob has the private key and can decrypt Alice's message Because they both know the secret, they can both initialize a symmetric cipher algorithm and then start sending messages encrypted with it Here is a revised protocol.:
A-> B Hellob-> a hi, i'm bob, bobs-certificatea-> b proB {Digest [alice, this is bob]} bobs-private-keya-> b OK Bob, Here Is A Secret {Secret} Bobs-Public-Keyb-> A Some Message} SECRET-KEY How Secret-Key Is Computed is Up To The Protocol Being Defined, But It Could SIMPLY Be a Copy Of Secret.
Using SecRET as another key enhances the security of the network, but now this key will be used for symmetric encryption algorithms (eg, DES, RC4, IDEA). (Translator Note: The public key algorithm is relatively large when the amount of information is encrypted, so it is generally used in the encryption of the large amount of information, and the routine communication use public key system is overwhelmed. So this article is verified after authentication. The reliability of the public key system exchanges a symmetric encrypted key, and the subsequent communication is protected by the symmetric encryption algorithm.) Because it is a key generated before being sent to B, the key is known. B also knows the key, because B has a private key, can decrypt information. Because they all know the key, they can initialize a symmetric encryption algorithm that encrypts information from the beginning (symmetric encryption algorithm). The following is amended: A-> B: Hello B-> A: Hey, I am B, B. Certificate A-> B: Please prove B-> A: A, I am B {Summary [A, I am B]} 私 私 私 甲 -> B: Hello, here is the key {secret}} public key B-> A: {Some Message} SECRET-Key
(Symmetric Key) SECRET-KEY is calculated, completely (both defined) communication protocols have decided, of course, can simply use Secret-Key.
You Said What? What are you talking about?
Mallet's bag contains a few more tricks. Although Mallet can not discover the secret that Alice and Bob have exchanged, he can interfere in their conversation by damaging it. For example, if Mallet is sitting between Alice and Bob, he can choose to pass Most Information Back and Forth Unchanged But Mangle Certain Messages (Easy For Him To Do Because He Know ": h has other tricks. Although I don't know if I find the key that has been exchanged, H can interfere with their conversation. If the hacker h is in the middle of A and B (the communication link), he can let most of the information, choose to destroy certain information (this is very simple, because he knows the agreement adopted by A and B.):
A-> M Hellom-> b Hello
B-> M Hi, I'm Bob, Bobs-CertificateM-> a Hi, I'm Bob, Bobs-Certificate
A-> MPE M-> B Prove IT
B-> M Alice, this is bob {digest [alice, this is bob]} bobs-private-keym-> a alice, this is bob {digest [alice, this is bob]} BOBS-PRIVATE-KEY
A-> M OK Bob, Here Is A Secret {Secret} Bobs-Public-Keym-> B OK Bob, Here Is A Secret {Secret} BOBS-PUBLIC-KEY
B-> m {some message} secret-keym-> a garble [{some message} secret-key]
Mallet passes the data through without modification until Alice and Bob share a secret. Then Mallet gets in the way by garbling Bob's message to Alice. By this point Alice trusts Bob, so she may believe the garbled message and try to act on it. Note That Mallet Doesn't Know The Secret - All He Can Do Is Damage The Data Encrypted with The Secret Key. Depending on The Protocol, Mallet May Not ProductA Valid Message. Ten Again, He May Get Lucky.
A-> H: Hello H -> B: Hello
B-> H: Hey, I am B, B. Certificate H -> A: Hey, I am B, B certificate
-> h: Please prove H -> B: Please prove
B-> H: A, I am {Abstract [A, I am]}} private key h -> A: A, I am {Abstract [A, I am B]}} private key
-> h: Hello, B, here is the key {secret} B -> B: Hello, B, here is the key {secret} B
B-> H: {Some Message} SECRET-KEYH -> A: Garble [{s OME Message} SECRET-Key]
H ignores some of the data is not modified until the A and B swap key. Then hs interferes with the information of B. At this moment, A. The A, so he may believe that the information that has been interfered and try to decrypt. It should be noted that h does not know the key, what he can do is to destroy the data after using the key encryption. Based on the protocol, h may not produce an effective information. But the next time?
To prevent this kind of damage, Alice and Bob can introduce a message authentication code (MAC) into their protocol. A MAC is a piece of data that is computed by using a secret and some transmitted data. The digest algorithm described above has just the Right Properties for building a mac function That Can Defend against mallet:
Mac: = Digest [Some message, Secret]
Because Mallet does not know the secret, he can not compute the right value for the digest. Even if Mallet randomly garbles messages, his chance of success is small if the digest data is large. For example, by using MD5 (a good cryptographic digest algorithm invented by RSA), Alice and Bob can send 128-bit MAC values with their messages The odds of Mallet's guessing the right MAC are approximately 1 in 18,446,744,073,709,551,616 -. for all practical purposes, never to prevent such damage, A. And B can introduce an information verification code in their protocol (Message Authentication Code, hereinafter referred to as MAC). The Mac is a piece of data calculated based on the key and the transmitted information. The characteristics of the summary algorithm described earlier are actually used when generating Mac, which is used to resist h attack:
Mac = Digest [some message, secret]
Because h does not know the key, he cannot calculate the correct summary value. Even if H random interference information, as long as the amount of data is large, his success is minimal. For example, using MD5 (a good encryption algorithm for an RSA invention), A and B can add 128-bit MAC values. H speculates that the correct MAC is nearly 1/18, 446, 744, 073, 709, 551, 616, about zero.
Here Is The Sample Protocol, Revised Yet Again:
A-> B Hellob-> a hi, i'm bob, bobs-certificatea-> b proB {Digest [alice, this is bob]} bobs-private-keya-> b OK Bob, Here is a secret {secret} bobs-public-keyb-> a {some message, mac} second-key
Mallet is in trouble now. He can garble messages all he wants, but the MAC computations will reveal him for the fraud he is. Alice or Bob can discover the bogus MAC value and stop talking. Mallet can no longer put words in Bob's mouth.
The following revised protocol:
->: Hello B-> A: Hey, I am B, B. Certificate A-> B: Please prove B-> A: A, I am {Abstract [A, I am B ]} 私 私 私 甲 -> B: Hello, B, this is the key {secret} B. Public key B -> A: {Some Message, Mac} SECRET-KEY
Now h is already unspeakable. He can interfere with any information, but Mac calculations can discover his trick. A and B can discover forged MAC values and stop talking. H no longer fake borrow Y. WAS THAT SAID?
Last but not least to protect against is Mallet the Parrot. If Mallet is recording conversations, he may not understand them but he can replay them. In fact, Mallet can do some really nasty things sitting between Alice and Bob. The solution is to introduce Random Elements from Both Sides of the Conversation. It is not enough to prevent H's tongue attack. If h records (A and B) communications, although he can't understand (communication) meaning, he can reproduce (communication). In fact, hidden in the middle of A and B can do some great attacks. The solution is to introduce random factors in both parties.
