1995-10-25 - RE: Don’t Kill the Messenger–A New Slan

Header Data

From: agermain@cmp.com (Germain Arthur)
To: sjb@universe.digex.net (Scott Brickner)
Message Hash: 2067ff73efd71350e6b2cb43145706899c6d5d63f55792ecb7d0049d9f8ebc2d
Message ID: <1995Oct25.093456.1151.341104@smtpgate.cmp.com>
Reply To: N/A
UTC Datetime: 1995-10-25 13:35:50 UTC
Raw Date: Wed, 25 Oct 95 06:35:50 PDT

Raw message

From: agermain@cmp.com (Germain Arthur)
Date: Wed, 25 Oct 95 06:35:50 PDT
To: sjb@universe.digex.net (Scott Brickner)
Subject: RE: Don't Kill the Messenger--A New Slan
Message-ID: <1995Oct25.093456.1151.341104@smtpgate.cmp.com>
MIME-Version: 1.0
Content-Type: text/plain



I have unsubscribed from this mailing list. Please remove my name from   
your personal address lists. Thanks.

ahg3

 ----------
From:  Scott Brickner[SMTP:sjb@universe.digex.net]
Sent:  Tuesday, October 24, 1995 12:59 PM
To:  Adam Shostack
Cc:  Cypherpunks Mailing List
Subject:  Re: Don't Kill the Messenger--A New Slant on Remailers


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.







Thread