(Disclaimer: I am not qualified to speak authoritatively on cryptography - I didn't even take any undergraduate classes on cryptography as a student either)
The first part (the analogy for public-key encryption) is valid (analogising a public-key as a padlock works, but disregards the fact that a public-key (padlock) can be used to decrypt data encrypted with the private-key (the key) - which is counter-intuitive to a layperson).
As for the second part:
Bob wants to be sure the box came from Alice: (Bob gets Alice's signature)
- Bob sends box to Alice locked with her padlock
- Alice unlocks it, then puts Bob's padlock on instead, and sends it back to Bob
- Bob sees only one padlock which he unlocks with his key. He knows that Alice had the box as only she could have taken her padlock off.
Key-exchange - or any subsequent interaction between Alice and Bob - is not necessary to prove message authenticity:
In PKI, a digital-signature is basically a message-digest (i.e. a hash like SHA-256) that has been encrypted with a private-key (rather than a public-key) - so that anyone with the public-key can decrypt the encrypted hash (and then recompute the hash and if it matches then that's proof that the message came from the holder of the private-key for the corresponding public-key), like so:
- Alice sends Bob a private message.
- The message is encrypted with Bob's public-key, so only Bob can decrypt it.
- (Assuming Bob's private-key hasn't been leaked or discovered, of course).
- While the message is encrypted with Bob's public-key, that has absolutely no bearing on the originator or attestor of the message - because anyone can encrypt anything with someone's public-key.
- So Alice also adds her signature to the message, which does two things:
- It means that Bob can trust that Alice is responsible for the message (that she either authored or she's attesting to it) - again, assuming Alice's key isn't leaked or discovered.
- It proves that the message from Alice to Bob has not been modified (otherwise the recomputed hash wouldn't match).
- Alice adds her signature by computing a hash of the message, then encrypting the hash with her private-key, so anyone with her public-key can decrypt it and see her hash.
- Bob then receives the message:
- The message is encrypted with Bob's public-key, so only Bob can decrypt it with his private-key.
- The message has Alice's signature attached to it, so Bob can verify the authenticity and integrity of the message:
- Bob has Alice's public-key and decrypts Alice's signature, revealing Alice's computed hash of the message.
- Bob then computes his own hash of the message.
- Bob sees that his hash - and Alice's hash match - therefore the signature is valid and Alice sent the message.
Regarding Step 3 in the scenario you've posted:
Bob sees only one padlock which he unlocks with his key. He knows that Alice had the box as only she could have taken her padlock off.
This is not guaranteed and must not be assumed: Alice could have sent the exact same message to other people, and those other people could have encrypted the message with Bob's public-key and then forwarded it to Bob - if Bob receives one of those messages then there is absolutely no indication it actually came from Alice or that he was the original intended recipient.
This is why, for example, S/MIME for e-mail requires the entire message body and headers to be included in the message hash (in S/MIME this is actually done by copying certain headers like To:
, Subject:
, From:
, etc into the message and then hashing and encrypting that) - so while the adage that anyone can encrypt anything with someone's public-key, so long as the message is also signed by the sender then at least this approach preserves information about the intended recipient in addition to the actual sender.
Example scenarios:
- Alice wants to send a non-secret newsletter that can be redistributed by anyone:
- Alice would sign her newsletter content with her private-key.
- Anyone is able to redistribute (copy, forward, etc) this newsletter, and provided they keep the signature attached to the newsletter then anyone who receives it can be sure it originated with Alice.
- Because anyone could simply remove Alice's signature and replace it with their own, Alice can prove she originated the message by getting a signed timestamp signature, as anyone else who subsequently signs the same message (after removing Alice's signature) would have a higher timestamp.
- Note that this requires the use of a widely-trusted source of time information. Without a trusted source of timestamps the only solution in a zero-trust distributed system is by using a distributed ledger (aka blockchain) - which is another topic in itself.
- Alice wants to send a secret message to a single individual recipient (Bob):
- Alice would encrypt her message using Bob's public-key.
- Alice should also sign the message to allow Bob to know the message came from her and to ensure the message isn't tampered with in-transit.
- Note that nothing stops Bob from redistributing the message after decrypting it - encryption still relies on trust: encryption can't protect data if you can't trust the intended recipient of a secret message to actually keep it secret.
- Note that there is little point to encrypting a message using PKI without also signing it because (strictly speaking) encryption doesn't ensure message integrity (i.e. changing random bytes in an encrypted message in most crypto-systems will result in changed output (usually garbled output though, but some crypto-schemes like ECB mode can be successfully attacked without knowing any of the secret keys).