2

I have recently read about the german enigma machine in WW2, It worked in a way that every day the machine configuration was sent per mail to the different operators. (I couldn't find official sources on this, please do suggest an edit if i said something wrong)

Obviously these ciphers could be confiscated by the allies, but that apparently wasnt very effective compared to brute forcing it. (Turing)

Now about online encryption like https, how is it possible to encrypt anythingonline, if the decryption key would also need to be transferred somehow.

It just never made sense to me, even if there is a public+private key scenario. If someone can tap into the connection, he can see both being sent right?

I would love to get enlightened on this, this is where my amateur theories on cryptography break down.. Thanks!

downrep_nation
  • 147
  • 4
  • The encryption you're thinking of is *symmetric* (the same key that encrypts will also decrypt). Briefly (and **not too accurately**): SSL uses asymmetric crypto: whatever is encrypted with one half of the key *can only be decrypted by the other*. I make one half public: everyone is able to send me data that anyone else can read, but I alone can decrypt. When communicating, we both generate a key and exchange its first "half". This process is slow but we only need it once. We use it to encrypt two symmetric, faster keys, which then don't travel in the clear. These keys protect the traffic. – LSerni Mar 27 '16 at 21:02
  • It's because of the chain of trust. Why do we trust an SSL connection? Because the connection is encrypted using an x.509 certificate. Why do we trust the x.509 certificate? Because the certificate is signed by a certificate authority (CA). Why do we trust CA? Because the browser vendors have included the CA's root certificate in their browser. Why do we trust the browser vendor? Because you downloaded and installed their software into our machine. – Lie Ryan Mar 28 '16 at 08:50
  • @downrep_nation if you learned how https works you would have an idea about how asymmetric encryption works. Specifically, RSA for some of the encryption, Diffiehelman for the key exchange, and certificates (and CAs) for the authentication. – d0nut Mar 28 '16 at 15:17
  • @downrep_nation although you were only using SSL as an example, it is actually the best example of the answer to your question and how "online encryption" protects itself from eavesdropping. – schroeder Mar 28 '16 at 22:10
  • 3
    This would have been a nice question to answer and even the author of the question plainly says it has nothing to do with specific algorithms. Asymmetric encryption can be hard to grasp, the most fundamental part of it is an algorithm which is harder to solve in one direction than the other. The best analogy I've heard is a padlock. locking it is one operation, unlocking it is easiest done with a private key. The locks can be distributed in the open, but the key needs to be kept secret. See the postal analogy: https://en.wikipedia.org/wiki/Public-key_cryptography#A_postal_analogy – mgjk Mar 29 '16 at 01:56

4 Answers4

7

Take a look at this explanation of the Diffie-Hellman key exchange. The central point is that due to some clever mathematics, both parties are able to compute the secret key, while being certain that no one else could have done the same.

If you spend a couple of minutes looking into the mathematics, it should become clearer why this is possible.

Bruno Rohée
  • 5,221
  • 28
  • 39
Hans Kristian
  • 391
  • 3
  • 9
2

There are a lot of complex concepts here, but they can be broken down into a few simple statements. I'll explain the RSA key exchange here as it's pretty straightforward. First, we have to start with a couple of basic facts:

Given: Symmetric encryption uses the same key for encryption as decryption.

  • The symmetric key must be kept secret by everyone who knows it.
  • Symmetric encryption is fast and efficient.

Given: Asymmetric encryption uses a 'public key' to encrypt and a 'private key' to decrypt.

  • As the names imply, a public key can be shared with everyone publicly, it's not a secret.
  • A public key can be delivered in a "certificate", which is a digitally signed document stating that it is authentic, and that it belongs to this server.
  • A private key must be kept secret by the one party who knows it.
  • Together, we call these a key pair.
  1. A client connects to a server and receives a certificate containing the server's public key.
    • (The client validates the signature on the certificate before continuing.)
  2. The client generates a secret random value to use as a symmetric algorithm's key.
    • This is a temporary key we call the "session key".
  3. The client encrypts the session key using the server's public key.
  4. The client sends the encrypted session key to the server.
  5. The server decrypts the encrypted session key using its private key, and recovers the client's original session key.
    • The server now has a copy of the same session key the client generated.
  6. The client encrypts its data with the symmetric algorithm and the session key and sends it.
  7. The server receives the encrypted data, and decrypts it using the session key.
  8. The server generates the response, and encrypts it using the session key.
  9. The client receives the response, and decrypts it using the session key.

The secret session key is always encrypted by the client before it is transmitted. An eavesdropper listening on the network cannot tell what the original random value was. They can learn the encrypted random value, but because they do not have the private key, they cannot decrypt it.

There are other ways to exchange session keys. Other posters have mentioned Diffie-Hellman (DH) as one of the major protocols, but there are even others.

John Deters
  • 33,650
  • 3
  • 57
  • 110
2

Several other people have contributed answers on the technical issues you are having trouble understanding. But I notice at least two poor assumptions in your question(s).

1) The German Enigma machine was a quite an innovative device, and we were lucky to defeat it. It wasn't just brute force, at least one device was captured and reverse engineered, so that we knew how to apply a brute force algorithm. Once we understood the rotor system, the next problem was the starting configuration of machine for a given transmission. That had to be guessed. Because ....

2) A symmetric key does have to be "transferred somehow" but not necessarily online. The Germans used separate channels for distributing the settings for the starting state of the machines.

On the internet, we do this with Diffie-Hellman exchanges (or with a PKI). Where a random symmetric key is created independently on each side, for that conversation session then discarded. The cleverness comes for the fact that observing the conversation does not revel the ultimate key.

DaveM
  • 165
  • 5
0

With public key cryptography everyone knows the public key but it is useless if you want to decrypt data. You can only encrpyt data to be sent to the user that has the private key associated with that specific public key.

So the public key has an associated private key that is used to decrypt.

Read about RSA.

yoyo_fun
  • 183
  • 7
  • So both sides only know how to encrypt data but not how to encrypt it.. – downrep_nation Mar 27 '16 at 05:07
  • @downrep_nation In the case of https, the server has the private key, but only sends the client its public key. They then do a complicated process that uses that key pair (and often a related trick called [Diffie-Hellman key exchange](https://en.wikipedia.org/wiki/Diffie–Hellman_key_exchange)) to protect the exchange of session keys that're used to encrypt the actual data being transmitted. This is a far bigger topic than can be covered in a stackexchange answer. – Gordon Davisson Mar 27 '16 at 07:00
  • Watch this youtube video. It explains the public key method quite well. https://www.youtube.com/watch?v=ERp8420ucGs – yoyo_fun Mar 27 '16 at 16:40