Is public key cryptography really safe?

[mtanti]

Contradict me if I'm wrong...

If Black Hat blocks and controls Alice’s internet activities (a man in the middle attack) than these 2 situations can arise:

1. ALICE DOES NOT HAVE BOB'S PUBLIC KEY
Alice sends Bob her public key but it is blocked by Black Hat and instead he sends his public key ‘A’ to Bob. When Bob sends Alice his public key Black Hat blocks it and gives Alice his second public key B. This will then result in Bob sending an encrypted file (using key A) to Alice, blocked by Black Hat, decrypted with his key A, encrypted with Alice’s public key and sent to Alice. The same when Alice sends to Bob but using key B. An effective man in the middle attack were no one can suspect anything.

2. ALICE ALREADY HAS BOB'S PUBLIC KEY (BOB BEING A CERTIFICATE AUTHORITY FOR EXAMPLE)
Alice sends Bob her public key encrypted with Bob's key to prevent the previous situation from arising. Black Hat can still block Alice’s key from arriving to Bob and substitute it with his own key A. Bob will not send his public key because Alice already has it. Now what will happen is that Black Hat can read encrypted files sent by Bob to Alice but he cannot read encrypted files sent by Alice to Bob because Alice does not use Black Hat's key. Instead she uses Bob's authentic key to which Black Hat does not have the equivalent private key. Also Black Hat will have Bob's public key so Bob cannot private key encrypt. So basically unless Bob requests something from Black Hat which only Alice has, Bob will never know about what happened as he doesn’t know Alice’s authentic public key. However Alice will not receive a reply because Alice would be expecting a reply from Bob encrypted using her public key which Black Hat does not have. So all Black Hat can do is isolate Alice from the internet and Black Hat can impersonate her without anyone else except for Alice suspecting anything. So as long as Bob does not request anything from Alice, Black Hat will have no problems impersonating Alice as he would be receiving encrypted files which he can decrypt on Alice’s behalf. Alice could take days to suspect that her public key never reached Bob as she could think of a delay or Black Hat could impersonate Bob and tell Alice that he did not receive her key so as to buy time.

Conclusion:
The only safe way to communicate is by both Alice and Bob having each other’s public key from the start, which means that it is no better than secret key cryptography. Unless of coarse Alice already has something which Bob also has and can challenge Black Hat with it. However this is equivalent to a secret key…

 

[chroot]

Well, duh. This is not a new concept!

Key exchange is obviously the most difficult part of the entire concept of public key cryptography. This is why more advanced systems have key signing mechanisms, so trust hierarchies can be established.

Simply sending your public key through an open (unsecured) channel is stupid.

- Warren

 

[3trQN]

If Alice and Bob had any sense they would have killed Eve by now, we all know she's been listening in on them two for a long time!

 

[mtanti]

But what I'm saying is that there is no way, not even using digital signitures which is situation 2, to stop it from happening. There is just no way to avoid having files destined to you being stolen by someone else unless you are certain that your public key has arrived. So basically what the hell is public key good for if it was invented specifically for safe and easy distribution? They might as well have kept the secret key model...

 

[Anttech]

This isn't new

http://www.rsasecurity.com/rsalabs/node.asp?id=2248

The Diffie-Hellman key exchange is vulnerable to a man-in-the-middle attack.

<snip>Home: Crypto FAQ: Chapter 3 Techniques in Cryptography: 3.6 Other Cryptographic Techniques
3.6.1 What is Diffie-Hellman?
Previous Previous

The Diffie-Hellman key agreement protocol (also called exponential key agreement) was developed by Diffie and Hellman [DH76] in 1976 and published in the ground-breaking paper "New Directions in Cryptography." The protocol allows two users to exchange a secret key over an insecure medium without any prior secrets.

The protocol has two system parameters p and g. They are both public and may be used by all the users in a system. Parameter p is a prime number and parameter g (usually called a generator) is an integer less than p, with the following property: for every number n between 1 and p-1 inclusive, there is a power k of g such that n = gk mod p.

Suppose Alice and Bob want to agree on a shared secret key using the Diffie-Hellman key agreement protocol. They proceed as follows: First, Alice generates a random private value a and Bob generates a random private value b. Both a and b are drawn from the set of integers . Then they derive their public values using parameters p and g and their private values. Alice's public value is ga mod p and Bob's public value is gb mod p. They then exchange their public values. Finally, Alice computes gab = (gb)a mod p, and Bob computes gba = (ga)b mod p. Since gab = gba = k, Alice and Bob now have a shared secret key k.

The protocol depends on the discrete logarithm problem for its security. It assumes that it is computationally infeasible to calculate the shared secret key k = gab mod p given the two public values ga mod p and gb mod p when the prime p is sufficiently large. Maurer [Mau94] has shown that breaking the Diffie-Hellman protocol is equivalent to computing discrete logarithms under certain assumptions.

