Tag Info

Hot answers tagged

204

It is the magic of public-key cryptography. Mathematics are involved. The asymmetric key exchange scheme which is easiest to understand is asymmetric encryption with RSA. Here is an oversimplified description: Let n be a big integer (say 300 digits); n is chosen such that it is a product of two prime numbers of similar sizes (let's call them p and q). We ...


74

Here's a really simplified version: When a client and a server negotiate HTTPS, the server sends its public key to the client. The client encrypts the session encryption key that it wants to use using the server's public key, and sends that encrypted data to the server. The server decrypts that session encryption key using its private key, and starts using ...


41

The other answers are good, but here's a physical analogy that may be easier to grasp: Imagine a lock-box, the kind with a metal flap that you put a padlock on to secure. Imagine that the loop where you put the padlock is large enough to fit two padlocks. To securely exchange send something to another party without sharing padlock keys, you would put ...


41

The situation can be confused, so let's set things right. RSA is two algorithms, one for asymmetric encryption, and one for digital signatures. These are two distinct beast; although they share the same core mathematical operation and format for keys, they do different things in different ways. Diffie-Hellman is a key exchange algorithm, which is yet ...


38

You may use a key exchange (as part of a cipher suite) only if the server key type and certificate match. To see this in details, let's have a look at cipher suites defined in the TLS 1.2 specification. Each cipher suite defines the key exchange algorithm, as well as the subsequently used symmetric encryption and integrity check algorithms; we concentrate ...


32

Diffie-Helman is a way of generating a shared secret between two people in such a way that the secret can't be seen by observing the communication. That's an important distinction: You're not sharing information during the key exchange, you're creating a key together. This is particularly useful because you can use this technique to create an encryption ...


21

The problem with a one time pad, is that is must be equal in length (or longer) than the data being encrypted , and must never, ever, be reused. Just as you indicate, how would they send the key?, the OTP must then be sent in a secure way... however that is the problem that is usually left to the user and is generally why OTP is useless. If you have the ...


17

What you are referring to is asymmetric encryption. A key is used for encryption, and a seperate key is used for decryption. You would use the encryption key, aka public key, to encrypt the incoming log files, while the decryption key, aka private key, is stored on a different server/system/etc so there is no way to decrypt the logs. Some good primers: ...


16

In simple words: There are two different encryptions taking place: First there is the public/private key encryption. The client uses the public key of the server (which is included in the certificate) to encrypt some information that only the server can decrypt using it's private key. Based on this information a session key is derived, that is only known ...


13

Cipher suites which provide perfect forward secrecy are those which use a Diffie-Hellman key exchanged, signed by the server -- but the server key may be of type RSA. Consider the TLS standard: there are two cipher suites which use AES with a 256-bit key, SHA-1 for integrity check, and a RSA server key: TLS_RSA_WITH_AES_256_CBC_SHA ...


13

Comparing key strength between symmetric encryption and asymmetric key exchange is like comparing apples with oranges: it is doable (they are both tasty fruits) but tricky and full of subtle details. To break DH, the best known method is trying to solve the discrete logarithm problem, for which the best known algorithm is a variant of Index Calculus which ...


13

I think of the six answers already up, gowenfawr's explains it best. Read that first as this is simply an addendum. On Diffie-Hellman Several answers mention Diffie-Helman exchanges. These are implemented in a minority of exchanges. A DH exchange is signed by the server's key to prevent a MITM attack. Because the key is not encrypted to a public key, it ...


13

DH ephemeral key exchange provides perfect forward secrecy, which RSA alone does not. This means that even if the long-term key is leaked at a later date, the session keys for individual connections are not compromised, even if the full data stream is captured.


12

How would they pass they key? This gets to the root of where OTPs came from, and indeed how they got that name. This is for correspondence during wartime with ships or other similar agents[*]. When the ship leaves port, they head out with a pad of random data. When they receive an encrypted communication over the radio, they decode it using the ...


11

Diffie Hellman is an algorithm used to establish a shared secret between two parties. It is primarily used as a method of exchanging cryptography keys for use in symmetric encryption algorithms like AES. The algorithm in itself is very simple. Let's assume that Alice wants to establish a shared secret with Bob. Alice and Bob agrees on a prime number, p, ...


11

Not really "Internet", but the one-time pad is documented to have been used for the Red Phone (a westernly-biased name; I don't know how they called it in Moscow). The pads were exchanged on magnetic tapes, sent by planes on a weekly basis. It is possible that the current system still uses a similar encryption method. This makes sense: though the one-time ...


10

What you implemented is not Diffie-Hellman, and has no strength at all. You are being confused with the use of the '^' character. In C-like programming languages, '^' is the operator for a bitwise exclusive-or (a "XOR"). When writing mathematics in ASCII, it is customary to denotes exponentiation with the '^' character -- and it is not a XOR at all ! This ...


9

AES-256 and a 8192-bit DH modulus are both overkill. Comparing them with each other is a delicate exercise which verges on the meaningless, since both are quite far into the realm of "can't break it now, can't do it in 30 years either". You can have a look at this site for information and calculators on various ways to estimate relative strength of symmetric ...


9

Actually it is not that hard. It may be slightly expensive, computationally speaking. A good DH modulus and generator is what you get when generating DSA key parameters; see the DSA specification. You get to choose the subgroup order (q, a prime number), the modulus (p, such that p-1 is a multiple of q), and a generator for the subgroup of size q. OpenSSL ...


9

A lot of the answers already provided are overlooking the interception capability of the ISP or NSA. Take a look at Room 641A in the AT&T datacenter. There are an estimated 10 to 20 such facilities that have been installed throughout the United States. Also take a look at the One Wilshire building where 260 ISP's connections converge into one building. ...


9

The answer to your situation, presented as it is, is that it is impossible unless you make certain assumptions. You have two problems you need to resolve for this to work. For this example, I will use Alice and Bob as examples. You need to have Alice and Bob exchange keys in a secure fashion. This is the easy problem. Any key exchange method like ...


8

There is Diffie-Hellman (which SSL can also use), but this is only secure if an attacker cannot perform active attacks, or the parties can be mutually authenticated.


8

Right now, it seems that none of the existing major browsers supports TLS-PSK, and neither to they support TLS-SRP. In your case, both are applicable, but SRP is "stronger" in that it tolerates much better a low-entropy shared secret (say, a password). There has been some initial effort at making Chrome SRP-aware; I don't know how far it went. Since ...


8

With big numbers, Diffie-Hellman looks like this: we work modulo a big prime p, and we start with a conventional big integer g (in the 2..p-2 range). Each integer modulo p represents an achieved colour; g itself is the starting point, i.e. "yellow" in your picture. Each paint is an integer; the range of possible paint tones is large (at least 2160). Mixing ...


7

Basically the problem is a matter of trust. When you sign a file, someone needs to retrieve your public key to check the signature, but how can they be sure that this is really your signature? GPG provide a way to do that called the Web of trust. For example, let's say you are Bob and want to discuss with Alice. You already know Ted, which is a friend of ...


7

Get yourself a trusted key. Two easiest options are an SSL certificate ($50..$100) and a GPG key (free). Encrypt or sign the data you send with that key. With SSL, you can just serve your data via https, but can also just sign it. With GPG, you have to build enough trust for your key, so that the receiving end is sure it's you and not an impostor. Another ...


7

Client authentication is for the benefit of the server. Preventing a man-in-the-middle is a distinct matter. If the key exchange uses DH with a signature by the server (relatively to a public key which is known to the client) then the client is protected from a man-in-the-middle: the client has a strong notion of who it should be talking to, and the ...


7

The best practice is: The basic idea. Create an API key (a 128-bit symmetric key) for each separate user account. This key needs to be securely stored on the server, and also securely stored on the user's client. For each request made by the client, add an extra request parameter that has a "signature" on the entire request. The "signature" should be ...


7

The usual way this is done is to have Alice sign the set of DH parameters to use. This requires Alice's key and certificate to be appropriate for signatures. In two widely deployed protocols: In SSL/TLS, when Alice (the server) wants to use Diffie-Hellman for key exchange, it selects one of the DHE cipher suites. The DH parameters and the DH public key ...


7

Diffie-Hellman would not help here: an active attacker could use a classical MITM and see whatever data is supposed to be protected by the DH key. He would only see the SRP exchange "from the outside" but would still learn the username. The non-anonymity of the connecting user is a rather fundamental property of Password-Authenticated Key Exchange ...



Only top voted, non community-wiki answers of a minimum length are eligible