Originally posted by fearlessleader
the three send method seems to work, because there is no reason you can not have multipul encriptions on a message
It's not clear that there is an electronic analogy to the proposed
2-lock method.
Let M be the message, A be the first lock, B the second lock,
A' be the first key, and B' the second key.
So we start with M.
Lock it: A(M)
Lock it again: B(A(M))
Now ultimately we need B'(A'(B(A(M)))) = M
So, A'(B(A(M))) must equal B(M).
So when the sender gets the box back and goes to unlock it,
he needs a transformation A'(B(A(M))) that yields B(M).
I claim he cannot do this without knowing B. But if he
does know B, then B is not really a lock in the first place.
So I don't really see how this inter-tangling of locks is
can be implemented.
Obvioulsy multiple arbitrary encryptions can exist, but only only
when applied in a LIFO, layered manner. To do otherwise is
to expect deadlock.
Dr. Cribs
P.S. If you would refute this argument by saying that both
parties could share the knowledge of any of A, B, A', B', then
that violates by analogy the constraint that the parties may
not exchange keys or open locks.
P.P.S. In fact, if you do allow the sharing of information about
some of A, B, A', or B', then the above method is not only
feasible but essentially the same as public key encryption.
That is why I raised hell when rgoudie said you couldn't
share keys or open locks, becasue you need to share some
for the above method to work in the electronic realm.
(The sequence essentially becomes A'(B'(B(A(M)))) = M.
But because it is the first party who applies B', that is analogous
to sharing keys, which the problem prohibits but the real-world
solution requires.)