1992-10-05 - Secure IRC

Header Data

From: Eric Hughes <hughes@soda.berkeley.edu>
To: cypherpunks@toad.com
Message Hash: 920f54397de592454fa688f71146bf88ca608b796b00fcf8cce1760b83938f5e
Message ID: <9210050206.AA20902@soda.berkeley.edu>
Reply To: <9210012143.AA00610@atdt.org>
UTC Datetime: 1992-10-05 01:59:32 UTC
Raw Date: Sun, 4 Oct 92 18:59:32 PDT

Raw message

From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Sun, 4 Oct 92 18:59:32 PDT
To: cypherpunks@toad.com
Subject: Secure IRC
In-Reply-To: <9210012143.AA00610@atdt.org>
Message-ID: <9210050206.AA20902@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



The problem with central servers is that they are prone to single
point failure.  That failure may be computer down or key compromise.
A good criterion for this kind of design is not to use central
servers.  This is almost always possible.  (Or always possible,
depending on who you ask.)

There is also the question about getting permission to enter a room,
which corresponds to an authentication or a key distribution or a
voting algorithm or some sort.  You need to know how you want that
_social_ interaction to work before you design protocols.  You should
implement that sociality and test it without encryption to make sure
it's what you want.  Is this sounding familiar?

Eric





Thread