How to Send a Secret Message
ฝัง
- เผยแพร่เมื่อ 22 พ.ค. 2024
- How do you send a secret message if someone might be eavesdropping? How can you give someone a locked box to open without giving them the key? Here, we take a look at the three-pass protocol and man-in-the-middle attacks.
0:00 Locks and Keys
1:20 Three-Pass Protocol
3:28 Man in the Middle
***
Spanning Tree is an educational video series about computer science and mathematics. See more at spanningtree.me
To be notified when a new video is released, sign up for the Spanning Tree mailing list at spanningtree.substack.com/
Spanning Tree is created by Brian Yu. brianyu.me/
Email me at brian@spanningtree.me to suggest a future topic.
Imagine being this worried about a sheet of paper when you don’t have a door on your house.
Hahahahahahahah
The paper was the purchase order for a door. But now hes doomed to be doorless.
Made my day
Moga seen a billion comments today across all of youtube, yours was the best
😂😂😂
A very simple misleading idea isn't covered which is why you can't just send the locked box first and then later the key. This is because, as pointed out by another commenter, the messenger could fake their delivery of the box and then come back for the key while it is still secretly in their possession. Additionally, you would never be able to reuse this key because it could also have been cloned.
And in the real world, messages that are or aren't encrypted can be cloned as well.
You’d 😊😊
You tell the messenger to go naked so he won't hide the suitcase on himself
I was thinking that this was what the video was about, guessing as to what was gonna be this method of sending a secret message… until it hit me at the end, yes, that key can be copied.
@@spectralspectra2282 then he just hides the box in a bush or something
I love how messenger went from "Might not be so trustworthy" to getting angry that he can't read the letters
But we all know that the real reason he is angry is that the guy makes him go back and forth 3 times instead of going himself for these 20 meters down the street.
You just described every government trying to snoop into encrypted messages
Based on the idea of public and private keys. The recipient could paint their house blue for everyone to see. When you receive the box with the two locks you can verify that the color of the house of the recipient matches the color of the lock. In practice this is a bit more complicated, but a combination of public and private information is often used.
In order for this to work effectively, private keys need to be kept completely private, and public keys should be as public as possible. If your public key is not widely known, an angry messenger could share their own public key and claim it's yours; now only the messenger can read secret messages meant for you!
@@InventorZahran why would you send a secret message to someone if you didn't know their public key? why would you carry a private key if you didn't intend to keep it completely private? the only concern is over whether or not the private key accidentally gets out, in which case a constantly changing private key might be optimal.
@@InventorZahran how to solve this, if the man in the middle shares their public key and claim to be mine? how would the sender verify if its my public key.
This is the best way I've ever seen this explained. I have learned this, forgotten it, and relearned it more times than I can count but this explanation was the easiest to understand I have ever come across.
so relatable
Every bit of what you said.
I learned it this way - though as a challenge, how do you do this - in Computer Science in ~2004.
How on earth do you forget something so simple?
@@thishandleistaken1011 Don't even pretend like the private key public key system is intuitive.
Fundamentally, there is nothing you can tell your recipient that you are not also telling your messenger. The only solution is to have a different, trusted medium of communication prior to using the untrusted messenger, in order to set up secure communications.
This can involve meeting in person to exchange keys or a one-time pad or a public key. Or using asymmetric encryption, posting your public keys through multiple different messengers so you and your recipient can reduce the likelihood that every different messenger will get away with lying about those keys.
if I encrypt message with asymmetric public key .. how can "messenger" steal the data if only the rightful receiver has private key ? well apart obvious .. stealing the private key .. I can't see any other way .. is there any ?
@@TechExpanse instead of giving it to them, just be the recipient yourself. send them your public key instead.
@@TechExpanse You still have to trust the initial key exchange. If you get "the recipient's" public key from one untrusted messenger, then it could just be that messenger's public key. To avoid man-in-the-middle, you still need a different way to establish trust initially. What's great about asymmetric encryption is that you can just broadcast your public key across every possible messenger to minimize the probability that someone else will be deceived about your key. No way is every different messenger coordinating to give the same fake key to your sender.
Even better, the sender can sign the message with their own private key in addition to the recipient's public key, so the recipient can verify who created the message in the first place.
What about signing the message to verify the authenticity? If it was as easy as intercepting the message and sending your own public key the whole internet would be compromised
@@Chriss4123 root certificate authorities are the trusted third parties. Every operating system comes preinstalled with the locks to them in which you can use to securely communicate, and they will give you the locks of your recipients (since they are the ones that manufactured all the locks).
If a CA got hacked then the effects will be indeed devastating. Modern computers will try to contact a bunch of CA at once in case one is compromised.
I'm about to get a computer science degree, till now I understood man in middle attack in a wrong way.
But you made it clear!!
Thank you so much for the video!!!
This explanation is AMAZING. Yall have no idea how complex this is usually explained. With this beautiful explanation and video, even a child could understand this.
Two men in the middle could theoretically work. If you sent the box through one third party with a lock on it, Alice either receives or doesn’t receive the message. When it comes back it has two locks on it. It doesn’t matter if the second is Alice’s or the third party’s. After unlocking your lock, send the message through a different third party. If Alice sees a lock that isn’t hers, she wasn’t given the box in the first place meaning one of the first third party tried to sneak a peak. If the only lock is the lock she recognizes, she is safe to open the box. If there are two locks, one of the locks is hers and the other is the second third party’s. 1/3 of the time you can receive the message, the other 2/3 you can at least be safe knowing the message will not be received by a third party. The only assumption to this solution is that the two third party’s have no idea that you have sent a message through both of them. If you retain anonymity then they won’t be able to coordinate in order to open the box.
But what if the 2 third parties decide to cooperate?
Nothing stops the 2 third parties to team up against you, it would make it even easier for them.
How would Alice recognize the key? There would have to be some way to fake a lock that would contain some quality that Alice would assume makes it the original lock. This would also require some guaranteed way of informing Alice of the lock beforehand, at which point you could have given Alice a key anyway.
@@andrewe.7299 you clearly didn’t watch the video if you’re asking this question. All encryption locks come with a key and if the key doesn’t fit the lock then lock is not yours.
@@4duanich I don’t know how my second reply keeps being hidden by my reply to the person above will be the exact same. Clearly you didn’t read the full comment which made the assumption of full anonymity when dealing with two third parties. Full anonymity would make it so that they would both have to guess that the package is from you in order to get into contact. To further the impossibility of this in the real world, you could assign several hundred third parties to a random number generator and pick completely random third parties so they’d not only be guessing where the package is, but there would also be no mathematical way to increase the odds.
the most underrated channel of youtube, I first clicked djikstra algorithm video and I lost myself, great!
This is wonderful. I have been wanting to find an animation I can send to students/peers to better understand cryptography and the problems you highlighted. Finally found it!
One possible modification to the protocol to prevent a man-in-the-middle attack would be to use digital signatures. Instead of physical locks, you and your neighbor could use digital keys and signatures to lock and unlock the message.
In the first pass, you could encrypt the message using your private key, and then sign it with your digital signature. You would send the encrypted and signed message to your neighbor through the messenger. The messenger would not be able to read the message because it's encrypted with your private key.
In the second pass, your neighbor would receive the encrypted message and add their own signature to it, using their own private key. They would then send the doubly signed message back to you through the messenger.
In the third pass, you would remove your signature using your private key, and then send the message back to your neighbor through the messenger. They would then remove their signature using their private key, and be able to read the message.
With this modification, the messenger would not be able to read the message because they would not have access to your or your neighbor's private keys. Additionally, if the messenger tried to modify the message in any way, the digital signatures would be invalid and you and your neighbor would know that the message had been tampered with.
I think you fail to see that the man in the middle simply adds their own private key and pretends it has been delivered. You then remove yours and the attacker has the only remaining key.
@@cptncutleg read the last paragraph
@@user-pc3rw6mq7b please see 4:00 it's the same principle.
@@cptncutleg The digital signature of your neighbour would be known to you, so if the messenger added their own signature, you would notice it is not signed by your neighbour. It's the same process which allows Microsoft to verify a product is from them and not any other company
I agree with @@cptncutleg
This was recommended to me at a really interesting time. I only just recently learned about the existence of commutative encryption while doing some research into how "Mental Poker" works. I had previously spent a lot of time learning and understanding how key exchange protocols work (namely Diffie-Hellman and its elliptic curve variant), as well as trying to understand how TLS uses public-key signatures to prevent man-in-the-middle attacks, but I had never heard of this simple three-pass protocol before this video. It makes a lot of sense how it works, but as far as I can tell, it's just not used at all these days (I believe due to the challenges with designing commutative encryption protocols). I'm glad I found this video, as it's a really great explanation of the concept.
Yes an amazing video I learned something new
it's not used because man in the middle is too easy on it.
Another thought is that the latency added by doing three passes, if you want your message to be delivered efficiently, thricing the time it takes for the receiver to actually read the message is quite time wasting.
"this was recommended to me at an interesting time"
Yup, that's how algorithmic recommendations work
It's not used because it doesn't work, as he explained.
In encryption, we haven't really found a way for MITM: we use certificates, which basically means you need to meet a trustworthy guy once that will guarantee if you are talking to the right person or not
This is absolutely adorable … love the blinking of the eyes and the evil eyes of the messenger …such detail. 😍 ❤
Oooh. I just stumbled on this channel. Love the way you present and explain things. Instant sub ❤
He really deserves a lot more likes and subscriptions.. Such a high quality content is hidden behind youtube's algorithm
1000%
Very much...
youtube algorithm recommended me this
true!
I only saw this BECAUSE of the algorithm. Are people sure they know what the algorithm actually does?
Plus this isn't that high quality, the animation is totally broken.
The beautiful world of encryption. Love it. Great presentation too!
Such an amazing explanation
Every single frame of this video worth it all.
This is a gold mine! thank you for all these videos
How does this channel only have 7k subscribers... this is incredibly high quality.
yeah this guy could be an instructor at harvard university or something
It has 50k now...
@@alekslevet It has 60k now..
@@mikethegamedev it has 100k now
It has 1M now...
Really good explanation for students. Congrats! I Will recommend It.
Excellent video.
Please continue creating such amazing content .. you made it so easier to understand such stuff which is complex in mind….. i can understand the hard work behind … kudos
I think you'd have to have a system that's already in place before you can even put the first lock on the box. The person you're sending the message to would have to use a lock that has their signature on it. This way, after sending the box with your lock on it, once the box comes back, you'd have to check the lock to make sure it has the signature, confirming that it is in fact the one installed by your friend, and not by the messenger.
That signature, in computer terms, might come in the form of two-factor authentication. They would input their password, then verify it by confirming on a second device, or by inputting a bit of personal information.
But how do you know what the other person's signature is? How do you make sure it isn't just Eve's signature?
What if eve is a stalker and has practiced the recipient's signature
The issue is then knowing what a correct signature looks like. SSL solves this problem by making a small number of Certificate Authorities that can use their well known signature to vouch for less well-known signatures. A less centralized method called Trust On First Use (TOFU) basically has both ends exchange signatures the first time they talk and hope that nobody was interfering with the initial handshake, if the signature every changes, a big warning shows up that means either all previous communication was being tampered with or the current connection is being tampered with (or that somebody just accidentally deleted their certificate (most common)).
@@legohexman2858 the signature is different everytime like a hash but to prove they actually sent it they include a key which unlocks the secret message that proves they sent it but without the private key your can't make your own signature on their behalf
BTW this is, by far, the best explanation of this I have ever seen. This is what I send to people who are not tech savvy. Should be used in trade schools. A+
Amazing explanation
Amazing video!
Please keep it up! 😁
Glad you enjoyed!
My answer to the Man in the Middle Attack is to use a time lock encryption. Alice sends video of her saying the time of day, encrypted using her private key and then the time lock encryption. Bob spends one minute decrypting the time lock encryption and decrypts the message using Alice's public key. In order for Eve to use the man in the middle attack, she would have to replace Alice's private key with her own. But to do that she'd have to first spend one minute decrypting the time lock encryption, and by the time Bob gets and decrypts the message, it will clearly be two minutes old instead of one minute old, so he knows not to trust her key.
Edit: I thought about this more. You could just record saying your public key (maybe salt it by a random number given to you to make sure if it's CG it has to be real-time). Or you could have part or all of the conversation time-locked, and at least be sure nobody is listening in except the person you're talking to. Eve could pretend to be someone else, but she has to be able to fake whoever you want to talk to.
Why wouldn't Eve just follow the same steps Bob would, resulting in the same problem of the middleman acting like the recipient.
Eve could just copy the message and send it as is, then decrypt it herself. Bob receives the message as if nothing happened, and now both know the message.
MitM can only be defeated by having first securely exchanged public keys. No other change to this scheme will work, because you can never be sure you talk to the man in the middle or the trusted party.
Public key is public. Everyone must know it. Otherwise it is just secret key specific to Alice/Bob and they know both of them.
The solution to this seems easy to me; Just use a computer that's twice as fast to do the decryption, so Bob doesn't notice the discrepancy.
Making the lock customized, containing unique symbol or something that lets you know whose lock it is would potentially solve the problem partially. Then, when the messenger returns with the lockbox you'd be able to check if it's the lock belonging to your friend. The downside is that you must have prior knowledge of just what lock your friend uses and they can't send you the lock pattern without exposing it to the messenger.
They arent actual physical locks tho. they are algorithms.
@@VoltsandVodka extend the metaphor and use your brain
That sounds convoluted yet still vulnerable. Any communication as to how the neighbor can recognize your lock will either be done through the messenger or without him. If it's with, he can intercept that message itself and make use of it to do a forgery where your neighbor thinks they're talking to you but no, not actually. And if it's without him, then why bother with any of this? Just hand your neighbor a copy of your key instead.
@@VoltsandVodka This is exactly what SSL/TLS dose, the lock is signed and that signature has a 3rd party reference that says I came from here and should have this lock on, by a highly trusted 3rd party of both parties the other intended party checks that if the lock and the signature match via the trusted 3rd party. if anyone adds anything to it in any way AKA another lock the validation fails.
@Martin Barker I feel like that should have been part of the video, since that is basically how most of the digital world communicates nowadays
this is the best explanation i've seen for how RSA can completely fall apart. using the wrong public key or messing with public key access/distribution can cause huge problems. the only truly "perfect" system in this example is a one time pad, where the pad is delivered without a messenger before any messages are sent. a LOT is riding on the pad though lol
one way is both the sender and receiver having signature on their lock.
But if messenger duplicates the signature??
@@jatingarg3267 how can anyone duplicate public key? private key is the signature and public key share among sender and receiver.
The messenger can see the message, they know the signature, it can be forged
@@HashCollision digital signatures change depending on the message so forging would require brute force
@@jackyhash8980 You don't have to duplicate the public key. You just have to convince Alice that the courier's key is actually Bob's key. We wouldn't need CAs if it was that easy.
This makes teaching people really simple to understand. This is really useful!!
you need more subscribers fam this is gold
This just randomly appeared in my youtube recommendation.
It's good, but it was so out of context that it become so funny.
This is awesome
The cliffhanger is killing me haha!
Like PGP, You send a 2 lock box with a public key attached. Receiver will be able to open the box with the public key and his private key.
Public key can be share anywhere, the middle guy will only be able to send his own message to the receiver.
SSL/TLS also is working well to avoid basics MITM attacks (Working on the same model)
Diffie-Hellman key exchange uses mathematical approach to safely exchange keys (public keys) between two parties
I say, just use two different middle men. One with the key, and the other with the locked box. Chances are, they won’t interact with each other. Not the perfect method, but I feel like it’s one of the more effective methods that’s not overly complex.
This is actually a really good idea, not sure how it'd work with computers, probably by sending an encryption code through a different path or something but for the method provided, it's good
but how would you know that they're not the same person wearing disguises?
@@Falcon4eva There is no guarantee, this system hinges on the assumption that the two middlemen have no interactions with each other.
I can imagine the only way to stop that would be to thoroughly research the middlemen that you are using.
Hey i don't know much about this topic but the person who wants your information would kind of hack like your messengers right and get information this is what happens actually right? So that way there can't be any more messenger because Messenger is symbolised here as hacker
Here's my idea. Have locks that provide some form of identification. If a lock is on the box with the wrong identification, then you know it didn't reach the intended person. This doesn't prevent the messenger from using a lock with the same identification as the target, but it makes it harder for the messenger to do so.
But how do you know what the right ID is? If your neighbor can freely send their ID, then the messenger can intercept it. And if you somehow devise a way to secretly send the ID... why not just use that for your original message?
@@JakeLaMtn the ID can be based on the output of a private algorithm that uses only public and changing information such as the price of a stock. the time and date can be a part of this ID to allow for collecting of the correct information, as transit time is uncertain.
this does require that there formula can be sent without it being peeked at, so it would require that the first party goes in person to give the algorithm, but after this all that needs to be done is the second party adds the ID generated by the algorithm to the lock before sending
@@mcjavabelike8320 Because you allow for that initial meeting where you decide on the algorithm that is to be used, you could have just given them a copy of your key (or another key that is capable of opening the same lock). In fact, *that* is what you have just described.
But if its the first ever message sent, then you dont know if the id was real in the first place just like the intercepted padlock,
I'm so invested.
Wow, I only discovered this amazingly clean explanation in 2023!!!!!
Using an asymmetric encryption protocol like RSA using a public and private key pair. Your neighbour publishes their public key, you encrypt the message with their public key and send it to them, which your neighbour can then decrypt. The issue still is how to verify that the public key your neighbour gave you is actually theirs, which can be done with a trust authority (ie, signed certificates), or you can literally visit your neighbour once, in person, and they can hand you their public key, giving you 100% assurance that the key does indeed belong to them and not some man in the middle.
Does this not still have the same issue? The middleman will also be able to read the neighbor's public key, and just decrypt on their own
@@imaadhaq540 No, you can not decrypt the message with the public key, this is why it's called Asymmetric encryption, you must have the private key to decrypt it.
There's fundamentally no way to associate a key with a specific person digitally. That's why we have "web of trust" and certification authorities. The best you can do is store all public keys publicly, so at least Amazon has a chance to say "No, that guy? He's claiming to have Amazon's key but he doesn't."
The method shown in the video is already asymmetric encryption. You don't have a shared lock that both parties have the key for (symmetric encryption). The issue is how to ensure you get the correct public key which is analogous to making sure the lock is from the receiver. To be really sure, I think meeting in person or via some other trustworthy medium is the only way.
@@1vader There's a story set in the far future with a galaxy-wide civilization with spaceships whizzing around and such. Can you guess the most valuable cargo per pound? One-time-pad keys. :-)
you give the box to the masseur, he gives it to the neighbor, he goes back and you give him the key, he takes it to the neighbor.
however, it has vulnerabilities, as long as the messenger does not really bring the box to the neighbor but "hides" it so then he takes the key and can do whatever he wants
yeah, i thought that too... another vuln being that the box (data) can be copied as well
this is digital, the messenger could just save the box and then unlock it with the key
Send the message, once received, send the key.
To dedend from seeing even open, or x-ray'd, create your own emcyption instead of locks.
In order to prevent copying and using your decryption(key), you could also send a password locked physical usb to your receiver. One such as the self destructuve 3-attempt one's i've seen.
And then, you prevent copying, as you once again, send a key, seperately after it was secured.
You can use two messengers, one to deliver the key and other the box.
Bonus ducks if the messengers don't know each other, think that the other one is dead or both have been told the receiver already has the second thing.
I don't see any way you could do this without allowing the messenger to simply impersonate your neighbor. Unless there is some type of thing that connects to the identity of a person. This must be impossible.
That's exactly the problem, yes. If you want secure communication you need a secure side channel to exchange identity information. Meeting in person to exchange that information for example. That's for example why browsers have hard-coded certificates (presumably obtained via trusted means) from trusted Certificate Authorities and why self-signed certificates are never trusted, and why email encryption only works if you have somehow pre-established trust via some trusted side-channel (unbroken CA certificate chain in the case of S/MIME for example).
well in cybersecurity or smth there is a solution rsa stuff
@@lilydome No, RSA has exactly the same problem.
The only solution I think is a 3rd party trusted source that can vouch for a signature from someone
You could intentionally have the third party use a encryption
1:04 You could send them separately. Send a key, then send the box later (or Vice versa)
Takes key, leaves and drops is some where.
Comes back for box, gets box and pick up key, open box*
I really love diffie-hellman technique!
I believe the question boils down to "How can you know if your neighbour was the one that put the lock?" And the answer is pretty straight-forward, actually. You ask the messenger to send you proof that the lock belongs to the messenger. In this video example, where the people live in a physical world, a video of the messenger sending the locked box to your neighbour and your neighbour adding their lock to the box is enough.
The sender should have two keys:
1. With the first key he places the first lock
2. The second key should open the lock placed by the recipient
In case the messenger tries to fake delivery with his own lock, the 2nd key wouldn't be able to open it and the sender would recognize failed delivery.
If and only if the sender is able to open the second lock in the second pass, only then he should remove his first lock
Its an analogy for incryption programms. The key and lock change every time a new messages is sent, to avoid people "replicating the key". If you always use the same key and lock to encrypt a message then someone could just decrypt one of those messages, find the key while doing so and decrypt every other messages
How do you get the other key?
@@JeffIsBetterThanBacon The sender / originator has both the keys at start
This is kind of like the stacked rings puzzle, and the pattern you have to take to solve it. What if you added 2 locks. One of which the receiver has a copy of the key. They unlock the second lock, and add their own. Send it back, and you only add a lock if the backup lock it removed. When the receiver finally opens the package, there’s a new key inside that’ll be used for the next package. The first key has to be initiated once using a face to face method with no carrier.
Theoretically, you could have previously set up a two way communication system with the recipient, (e.g. Radio comms system in your own encrypted channel) where the recipient would send a previously agreed upon word or phrase (eg Cat) so when they get the box for the first time, they would send that over on the encrypted channel and then add their lock, send another message, you would send another message, and so on. If they don't give you the message, you will know not to unlock your key. It is complex, but it probably would work.
You can try to deliver the message with a lock to your neighbor then has his sign (special sign everyday that you know it by yesterday message) back that shows that he has already read. Then give the key to the messenger. You can use this when you deliver the message back.
Assuming that both the sender and recipient knew each other, maybe use a lock that requires a password to open, write something that the messenger couldn't possibly know on the box like "the password to the lock is your (the recipient) birthday" and then inside the box insert an instruction to send the box back with a lock that uses my (the sender) birthday as the password, to confirm that it is indeed the intended recipient that got the message.
Idk if this translates well in computer tho
Well, there is the option of "just knowing" the key. In the metaphor, send a lock that you both have a key to open.
In this metaphor that would basically be Bob and Alice meeting up and exchanging copies of their keys in person.
You can do this in real life too, I have an encrypted chat app on my phone that lets you scan a QR code on a friend's phone to exchange keys in person.
Or in the case of setting up a computer with SSH, you could upload your public key over the internet or you could put it on a flash drive and physically insert it into the machine to be 100% sure it isn't tampered with.
How do you send this communication to Bob? Though the messenger? Can't the messenger just do the steps Bob had to do?
@@jaideepshekhar4621 the idea is that you would use some other medium to transfer it, usually in person
@@rhysbaker2595 But that's not feasible for continuous regular communication with a ton of people. How would you adapt it for computers?
Alice publicly announces she has a message for Bob. Bob wants the message from alice.
Bob publicly announces and sends 2048 different and open toggle locks to alice. Alice is unsure if she will receive Bob’s locks. Never mind.
Alice announces she received locks. Bob and Alice is unsure.
Alice puts her message in a box and locks it with her lock and 2047 of Bob’s locks, keeping one of Bobs’s locks for herself. Alice sends the locked box to Bob. Bob receives the box, announces it publicly and removes 2047 of his locks.
Bob is still unsure. It’s his locks for sure, but is it Alice’s box? Alice knows Bob received a locked box. Alice is still unsure if it’s the box she sent.
Bob feels sorry for himself and Alice, and publicly shows a picture of the key to the lock Alice kept.
Alice makes a copy key. Alice tests the key in Bob’s lock; it fits! Alice is happy! She must have received Bob’s locks.
Alice publicly displays a picture of her key. Bob makes a copy of it.
Bob unlocks Alice’s lock. Bob reads the message. Bob is happy. Alice is happy.
Maybe?
😂
More like public WiFi authentication in a nutshell
hypothetically, doesn’t publicly announcing that you’ve received a secret message from bob defeat the purpose of a secret message? I understand that the message will still be secret, but everyone else would know that they’re secretly communicating, yes?
(unless i am misinterpreting the public announcement part)
@@zamaii_ i mean, in the examples of the videos the communication was never secret, just the content of the communication.
@@zamaii_ well, we all know about the secret cia and fbi records, but does anybody know what they're actually communicating? No, so their plan hasn't failed.
@@zamaii_ The purpose is so the CONTENTS of the secret message is secret, not the fact that it's sent. It is impossible to send a secret message / encrypted message and not people know that you sent it.
one solution i can think of is creating tags for the locks, to identify a third party's lock in the event of a breach of security, like the color coding shown here. this might not be easily applicable to a physical scenario, but in a digital reality we can easily manipulate, it is very much possible
After watching this animated story .as a student, it was very easy to understand the concept.
You can have both locks connected to the bag in a way that resembles an or gate. It's safer (since there's no protocol that could be exploited, the only vulnerability are just the locks and the bag itself) ...and you or your neighbour can open the bag with either keys. 1 way to construct this is that you make a bag with 2 openings 1 opening is locked by the sender and the other opening is locked by the reciever and the locks stay on the opening at all times. I guess the messenger can still chose to put there own lock on the bag or not deliver the bag and hold the bag for ransom but at least the messenger can't open the bag without directly exploiting the weakness of the bag or lock
If it's operating like ar OR gate, wouldn't the bag simply be unlocked on the last leg of its journey?
@@charmio The point of this configuration is to make both locks lock the bag during the journey but still allow for both the sender and reciever to open the bag without the need to pass it around 3 times given the lock comes with the bag.
@@FunoyingSounds But I'm still confused as to how the sender gets the receivers lock? Or in other words, how does the receiver know what key to use? Wouldn't they need to exchange keys/locks beforehand?
@@charmio If I understand correctly, they would need to meet once, but the sender could then send multiple messages without needing to meet again. On that initial meeting, I'd imagine the sender and receiver each have a suitcase with a lock permanently built into it. They glue their suitcases together and cut out most of the glued sides, forming one container; the receiver locks it, and the sender leaves with it. Then whenever they want to send a message, they put it in the container, lock their suitcase, and send it; the receiver unlocks their suitcase, retrieves the message, locks it again, and sends the container back.
(Public-key cryptography allows for the equivalent of this without the initial meeting: the sender encrypts the message with their private key, then encrypts the result with the receiver's public key; the receiver can decrypt the message with their private key, then decrypt the result with the sender's public key.)
Your neighbour sends you an (unlocked) special box with two locks. One lock, the 'public lock', can close the box, but not open it. The other lock, the private lock, can open the box. She has the keys to both locks. She will send you a copy of her public key, if you don't already have it.
You receive the open box, you have the key, you put the message in the box, close it with her public key, and send it. Voila.
To be sure it is *her* box, you could go and visit her once, and pick up her box (and public key) yourself.
I didnt follow, if the special box has 2 locks and I receive 1 key, how am I able to open the box? I dont have the private key to open the private lock and insert my message into the box
@@Mostbee "You receive the open box" - she sends it opened, unlocked, with nothing in it.
@@commonpike So then whats he point of the private lock? You have 1 key for 1 lock, send the open box with the lock, the receiver put the message in and lock it with your lock. I didnt get what's the meaning and diferentiation between a public and private lock if there's only use for 1? Also the middleman could just switch the lock for one they have the key, visiting a person to familiarize with a key defeats the purpose since you could just say the message in the visit.
I had watched computerfile but this had never been so easy to understand encryption
If there were two messangers, you could use the first three pass protocol but with a third yellow key in the box. Then if you change to the second messanger you can simply use one yellow lock and you both have the same key. The first messanger could have that key but now that you are using a different messenger if the key was intercepted you would know as the receipient cannot unlock your message.
This however means the first messenger cannot access traffic with the second messenger.
I believe the most common protocol is to give everyone the lock that opens only to your key and only open box locked by them. Is the public key method.
You use your neighbor lock to send your messages and he uses yours to send you message, not even the sender can open the message, only the true receiver since its his lock you used.
You still have the problem of the man in the middle. Unless you exchanged keys in a secure manner they can still intercept the key exchange.
@@TheClonerx they don't exchange keys. They distribute locks.
Basically you tell everyone how to encrypt the message in a way only you know how to decrypt. The middle man will have the same info everyone else does, how to encrypt (lock the message), but can't decrypt it (open the lock). People will give him massages already encrypted, so there's nothing he can do to "open" it.
There's still things the middle man can do, like not delivering the message, or fabricating a different letter, but he can't read people's messages.
@@luizpaulosantosribeiro9005 How do "you tell everyone how to encrypt the message"?
Telling someone or everyone something still requires a messenger.
The messenger could intercept that message and replace it with an encryption that the messenger knows how to decrypt.
Start by setting up a password with your neighbor that the messenger doesn't know. (That's the tricky part.) When you send them a message, have them send back the password on the outside of the box. Only remove your own lock if the messenger returns with the correct password. Then, change the password every time you send a message, and include the new password in the locked message.
But how do you deliver the password to the neighbor. You are still faced with the same problem.
@@johnhilton145 Yeah, that's why I specified that it was the hard part. But if you can get just that one message through safely, you'd have perfect security for the rest of time with that particular neighbor.
I think my reply was deleted, so I'll leave a shorter one summing things up. using rolling passwords would work, but a simpler way is to personally deliver a copy of the key to your lock to the recipient if you're already able to get to them in person. this allows future messages to be sent back and forth in one pass.
ECDHE is widely used to solve the main problem in the video, giving both parties a way to securely derive a shared secret key which can be used on both ends to encrypt/lock and decrypt/unlock (essentially 2 copies of a key to a lock)
AES is usually used as the lock itself, for encrypting messages with the secret key
If you can communicate with the recipient in a guaranteed private and secure manner just one time, you can exchange a one-time pad. An OTP gives you a fixed amount of unbreakable encryption, which you can use to exchange keys or any other messages until it runs out of bytes.
You can reuse your OTP a little bit, but any reuse does expose some information about the OTP which could break all prior communications open. So don't do that unless you're desperate.
@@Mothuzad if you have that option, you're probably best off sharing an encryption key to use with something like AES-256. one time pads are definitely cool, although reusing them at all is a bad idea. there's a great stackoverflow post out there showing the amount of data you can reveal when you do.
If you and your neighbor make a similar and small change to the locks you could prevent man in the middle attacks as long as you can get the bot across to your neighbor without the messenger seeing it
The algorithm has blessed, atleast me, with this video. Cool!
The receiver created an empty trap chest, which can only be unlocked by himself. The trap chest is initially open. As the name suggest, once sender put something in it and close it, it is locked. Nobody but the receiver, who also the owner of that trap chest, could open it.
In computer science, it is called assymetric public key infrastructure
But how would you know if the messenger didn't send you their own false message?
Doesn't work.
The messenger creates his own trap chest and gives it to the sender. The sender can't know, if he is putting his message in the receivers trap chest or into the fake trap chest, that was created by the messenger. The messenger can then unlock his own trap chest, do whatever he wants with the message and then put it into the receivers trap chest before completing the delivery.
@@ruroruro thank you. yes, the trap chest in public key, expected to be WELL-KNOWN by public, that everyone admits its authenticity
@@anjarwicaksono229 if you can exchange some information in advance (for example, the information on how to identify a "trusted" trap chest) then you can just exchange your keys instead.
It's kind of a chicken or an egg problem and there is REALLY no way to solve it in practice without sharing some secrets in advance or just trusting some 3rd party.
Bro, literally just bring it on your own
this seems like one of those videos that you watch in class and i like it
The best answer is to use a cipher only the recipient and the messages knows to solve (public and private keys for encryption). Along with attaching a tracker that goes off publicly when Accessed.
If addresses don't line up, you have a security breach and can then replace your middleman, if they match the intended recipient, you are fine.
If the secret message itself is a cipher however, it will be much more difficult to intercept it and understand it especially if it looks to be unimportant
There is another solution, which is to BE the messenger. If your data is so important that it requires this level of security, it should naturally be worth while to host your own server with your own messenging system and its own double lock feature. This would leave your ISP as the only one capable of accessing the information, which is basically as good as it's going to get as far as I understand.
This is where services like matrix come in play
Another way is to have Bob send his unlocked padlock to Alice, and vice versa. Then Alice attaches Bob's lock on the message, so now only Bob can unlock it. But this could still be vulnerable to a man-in-the-middle attack if Eve (the messenger) replaces Bob's lock with her own in the first step.
That is in principle public-private key cryptography. Bob has a stash of locks in front of his door (the public key) but only he has the key (the private key). Everyone who wants to send a message to bob can just take a lock, put their message in a box and lock it with bobs lock. After that only bob can unlock it. In this case you have the problem, that anyone could replace bobs locks (getting a forged public key from some untrusted source)
That's in principle where Certificate Autorities come into play. A trusted third party stamps an uncopyable (yeah realism...^^) logo containing "bobs locks" on all the locks. If you trust the third party you trust that these locks are really bobs locks. In the real world that is the cryptographic signature a CA does on a SSL Certificate
@@maukschilol In simple words it is impossible.
CA is that "trusted" messenger.
@@kairatkempirbaev7183 well not impossible. What you can do is meet personally and just give eachother a stack of locks. After that just sent eachother back some locks you received with each message you sent.
In the real world: just exchange your public key personally or compare their fingerprints over a trusted channel (which for this case with the needed trusted channel just pushes the problem down the road ;D)
This way you can be sure that the keys you sent eachother have not been tampered with. Problem is, that it is just not practical to do a personal key exchange between every website and user. That's why the pki infrastructure ist currently the "best" option we have
@@maukschilolEven if you try to exchange your public keys, someone can catch that transmission and insert their own key. How do you verify it was from who you think it is?
@@jaideepshekhar4621 that's why you have a fingerprint on a PGP public key. If you compare the long form fingerprint (the short form is not considered secure anymore) over a secure channel or an insecure where you can still have somewhat of an assurance that the other party is the one they say they are (like calling your friend) you can be reasonably sure that you got the correct public key.
In pgp theirs also the concept of web of trust where you trust a key that has a cryptographic signature from someone you trust ( read: my friend that I trust checked that the key belongs to that person and signed the third parties key with his own )
And with SSL this role is somewhat taken by the CAs. They sign a certificate to show "the owner of that certificate was checked according to our guidelines"
Make a lock that requires two keys, send your public key with the box and the receiver can open it using both the public key you gave them and the private key they own. (OpenPGP)
Love the video, great brain teaser. Will spend the rest of my day thinking up an alternative method; who knows maybe one of us can figure out how to get the chicken, feed and fox over the bridge.
I'm gonna use the phrase "cut out the middle man", because you could just give your friend the job of the messenger and let them have the message!
Both can share some secret keys before hand Right?
No, that actually is what makes this such a tough problem.
Rohit is actually correct here, despite what Pedro said. If the two neighbors DID have some secure way/channel of exchanging a symmetric key (think: two copies of a key to a lock) in the past (say, they were having a dinner party), then I think some of these problems would be ameliorated.
I think you could draw an analogy here to how we might use asymmetric/public key encryption to establish a symmetric key encrypted channel. The problem is how to securely exchange this symmetric key.
@@420_gunna If there were a way to guarantee that you can use two different messengers that can’t communicate, perhaps you could send a key with one and the locked message with the other?
@@MorningPants Maybe that would work, I dunno! The thing with the public internet though is that (as far as I understand it) we don't have control over the routes that our packets take across the internet (where I think the route/hops that your packets take would be analagous to the identity of the messenger). That routing is determined (for "correct" nodes) by BGP, which I don't really have a strong understanding of.
@@420_gunnaYou completely misunderstood the problem.
Just pretending the problem isn't there is not a solution.
Eg. saying "they can just meet up sometime in the past, before they knew they wanted to communicate!"
If you want to communicate securely with someone in China, then "Oh, you should just fly to China first and give them a key!" is not really a solution.
Especially since you can't really go back in time and exchange keys, when you find out you need to communicate.
Like, if you want to order a thing from Amazon, having to drive to an Amazon warehouse and have "a dinner", so you can give them your address and credit card info securely later, kind of defeats much of the purpose of ordering online.
have 2 halves of a key:
(single lock, 2 passes)
Message passed with 1 half of the key (not enough to open the lock)
Client/receiving end w/2nd half of the key can now open the lock and read the message
Return the other half of the key - this makes it difficult for the man in the middle to copy only 1 half of the key, forcing them to try reconstructing it which takes longer
That would be redundant since you could then just say the neighbour has the key to your box.
The thing here is you can't communicate/give the right key to your neighbour to open the box.
nice video
I think others have already gave this idea, but what about a lock with a code you could tell through another medium of communication, that the messenger won't know about but your friend will.
You could message your friend saying: "the code is 4268" and they could input it when they receive it. Wouldn't that solve the problem?
A three man method would work as a counteraction for the man in the middle attack, you could get the messenger to put their own lock on the box and once the box gets to your neighbor they put their own lock on the box, this adds the messenger's lock into the equation making it monitored and the messenger would have to unlock it in order for the box to be opened on any side, this would only work in a situation where each man has 1 lock and key but adds more security to any outside attacks from any other prying eyes
You have to assume this is a constant process of sending and receiving.
Therefore the Messenger will see your 2 lock method and just keep copying locks until you believe it's safe to give the go ahead. At which time the messenger will just remove their locks.
@@GuitarSlayer136 I mentioned it only works if each person only has one lock in the original paragraph, which I assumed based off of the video only having three
Well we're not restricted to 1 form of communication so before we start encrypted communications we can just meet in person, tell what key we'll use for future communications and then use that key each time, however I do see how that would be a time consuming method for companies and a potential vulnerability as they would have to store those keys, so another method would certainly be needed
it's a metaphor for compute encryption but I guess
Using a side channel for pre-sharing a key is indeed a valid solution and potentially a good one although as you identified it has the drawback of being cumbersome. The side channel need not necessarily be a physical meeting however it just requires an independent communication channel (The side channel) so it could involve say sending a storage device with a physical key through the physical mail to protect future communications via the internet for example. This way the attacker would theoretically need to compromise multiple independent communication channels in order to intercept both the key and the message, and in reality there could be a plethora of options for which side channel will be chosen so the attacker would either need to identify the correct one or compromise all of them.
The briefcase can be secured with a combination lock or a padlock, and you can share the combination or key with your neighbor through a separate secure channel, such as a phone call, text message, or a secure messaging app.
To ensure the message's security, you should take precautions to ensure that the briefcase has not been tampered with during transit, such as using tamper-evident seals or installing tracking devices. You can also use techniques like steganography to hide the message within another file, such as an image or audio file, to further enhance its security.
Additionally, if there is a possibility of a third party intercepting the message during transit, you can use a technique called the "two-person rule." This involves splitting the message into two parts, encrypting each part separately
The video makes assume advanced tech is not used. You overcomplicating everything!
@@robotxavy2132 its not overcomplicated lmao😂
1. lock the box ( YOURS ) neighbor has box
2. hand a key (yours) neighbor now has your key, ur box
3. boom
There really are infinite ways to do this.
One way is to have the message itself encrypted in a code that has been discussed with the receiver before hand so that even if they bypass the locks, the message itself is encoded.
Following this first meet to decide in person idea, you can communicate what lock will be attached to the box. So once they receive the box they can analyze the coded box before attaching their lock.
But to ensure that a message is locked without using any pre determined meeting is significantly harder.
You could try sending the message in bits through proxies who will deliver the message to the intended receiver it is a lot longer and bigger of an operation so any attempts to steal the message would take forever.
I’m not smart enough though to think of one that doesn’t use pre determined conditions but meeting up and deciding in person beforehand is the simplest and most likely safest route
This is about digital communication. While there are solutiobs such as "meeting up" irl, that can't really happen between two computers
There aren't any perfect solutions to this problem. An extremely good solution is the Diffie-Helman key exchange. Here's the tl;dr if the explanation is too long or the math is too complicated: it basically involves the good guys each having their own secret numbers and using them to create an extremely hard to solve math problem that is only easy if you have one of the two secret numbers. So they can each solve the problem and get the message easily while the malicious messenger would have to spend hundreds of years with the most powerful supercomputer to compute the message.
Imagine the key isn't a key that you turn, but rather a combination. You and your neighbor meet in person. You exchange a device which has a code on it. This device changes the code every minute based on a hardcoded function. You set the combination to the box based on the code on the device. When you give the box to the messenger, they are unaware of the device or the code behind it. Your neighbor receives the box. Your neighbor assumes 1 minute or less on transport and has to try a maximum of 2 combinations.
This won't work because those locks can always be brute forced. We have computers that can crack codes having millions of combinations, within seconds, and they aren't too expensive eithe. So then the combination lock fails
put a unique string of numbers on the lock during the three pass system, so there cannot be an impersonation lock
the string of numbers will be known only by sender and recipient via the contents of the box, assuming these messages are ongoing and you are each sending messages back and forth you can enclose the next expected string of numbers with the message
Plot twist your messenger is lockpicking lawyer
What if the messenger delivers first the locked box, then leaving the locked box with the neighbor, then he goes back to the first guy and gets the key, then he gives the key to the neighbor?!
Its a thought experient.......
The key stands for decryption code and lock stands for encryption...
The message will be doubly encrypted by the second pass and in the final it will be decrypted by the reciever...
If u rhink its quite clever way. Sending your encryption key is not safe and LEAVING the package is not digitally possible. Cryptography is fun delve deeper into its secrets!!!
the messenger could not deliver the locked box to the neighbour at all, and fake that he has delivered. if you want proof of signature/ evidence of delivery, that can be forged as well.
Seems easiest to establish security measure beforehand, such as hand delivering the key before sending messages. Of course, you'll always have the possibility of your lock being picked.
This is so genius
For the last bit... we'd basically need a way to secure the message against *the sender of* the message at that point. The authorized individual's the weakspot...
And what is one to do when the security weakness is also someone who NEEDS to be able to access the message? When the flaw is "the people using the system might mistakenly mislead the system about what has occurred"?
A computer does as you tell it to, not as you wish it to...
The lock is the public key to encripth, the key is the private one, that's represent a reversable encryption, on this way I can easily use the public key of the one I want to communicate, or I can insert a third party on this 3 phase protocol who can certificate the identity of the receiver
We could make the messenger deliver the (locked) message and then bring some proof that it has been delivered (like their sign or thumb print), then send the copy of the lock’s key, so that the message can be read by the neighbour and if there is the need the send a secret message then both people have the key
Dunno if it's possible but my approach would be:
The neighbour gives out instructions on how to create locks which fit with his own key.
As long as these instructions are in a place where they can't be manipulated by the messenger, you can create a lock which works with the neighbours key and lock the message with it.
Only your neighbour will be able to open the locked package afterwards.
In this example it could be like this: your neighbour has drawn the instructions on how to create such a lock on his house and you can see them using binoculars.
Thats sweet!
This video shows how much we need 'trust' in community. This is a topic where materialism breaks down, because the 'tpp', three-past-protocol has also been rebutted in comment section.
You can't really find a way besides 'trust'.
I'd be looking that angry too if I had to deliver the same message to the same people three times
I think that if you had some sort of signature, or ID verification on the lock, to ensure that it is the correct person recieving it, ie fingerprinting, or just a straight up signature, like the ones you have on the back of your cards, that are supposed to be there to verify that when you sign for your card, the vender can verify that it is that persons card, it would greatly increase the threshold of security and it would require a lot more skill to snatch the secrets.
I would use locks with little details to make sure it’s your neighbors‘ lock. You could carve something in or even use special paint that can’t be seen by the human eye.