4 ms·
This scheme sounds (unsurprisingly) similar to a well known crypto scenario. Here is a page that describes it[0]. Copying from there: You and I need to communi
by Cogito 7y ago
This scheme sounds (unsurprisingly) similar to a well known crypto scenario. Here is a page that describes it[0]. Copying from there:
You and I need to communicate via the National Postal Service. What you want to communicate is secret, so you don't want a postal worker or some random schmoe who finds your mail in the mailbox or a package on your stoop to be able to open it up and read what's inside, and you know from experience that any time you send something in the mail without securing it, it either gets read or (if it's not just text) stolen. We must live in a country with a really corrupt postal service, I guess -- kind of like the Internet.
We each have access to an arbitrary number of indestructible boxes, and an arbitrary number of indestructable key locks. Each box can have as many locks on it as you like. Unfortunately, each lock has only one key, and only the person who possesses the lock has the key. We can send things to each other in locked boxes, but of course the recipient doesn't have the key to the lock because the sender has it. Sending the key unsecured will get it stolen or, worse, copied. We also have no way to meet each other in person to exchange keys securely (and if we did, we could just skip the postal service altogether, anyway).
How can we arrange, with these resources, to communicate securely with each other?
[0] https://www.techrepublic.com/blog/it-security/the-key-exchange-puzzle-test-your-cryptographic-skills/ https://www.techrepublic.com/blog/it-security/the-key-exchan...
- zaroth 7y agoIt’s actually fundamentally different, because instead of trying to agree on a key we can use to securely communicate cleartext over a hostile network, this is a scenario where neither side wants to know anything about what the other side knows, except in the very special case where we both have the same exact value, in which case only one side should discover that.
- Cogito 7y agoThe solution to the scenario is (spoiler alert) to attach multiple locks. Alice attaches her lock. Alice sends the locked package to Bob. Bob attaches his lock. Bob sends the twice locked package to Alice. Alice removes her lock. Alice sends the package, locked with only Bob's lock, to Bob. Bob removes his lock and opens the package. ---- The scheme you discussed is really similar to this, but I guess with one key difference; in the scheme you describe the locks themselves contain information and are hidden by a second lock. I don't think there is a good extension to the solution I posted above, but it's as if when Bob attaches his lock it is hidden until Alice removes her lock, and at that point Alice only cares about what Bob's lock looks like.
- tommica 7y agoWhat is stopping me doing a MITM on that, especially when it's digital - couldn't I copy the locked package that Alice sent, forward the original to Bob, and then when Bob sends his locked copy, I use my copy and attach my OWN lock to it, and send that instead to Alice, who then removes her lock from it, leaving only a package that is locked with my lock?
- Cogito 7y agoSure, you need a way to verify that the package has been locked by who you thought you were sending it to. Your attack would work by removing Bob completely, you just play his part in the protocol. This is true for any protocol though. If you don't know who you're talking to then you could be talking to anyone. In practice most protocols get around this by either pre-sharing a private key, or using a public/private key pair with a challenge round to establish identities.