how encryption works_问答_开发者_运维开发者技术经验分享

I know a basic rules on https!

I know there is private & public key, and public key is for encryption and private key is for decryption!

Now I have questions:

* - IF I know the public key why I cannot decrypt data, Surely i开发者_运维技巧t's related to private key!!!

*- And does https protocol encrypt all data or only data that sent by client?? for emxample, If i go to gmail.com, html codes are encrypted or not?

now if answer is yes(and HTML codes are encrypted) how my browser can decrypt it and others can't??

If no, why we should use it for example for downloading backup of important data?

Okay, a couple of points of confusion here.

First, HTTPS isn't actually encrypted with a public/private key scheme -- technically, "asymmetric encryption." It's instead encrypted using a symmetric encryption -- one of several, actually -- with a session key that's established through an algorithm like Diffie-Hellman key exchange.

The result is that the encryption is carried out through a one-use key that's computed as part of the handshake setting up the SSL connection.

The Wikipedia article on Transport Layer Security (SSL was really a proprietary term from Netscape) is reasonably decent.

If you could get that key, you could indeed decrypt the data, but since the usual key now is 128 bits long, you have roughly 1 chance in 2¹²⁸ of getting it right -- or, in another way of looking at it, you can expect to take about 2¹²⁷ (170141183460469231731687303715884105728) tries before you'd find the key.

But second, asymmetric encryption does come in one way, however. When you're establishing an SSL connection, the host provides an X509 certificate to identify itself; that's so someone can't hijack DNS and make themselves appear to be paypal.com instead of Vlad's Cut Rate Hacking. The X509 certificate is signed using a public/private key pair: the signature is hashed using the private side of a trusted providers key -- say VeriSign. They provide the public side, which allows you to confirm that the certificate was indeed encrypted by VeriSign. That confirms the authenticity of the cert.

Public Key encryption systems are based on One Way Functions; functions that are far easier to compute in one direction than in the other. There are two common choices of one-way functions for public-key cryptography systems: Large integer factorization and Discrete Logarithms.

There are no mathematical proofs that large integer factorization doesn't have easy solutions: however, several decades of intense research hasn't found any polynomial-time algorithms. (Not that one would necessarily be fast, just that finding one has been a good long-term goal.) The RSA cryptosystem safety is based on the difficulty of factoring large primes.

There are mathematical proofs that solving discrete logarithms is very difficult. The El Gamal and Diffie-Hellman algorithms rely on discrete logarithms for their safety.

The public key mechanisms are only part of actual deployed solutions though. Public Key systems are usually used for digital signatures and for negotiating a session key that is used with a symmetric cipher. Symmetric ciphers are far faster, much safer to use on plain text with patterns, and are an integral portion of modern communications privacy and integrity.

Now, to directly address your questions :)

IF I know the public key why I cannot decrypt data, Surely it's related to private key!!!

They are related. And you could find one given the other. But the computational complexity of finding one is currently so much worse than generating new public / private key pairs, the key itself should have no value by the time you have cracked it. (Years for 'smaller' keys, probably millennium for 'larger' keys. Trouble is, the definition moves around. :)

And does https protocol encrypt all data or only data that sent by client?? for emxample, If i go to gmail.com, html codes are encrypted or not?

HTTPS itself encrypts everything in both directions. HOWEVER, some web sites will use unencrypted http for images, css, javascript, and https for the HTML that actually contains the user data. This is because serving unencrypted content is much faster than serving encrypted content. It is also very unsafe, because most of those types of contents can be replaced while in-flight, allowing intruders to modify the browser's DOM or inject other new code, that lets them get access to the private data. Most browsers complain about mixed SSL/TLS and unencrypted content, so hopefully not many sites do this.

how my browser can decrypt it and others can't?

During the SSL/TLS handshake at the start of the session, the server and browser negotiate a new session key that will be used for the session. All the traffic between browser and client are encrypted with the session key, and as a result of the way the SSL/TLS session is created, only the client and server know the key:

https://www.rfc-editor.org/rfc/rfc5246#page-64

8.1.1. RSA


   When RSA is used for server authentication and key exchange, a 48-
   byte pre_master_secret is generated by the client, encrypted under
   the server's public key, and sent to the server.  The server uses its
   private key to decrypt the pre_master_secret.  Both parties then
   convert the pre_master_secret into the master_secret, as specified
   above.

8.1.2. Diffie-Hellman


   A conventional Diffie-Hellman computation is performed.  The
   negotiated key (Z) is used as the pre_master_secret, and is converted
   into the master_secret, as specified above.  Leading bytes of Z that
   contain all zero bits are stripped before it is used as the
   pre_master_secret.

   Note: Diffie-Hellman parameters are specified by the server and may
   be either ephemeral or contained within the server's certificate.

IF I know the public key why I cannot decrypt data, Surely it's related to private key!!!

Yes the are related, but to determine the private key from the public one would require solving a computational hard problem that is factorize a prime large number.

For telling it in simple words, you can do it, but the time it would require with the actual technologies is too long.