Hot answers tagged key-exchange
136
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 ...
57
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 ...
23
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 ...
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:
...
14
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 ...
14
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 ...
12
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.
11
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 ...
11
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 ...
10
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
...
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 ...
8
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 ...
8
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 ...
8
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 ...
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
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
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
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
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
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 ...
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 ...
6
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 ...
5
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 ...
5
At the end of SRP, client and server are implicitly authenticated to each other. "Implicit" means: "I do not know if I talked with someone who really knows the shared secret, but I know that he knows the symmetric key I just got from the protocol only if he knows the shared secret". If you want to make sure of that, challenge the peer: have it use the ...
5
RFC 5054 has a bit more precise recommendations. To be coherent, one must try to achieve a given "security goal" expressed in bits as a parameter t: namely, that the system is secure against attacks which have a computing power up to 2t elementary operations. The traditional value for t was 80 bits, but advances in technology make available computing power ...
5
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 ...
5
There are a number of key agreement protocols which are used to establish a shared secret, e.g. Diffie-Hellman. The real trouble is: a shared secret, yes, but with who ?
In the computer world, identity is knowledge. You want to share a secret with Bob but not with anybody posing as Bob: therefore, Bob must be able to "do something" that Charlie cannot; ...
5
Short answer. Yes, I think it is fine to choose x as a random 160-bit number. (I would not bet my life on it, but I'm pretty sure it is fine.)
Technical details. There are (at least) two ways to attack Diffie-Hellman.
One way is to use fancy algorithms for computing the discrete logarithm, e.g., based upon the number field sieve or the like. The ...
5
The trick is that Alice and Bob can share non-secret information freely; they can agree that yellow will be their base color and it doesn't help Eve at all if she finds this out.
When Eve intercepts the green paint Alice has sent to Bob, she knows it was made with yellow and some other color, but figuring out the other color is too hard to do even with ...
Only top voted, non community-wiki answers of a minimum length are eligible
