[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Square pegs in round holes
>Bob must find out whether Alice has declared (commited) her interest
>in him, if and only if he has declared (commited) his interest in her.
>Before he does so, he can at most know that a girl is interested in him.
>Another description: Bob and Alice can have a date if they both commit
>to each other. If only one commits, nobody will ever find out about it.
>- T is the trusted third party.
Well if we *must* use D-H that is a way, but why do that ? Instead of
using a binary assymetric key, why not a triple ? (Just because I do not
know of any does not mean that one does not exist).
Consider a function such that Alice has a key such that given a message M,
when encrypted by Alice may be manipulated by T such that Bob can decrypt
it. Similarly, Bob has a key that when manipulated by T' can be read by
Alice. Assymetric but not binary. The advantage here is that while "T"
is trusted by both, he/she/it/other is not able to read either message,
rather acts as a catalyst.
Such a mechanism could be as indicated or could be circular e.q. a cipher
such that A can generate a message readable by T who can generate a message
redable by B who can generate one readable by A. True you could do this with
three pairs of keys distributed alternatively so that a single person can
only write left and read right.
As to why you would want such a curiosity, consider a corporation with 80,000
mailboxes. It would be desirable for each person to be able to send E-Mail
to any other person but not desirable for each person to have to hold all
80,000 keys.
Given a triple (tertiary ?) function each individual would only need their
receive key and a "post office" transmit key. On sending a message, it would
be encrypted with a session key and the session key encrypted with the
post office key.
The post office would have all 80,000 receive functions but through the
assymetic keying would only be able to convert the session key to something
each intended recipient could decode but not be able to decode the message
itself.
This would meet both criteria (not key escrow but that is under "management")
D-H is wonderful but has difficulties with scalability. If such a function
existed (has anyone looked ?) it would solve the problem.
"The exercise is left to the student"
Warmly,
Padgett