Tag Info

Hot answers tagged

176

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 ...


64

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 ...


31

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 ...


31

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 ...


29

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 ...


27

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 ...


20

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 ...


16

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: ...


15

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

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

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 ...


12

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 ...


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

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 ...


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 ...


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

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

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

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 ...


7

Your preliminar answer is a good one, if they can install programs use GPGP: http://www.gnupg.org/ Get them to generate a key pair, email you the public key, encrypt whatever you want to that and return over email. Alternate options are: Encrypt with Winzip AES256 option, choosing a long complex password (goodpassword.com) and exchange that out-of-band ...


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

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 ...


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

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

In SSH 2, key exchange is done using the Diffie-Hellman key exchange. It is best described on the Wikipedia page (the link). Also on the Wikipedia page are a lot of links to documentation (RFCs) containing nitty gritty details. Wikipedia or Google is probably best to find out more about Diffie-Hellman. As a cool experiment you can download Wireshark and try ...


6

Look at Diffie Hellman : http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange For performances reasons, the connection is encrypted with symetric key. But the symetric key is generated during connection etablishement and never exchanged inc lear, but using asymetric cryptography. Asymetric cryptography is a technique were two key are needed : a ...


6

There are a few easy options. Put the key or other data anywhere on the Internet, calculate a fingerprint for it via SHA-256 or some other decent hash, and communicate the fingerprint out-of-band with the other party: via a phone call, SMS, or perhaps email if you aren't too worried about someone else intercepting an email. Get a third party that both of ...


6

SHA-1 is not an ideal hash function (actually, neither are the SHA-2 functions). The double hash invocation hides a few of the internal shortcomings of SHA-1. This is similar to HMAC, which also uses a double hash invocation for pretty much the same reasons. In more details, we want the function which maps the username-and-password to x (function selected by ...


6

It's not possible to authenticate a client in this way. As you correctly point out, it can always be reverse engineered and duplicated. Server authentication only works because the user doesn't have access to the server hardware, and to produce a secure client you must find a way to block the user from accessing the client hardware, which is generally ...



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