7

I understand that PKI uses digital certificates to link a public key to an entity, but is there anything similar for symmetric cryptography.

If, theoretically, PKI didn't exist, how do you know you are sending your ciphertext to the right person?

Is the security in the fact that even if you are sending the encrypted text to the wrong person, they won't be able to read it as they don't have the secret key? Would this not be dangerous as they can attack the ciphertext?

For example, Alice wants to send an encrypted message to Bob. Is there anyway (without PKI) Alice can know that her ciphertext is reaching Bob, and not Chris, who is pretending to be Bob? Does she have to rely on the fact that Chris wouldn't know the key so it would be considered safe?

There are no 'digital certs' to be used in symmetric encryption to tie a user to an address for example.

SilverlightFox
  • 33,408
  • 6
  • 67
  • 178
RJSmith92
  • 311
  • 2
  • 9

2 Answers2

8

The whole point of all encryption is that it's safe for the attacker to get your ciphertext, because they don't have the key. This is true for public-key encryption as well; it's perfectly safe for you to broadcast your ciphertext to the world, and certificates aren't related to that in any way.

The reason you use certificates in public-key cryptography is to know that you're encrypting something with the right key, because the key is generally sent over an insecure channel. With symmetric crypto, the analogous concern is that the person you talked to when you exchanged keys was an imposter; however, symmetric key exchange requires a secure channel with whoever you'll communicate with later, and so you can work out identity issues when talking directly with them.

Once you've directly tied a key to them, you can use message authentication codes to make sure that a message came from them and not from an imposter. Unlike digital signatures, you can't prove anything to a third party; with a symmetric scheme you know everything the other person does, so you could forge a message that looks like their messages. That's not an issue when you're talking to them because you know you didn't forge a given message, but you can't take that and prove it to someone else.

cpast
  • 7,223
  • 1
  • 29
  • 35
  • Thanks @cpast, you have cleared up my confusion. Just to conform, if Alice and Bob meet up and exchange a secret key and their IP addresses, Alice is 1.1.1.1 and Bob is 2.2.2.2. Later, when Alice wants to send a message to Bob, she encrypts it with the key and sends it to 2.2.2.2, she has no way to prove that Bob is at 2.2.2.2 but it doesn't matter? If it is Bob, then he has the key and can decrypt it, and if for some reason it isn't they can't decrypt it anyway without the key. So there is no need for some sort of certificate as with PKI (as you said, that is so you are using the right key). – RJSmith92 May 15 '15 at 04:16
  • 1
    @RJSmith92 Correct. If she has the wrong IP Bob obviously won't get the message, but no attacker can decrypt it (and she can then resend it, or put it on her blog, or stand on a street corner and shout it out a megaphone, or whatever -- the ciphertext doesn't need to be secret). – cpast May 15 '15 at 04:19
4

This in an interesting problem; with only symmetric encryption, how do you secure a communication channel (ensuring both privacy and authentication)? Researchers have been working on the problem for centuries and the best solution they've come up with is: Public Keys! That's a tongue-in-cheek way of saying that authentication is a fundamental problem in symmetric algorithms.

If Alice can get a shared key (aka shared secret) to Bob and be sure that Bob, and only Bob, has it then any symmetric encryption algorithm will provide both privacy and authentication. The fundamental problem is how to get the key to Bob without Chris getting a copy? This problem is well-studied enough that it has a name: the Key Distribution Problem. One approach is to use out-of-band methods like putting it on a USB stick and physically carrying it over to Bob, or printing it and putting it in a sealed envelope and sending it by a trusted courier. (These offline methods are collectively referred to as "sneakernet", aka "delivered by sneaker").

You might find your answer by doing reading about Shared Secrets, the Key Distribution Problem and Key-Agreement Protocols.

The Diffie-Hellman Key Exchange Protocol might be interesting to you. Despite technically being a public-key algorithm, DH allows Alice and Bob to securely agree on a shared secret over an untrusted network without either party needing a certificate, or either party needing to know the other person's public key in advance.

Mike Ounsworth
  • 57,707
  • 21
  • 150
  • 207
  • Thanks Mike, much appreciated. Regarding symmetric encryption, if Alice could 100% guarantee that only Bob knows the secret key, does it not matter that Alice cannot be certain that her encrypted messages might not reach Bob and go to Chris instead, as he doesn't know the secret key? I think cpast made the point in his answer that encryption means it is safe for the attacker to see the ciphertext. – RJSmith92 May 15 '15 at 02:12
  • 1
    ...and for Diffie-Hellman, I haven't read too much into it yet, but just quickly, I thought it did require a digital certification otherwise it suffers from a man in the middle attack? – RJSmith92 May 15 '15 at 02:36
  • 1
    Yes @rjsmith92, it is secure to observers who don't have the key. – Neil Smithline May 15 '15 at 02:37
  • 2
    @RJSmith92 Correct, Diffie-Hellman provides privacy, but not authentication. By that I mean that Alice can establish a shared key with _somebody_, and be 100% sure that only her and _somebody_ have the key, but it does not in any way tell who that somebody is. As I said, authentication (knowing _who_ you're talking to) is a fundamental problem using only symmetric key algorithms. – Mike Ounsworth May 15 '15 at 12:45
  • @MikeOunsworth Thanks, and a digital cert could be used with Diffie-Hellman to tie a Public Key to an entity, so Alice can then authenticate who she is communicating with? – RJSmith92 May 15 '15 at 12:54
  • 1
    @RJSmith92 Yes. For exampple, with TLS/SSL, the server has a cert but the client (browser) does not, so the server's cert is used to prove the server's identity before the Diffie-Hellman secret key (aka "session key") is established. – Mike Ounsworth May 15 '15 at 13:02
  • @MikeOunsworth Thanks again Mike, and lastly, the digital certification which proves the identity of the server, also contains the Diffie-Hellman public key, and therefore ties them together? – RJSmith92 May 15 '15 at 13:30
  • @RJSmith92 Great question, I have to say that you're pushing the bounds of my knowledge of the TLS handshake, so I don't feel confident giving an answer. Sorry. The TLS handshake using DH is a public protocol, so you should be able to easily find an explanation on Google. – Mike Ounsworth May 15 '15 at 13:43
  • @RJSmith92 I just found the answer in [this question](https://security.stackexchange.com/a/42350/61443). According to this answer "For ephemeral Diffie-Hellman (DHE) cipher suites, the RSA public key is only used for signing the DH parameters which are generated during the handshake." Meaning that the server's cert-public-key is used to encrypt and send the DH parameters; if the server is able to arrive at the same shared secret, then they must own that cert (ie have the private key). – Mike Ounsworth May 15 '15 at 13:53
  • @MikeOunsworth Thanks for taking the time to find that Mike. I also found the answer [here](https://wiki.openssl.org/index.php/Diffie_Hellman). As well as EDH which you said, there is 'Fixed Diffie-Hellman', which as it explains, uses a certificate that contains the DH public key. Thanks. – RJSmith92 May 15 '15 at 20:00
  • Let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/23838/discussion-between-mike-ounsworth-and-rjsmith92). – Mike Ounsworth May 16 '15 at 14:27