Square pegs in round holes

[A. Padgett Peterson P.E. Information Security]

  >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