From: Scott Brickner <sjb@universe.digex.net>
To: Adam Shostack <adam@lighthouse.homeport.org>
Message Hash: 499eb8d5d587ace366b2aa0132a7748bbc1c80cd7abac453003b0cd1ce4d4540
Message ID: <199510241759.NAA01689@universe.digex.net>
Reply To: <199510241203.IAA22014@homeport.org>
UTC Datetime: 1995-10-24 17:59:53 UTC
Raw Date: Tue, 24 Oct 95 10:59:53 PDT
From: Scott Brickner <sjb@universe.digex.net>
Date: Tue, 24 Oct 95 10:59:53 PDT
To: Adam Shostack <adam@lighthouse.homeport.org>
Subject: Re: Don't Kill the Messenger--A New Slant on Remailers
In-Reply-To: <199510241203.IAA22014@homeport.org>
Message-ID: <199510241759.NAA01689@universe.digex.net>
MIME-Version: 1.0
Content-Type: text/plain
Adam Shostack writes:
> Who cares if you can read messages encrypted to the key or
>not? Let everyone connect and download whatever messages they want to
>see. They're encrypted, after all.
Two reasons. One, it cuts down on traffic. Why bother to waste the
server's bandwidth on something the client can't read anyway. The only
possible reason someone could be asking for the data is because they're
trying to compromise the key or do traffic analysis. Why help bad
guys?
Second, there's no reason the messages need to be encrypted. The
server can accept messages addressed to *any* string of eight hex
digits, and doesn't care about the content. The server needn't limit
the kinds of encryption used in the actual message. It only cares that
the recipient is "really" (in some sense) the right reciever.
The original mental prompt for the idea came from the discussion of
the "key-is-the-person" model. I was trying to devise a scenario where
it was possible to know of an entity only through his key, and came up
with this. I also included the idea that messages signed by the key
would be forwarded by the server after being pseudonymized to the
keyid. That way, the user could participate in mailing lists purely
identified by the key.
Return to October 1995
Return to “tcmay@got.net (Timothy C. May)”