Take the 2-minute tour ×
Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

Can you help me understand the following reasoning?

If Alice sends Bob a message and that message is encrypted with two keys simultaneously: a symmetric key (Ks) and Bob's public key. The symmetric key (Ks) is also sent to Bob, encrypted with the private key of Alice. The conclusion reached from this exchange of messages is that Bob can not be sure that the message was written by Alice but Alice can be sure that only Bob can read.

But how can we reach this conclusion: Bob does not know if it was Alice who wrote if he had to get the public's Alice for the symmetric key (Ks)?

share|improve this question

migrated from stackoverflow.com Jan 15 at 21:37

This question came from our site for professional and enthusiast programmers.

4 Answers 4

I'm confused by your question. I'm assuming you meant something like the following:

Alice sends Bob a twice-encrypted message. Alice generates a fresh new symmetric key Ks, encrypts a plaintext message once with Ks, then encrypts the resulting data again using Bob's public key.

Alice also "encrypts" the symmetric key Ks with Alice's private key, and sends that encrypted key to Bob.

Bob "decrypts" the symmetric key Ks using Alice's public key, then uses Ks (and his own private key) to decrypt the plaintext message.

The conclusion reached from this exchange of messages is that Bob can not be sure that the message was written by Alice but Alice can be sure that only Bob can read.

But how can we reach this conclusion: Bob does not know if it was Alice who wrote if he had to get the Alice's public key for the symmetric key (Ks)?

I'm assuming the normal public-key assumption that everyone's public key is, in fact, common knowledge and can be looked up in some public directory or another, and Alice and Bob have somehow obtained (perhaps from that public directory) and validated each other's public keys.

Setting aside the fact that "encrypting" with a private key is almost certainly a protocol flaw...

Even though Bob uses the public key that he knows is Alice's public key, he cannot be certain that the plaintext message came from Alice. If Bob is as good at cryptography as we hope he is, he realizes that the true sequence of events may perhaps be something more like:

A long time ago, Alice "encrypted" a symmetric key Ks with Alice's private key and sent that encrypted message to Mallory -- or sent it to some uninvolved 4th party, and Mallory overheard and recorded that message.

Mallory forwarded a copy of that message to Bob with forged headers making it look like an encrypted message from Alice (which it is) to Bob (which it isn't) related to the double-encrypted message that Bob will soon receive (which it isn't).

