3 ms·
The 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 lo
by Cogito 7y ago
The 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.