Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

This question already has an answer here:

Is HTTPS it based on private key on user side?

Where does the user get the private key in the first place?

Suppose the user gets the private key by downloading a browser (Chrome, Firefox), then isn't hackers able to intercept the key by man-in-middle attack?

Suppose private key comes from Windows OS registration number, then does this mean hackers can intercept private keys of all Linux browser downloads by man-in-middle attack because Linux does not have registration number?

Suppose the private key is based on timer function, then isn't it easy to brute force the private key?

If HTTPS is not based on the user's private key, then isn't HTTPS very unsafe?

share|improve this question
add comment

marked as duplicate by Xander, gowenfawr, TildalWave, NULLZ, Adnan Nov 21 '13 at 21:49

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

2 Answers

Generally, a symmetric key is negotiated on the fly, and securely exchanged between the browser and the server. One protocol that enables people to do this (Diffie-Hellman key exchange) is explained in this excellent youtube video: http://www.youtube.com/watch?v=3QnD2c4Xovk.

The random data for that is derived using any number of methods; it's certainly not static, and it generally won't have much to do with the current time. The classic example is to use the number of microseconds from the time, which is something that knowing the time of day to the second won't help. Other sources include the timing of certain events (keypresses and disk accesses, as common in linux), the number of photons reflected by a semitransparent mirror at some moment (quantum-derived entropy like many SSL accelerators use), or the action of a metastable oscillator (the intel DRBG), and several other things. This random data is collected each time it is required, though in practice it can sometimes be stored in a pool for later use (which can be a vulnerability also, but that's another topic).

Since the key is quite random, you need to do a lot of bruteforce to get it. If you maximized the amount of entropy you could use for your key, and the cipher used a 256-bit key (AES-256, etc.), you would have to try a lot of times (2^256 * 0.50 attempts would give you a 50% chance of recovering the key). In practice, a lot of people use less entropy than this and construct the rest of the key deterministically, which means that if they used only 64 bits of entropy that formula would change to 2^64 * 0.50, as long as you knew exactly how the key was being generated. For DH key exchange like I mentioned above, the math is actually a little more complex because you have to account for the fact that you're choosing two random numbers and not one.

This is a lot of keys, and the odds of most attackers breaking one by bruteforce before you've stopped using it are very minimal.

share|improve this answer
add comment

Is HTTPS it based on private key on user side?

Partially, yes.

Where does the user get the private key in the first place?

The browser automatically generates a random private key.

Suppose the user gets the private key by downloading a browser (Chrome, Firefox), then isn't hackers able to intercept the key by man-in-middle attack?

The key isn't part of the browser, it is generated on the fly.

Suppose private key comes from Windows OS registration number, then does this mean hackers can intercept private keys of all Linux browser downloads by man-in-middle attack because Linux does not have registration number?

Same answer as above

Suppose the private key is based on timer function, then isn't it easy to brute force the private key?

Why would it be? There's some randomness involved.

share|improve this answer
    
> Why would it be? There's some randomness involved. The hacker know the time, it's within 15 minutes of the encrypted message. (since banks and e-commerce sites normally use 15 minutes as session expiration time). So they just brute force 15 minutes instead of brute forcing 2^512) combinations. Brute forcing 15 minutes is order of magnitude smaller than brute forcing all 2^512 combinations. –  guestguest Nov 21 '13 at 19:28
    
A proper PRNG isn't just seeded from the time. It uses many sources of entropy. For example the precise timing (nanoseconds or so) of disk operations, which are influenced by the surroundings, temperature and chaotic air turbulences inside the disk. Timing of arriving network packets, user input, etc. It also stores some random numbers to use after the next reboot. Together these should exceed 128 bits to ensure security. On Desktop systems, this works pretty well, on embedded systems or some virtual machines it can go wrong. –  CodesInChaos Nov 21 '13 at 20:16
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.