The Diffie-Hellman key exchange is vulnerable to a man-in-the-middle attack. In this attack, an opponent Carol intercepts Alice's public value and sends her own public value to Bob. When Bob transmits his public value, Carol substitutes it with her own and sends it to Alice. Carol and Alice thus agree on one shared key and Carol and Bob agree on another shared key. After this exchange, Carol simply decrypts any messages sent out by Alice or Bob, and then reads and possibly modifies them before re-encrypting with the appropriate key and transmitting them to the other party. This vulnerability is present because Diffie-Hellman key exchange does not authenticate the participants. Possible solutions include the use of digital signatures and other protocol variants.

The authenticated Diffie-Hellman key agreement protocol, or Station-to-Station (STS) protocol, was developed by Diffie, van Oorschot, and Wiener in 1992 [DVW92] to defeat the man-in-the-middle attack on the Diffie-Hellman key agreement protocol. The immunity is achieved by allowing the two parties to authenticate themselves to each other by the use of digital signatures (see Question 2.2.2) and public-key certificates (see Question 4.1.3.10).

Roughly speaking, the basic idea is as follows. Prior to execution of the protocol, the two parties Alice and Bob each obtain a public/private key pair and a certificate for the public key. During the protocol, Alice computes a signature on certain messages, covering the public value ga mod p. Bob proceeds in a similar way. Even though Carol is still able to intercept messages between Alice and Bob, she cannot forge signatures without Alice's private key and Bob's private key. Hence, the enhanced protocol defeats the man-in-the-middle attack.

In recent years, the original Diffie-Hellman protocol has been understood to be an example of a much more general cryptographic technique, the common element being the derivation of a shared secret value (that is, key) from one party's public key and another party's private key. The parties' key pairs may be generated anew at each run of the protocol, as in the original Diffie-Hellman protocol. The public keys may be certified, so that the parties can be authenticated and there may be a combination of these attributes. The draft ANSI X9.42 (see Question 5.3.1) illustrates some of these combinations, and a recent paper by Blake-Wilson, Johnson, and Menezes provides some relevant security proofs.
Top of Page

 

[mtanti]

Yes I know this but the fact remains that unless Alice and Bob have each other's public key then they just cannot check message integrity as this is only possible after each party has the other's key in order to decrypt the message digest. If that still hasn't happened then Alice's certificate can be substituted with Black Hat's (or Carol or Eve) certificate and it's back to situation 1...

I really want to know if I am right or wrong guys so please contribute to this thread... 10x :)

 

[DaveC426913]

I thought the idea was that public keys were published ... well, publicly, sort of like a phone book. No black hat is going to be able to block that!

 

[chroot]

Dave,

Exactly. In every possible cryptographic protocol, there has to be at least some trusted entities. Either you trust the channel for key exchange (you meet in a secret hotel room and swap pieces of paper, for example), or you trust an organization like the New York Times to publish your key in the newspaper, or you trust...

- Warren

 

[mtanti]

But that's not what cryptography is for is it? Cryptography is for hiding data where the security of the 'hide' is as secure as your key, not your medium (in the case for public keys anyway)... So basically if you are either paranoid or are exposed in anything that you send or receive (such as being an inmate in a prison), cryptography is no good...

Thanks guys, this helped me understand a bit more, always publish your keys on an unalterable medium which is also good for publishing copyright material! (such as the newspaper or a magazine).

 

[mtanti]

I still have one more question, is publishing your public key on a website safe? For example, www.nero.com have checksums on their website for every software you download from there so as to avoid on-fly illegaly altered downloads (appending virus code to the software for example).

But is it possible for someone to alter the page your are viewing before it arrives to your computer and change the checksum?

 

[chroot]

This "flaw" doesn't mean cryptography is no good -- it just means that you have to be very careful with the way you distribute keys, as key exchange is really the most vulnerable part of the process of setting up a secure channel.

There are also many different key exchange protocols which can prevent (or greatly reduce the likelihood of) a man-in-the-middle attack. Having a trusted authority sign both users' keys is one way. Another is the so-called Interlock protocol developed by Rivest and Shamir. Another is the clever use of session keys.

- Warren

 

[chroot]

Mere checksums are not really for security -- they are simply for verification that the received data is error-free.

If an attacker changed both the payload and the checksum, you've never know the difference.

On the other hand, hashes digitally signed by a trusted authority are secure, because the attacker does not have the ability to forge a digital signature of the trusted authority.

- Warren

 

[mtanti]

Yes it's true but it is still used on that site to check for illegal modifications. So basically I cannot ask for a public key or checksum over the internet as it can be modified during transmission? You cannot make an online directory of public keys?

 

[Anttech]

But that's not what cryptography is for is it? Cryptography is for hiding data where the security of the 'hide' is as secure as your key, not your medium (in the case for public keys anyway)... So basically if you are either paranoid or are exposed in anything that you send or receive (such as being an inmate in a prison), cryptography is no good...

Public-Private keys are not only for cryptography but all for identification..