(With some systems, it's not necessary for Mallory to ever copy any message from Alice -- with some systems, it may be possible for Mallory to simply flip a coin enough times and send those random bits to Bob with forged headers making it look like a encrypted message from Alice to Bob related to the double-encrypted message that Bob will soon receive).

Then Mallory and Bob both look up Alice's public key in the public directory to "decrypt" that random message into a symmetric key Ks.

Once Mallory has the symmetric key Ks, it's easy for him to forge a message to Bob that appears to come from Alice. Mallory encrypts any plaintext message of his choice once with Ks, then encrypting the resulting data again using Bob's public key (which he looks up in some public directory).

Since there's no way for Bob to distinguish these messages from Mallory from identical messages from Alice, Bob can't possibly know if the messages he received really came from Alice or not.

(There are other, better authentication protocols that would allow Bob to know whether or not the messages he received really came from Alice).

share|improve this answer
    
Yes, the problem in my reasoning thought if Bob decrypt a message with a public key of someone, such as Alice, knew that someone had encrypted with your private key, then it could only be that someone. Only that this mechanism really does not warrant authenticity of the writer's message. Such as this example of Mallory. Probably could only guarantee the authenticity with digital signature. –  user2989745 Jan 21 at 11:21

The problem is that there are not one, but two functions of asymmetric keys.

The first function is encrypting. To ENCRYPT data, you need only a public key. In this case, Bob has Alice's public key. He uses this public key to encrypt the data. The data is then sent to Alice. Alice is the only person who can DECRYPT the data, because only she has the private key.

The second function is signing. This is not the same as encrypting. Bob uses his PRIVATE key to SIGN the encrypted message before sending it to Alice. So when Alice receives the message, it is both signed by Bob's private key and Encrypted with Alice's public key. So Alice can use Bob's public key to verify that it was indeed signed by Bob, and then she can decrypt it using her own private key.

That way, she knows that (a) Bob sent it and (b) it was sent to her and nobody else read it.

The only part of this that isn't covered is the public key exchange, which ideally is done or at least verified in person or via voice.

share|improve this answer
    
Ok, but I can reach the conclusion that Alice encrypt your private key Ks with no warranty of authenticity, that is, no warranties to that Bob was Alice who wrote it, as if with a digital signature warrant that was Alice who wrote it? –  user2989745 Jan 17 at 19:56
    
Assume that the public key exchange was secure. They physically traded public keys in person. Now, when Alice gets the message, she knows that (a) it was for her, because it was encrypted with her public key, so only she can decrypt it and (b) it was from Bob, because it was signed with his private key, and she can verify this using his public key to check the signature. –  DShaw Jan 17 at 20:24

Actually I think your protocol is flawed. If the symmetric key was encrypted (should be called "signed" actually) with the private key of Alice then anyone will knowledge of Alice's public key will be able to recover the symmetric key and hence read your message. Hence, no confidentiality is provided.

However, the encrypted message which was signed with Alice's private key can serve as a digital signature (sort of - people usually sign the hash output of the message instead). This provides assurances that the sent message was indeed sent by Alice if Bob knows the public key of Alice. The public key can either be pre-shared beforehand or transmitted with the use of a public certificate.

share|improve this answer
    
I understand what you say, but my situation is to verify the proper functioning, but given that scenario I described what conclusion we can reach. And one of which is: The Bob are not sure that it was Alice who wrote the message, ie, it may not be the broadcaster. And I do not understand why .. since Ks need to decrypt the public key of Alice just have to be sure that it was Alice who wrote. Given that scenario I do not see how you can reach that conclusion –  user2989745 Jan 17 at 12:06
    
I think unless the public key of Alice is securely communicated to you either thr a face to face meet up with Alice or thr the certificates then you cannot be sure that the public key you are using does indeed belong to Alice. –  jingyang Jan 17 at 14:10
    
In conclusion if Alice simply encrypt with your private key Bob has no assurance of authenticity of the message, that is, that Alice wrote that right? Only with digital signature guarantee is that such authenticity? –  user2989745 Jan 17 at 16:55
    
Yes, you would need a third party like the certificate authority or other peers(done in pgp) to assure you the validity of Alice's public key. –  jingyang Jan 18 at 1:46

Technically, the message is signed by Alice using her private key and encrypted using Bob's public key. So only Bob may decrypt it using his private key and he can check the authority using Alice's public key.

Both should check each other key validity using an external procedure before using such encryption/signing, e.g. meet face to face in a bar and verify keys fingerprints.

share|improve this answer
    
yes I understand the reasoning . But still do not understand the conclusion reached in the logic described above. Only barely understand the concept of asymmetric cryptography . Because if Alice encrypts Ks with its private , then Bob will have to decrypt with the public key of Alice right? or is it with your public key? Because if it is with the public key of Alice and Bob must know Alice that was encrypted to know which public key to use . That's what's making me confused . Bob to decrypt that key Ks have to use? Thank you for your attention –  user2989745 Jan 15 at 22:34
    
Regarding Alice keys. She doesn't encrypt with her private key, she creates a sign using a given message text and her private key. Bob (and actually any other person in the universe) sees the unencrypted message, sees the sign and having Alice's public key may ensure if that sign can only be created by a person with a private key whose public part (i.e. public key) is attributed to Alice. Or maybe you need technical details about math used to perform the task? –  user3159253 Jan 15 at 23:23
    
I admit I 'm confused .. But in this case for Bob decrypt the key Ks had to have the public key of Alice or am I thinking wrong? –  user2989745 Jan 16 at 0:30
    
Ok. Regarding encryption. Technically to encrypt a message Alice needs only Bob's public key (remember, sign and encryption are two different procedures!). Alice takes an unencrypted message, Bob's public key and produces a message which can be decrypted only with Bob's private key. –  user3159253 Jan 16 at 2:04

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.