Tell me more ×
IT Security Stack Exchange is a question and answer site for IT security professionals. It's 100% free, no registration required.
up vote 7 down vote favorite
1

Is there a way for 2 parties to negotiate a shared secret (for example, a session key) without having a pre-shared knowledge?

SSL does this by using asymmetric encryption. Is there any other way to achieve this without use of PKI?

share|improve this question
2  
The way it works with SSL/TLS is that the browser receives a certificate from the server who claims to be X. Then the certificate is validated using the digital signature. It uses the knowledge it has with its certificate repository. Realistically, you can't really do what you ask for if there is a chance for active network attacks. You need some kind of trust system to do that (like what PKI offers). Otherwise Authentication is prone to fail. – user2283 Apr 30 '11 at 18:19
It sounds like you are asking about Zero Knowledge Protocols. Here's the wiki article en.wikipedia.org/wiki/Zero-knowledge_proof and this fascinating topic is explained well and in-depth in the canonical tome Applied Cryptography (2E) by Bruce Schneier. – adric Sep 7 '12 at 21:10

2 Answers

up vote 8 down vote accepted

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.

share|improve this answer
If this is within a strictly controlled network, would the active attack remain possible? – yfeldblum Apr 30 '11 at 16:47
I think it is really a case of whether or not you think an active attack is an acceptable risk. In an organisation's network, or some part of it, the infrastructure might be judged sufficiently difficult to actively attack. Regardless it is generally a good idea to require that an active attack is used. An active attack is typically much more difficult to do, and to conceal, than a passive one. I'm a big fan of opportunistic encryption (e.g. SSH style) for this reason. – frankodwyer Apr 30 '11 at 21:18
Thanks for the answers, I understand the possibility that this is not secure against some attacks, but I think that this approach is sufficient for my needs. Thanks – paan May 1 '11 at 6:53
up vote 5 down vote

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; otherwise, you will not distinguish them reliably. Everybody has the same computers, so "being able to do something" equates to "knowing some confidential information".

With SSL, certificates are used, which means that there is asymmetric cryptography. Bob is distinct from Charlie (from your point of view) because Bob knows the private key corresponding to the public key which is in the certificate (and Charlie does not know that secret key).

To sum up: if you and Bob know a shared secret, then you can use that to authenticate to each other. Otherwise, if Bob knows a non-shared secret, then this secret is a private key in a public/private key pair; so the problem becomes: how do you know that the public key you are about to use is indeed Bob's ? PKI is a way to do that, with the help of an "authority" which performs the link between Bob's identity (which is not part of the computer world) and Bob's public key (which is in the computer world).

"PKI" is a wide term, and covers a degenerate situation, in which you are your own PKI. Namely, you meet Bob once, and he gives you his public key (or a hash thereof); afterwards, you use that knowledge to make sure that you are using the "right" Bob's key. This is how SSH works.

share|improve this answer
Well, with SSH one should check the key fingerprint via a side channel on that first connect. – ewanm89 Dec 6 '12 at 0:02

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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