1994-08-09 - broadcast encryption

Header Data

From: hughes@ah.com (Eric Hughes)
To: cypherpunks@toad.com
Message Hash: f66cb5b8fb9e010268352cc26ac894b62e7b90baafbdb00fa754629389625a9a
Message ID: <9408091556.AA22438@ah.com>
Reply To: <aa6d46671a0210235f5f@DialupEudora>
UTC Datetime: 1994-08-09 16:24:58 UTC
Raw Date: Tue, 9 Aug 94 09:24:58 PDT

Raw message

From: hughes@ah.com (Eric Hughes)
Date: Tue, 9 Aug 94 09:24:58 PDT
To: cypherpunks@toad.com
Subject: broadcast encryption
In-Reply-To: <aa6d46671a0210235f5f@DialupEudora>
Message-ID: <9408091556.AA22438@ah.com>
MIME-Version: 1.0
Content-Type: text/plain


   What I would like to see is low-level digital signatures on the level of IP
   or AX.25.  IP is doable, I would think.  

What is the policy purpose for signing packets?  It will affect the
design.

Do you want to identify users, processes, or machines?

If you want to reject packets not signed or badly signed _before_
further processing, that's one way.  If you want to detect
interposition in a stream parallel to the use of that stream, that
would be another.  

Do you want each packet to carry an independent signature, or can
packets be aggregated for signature?  This is a separate problem,
since "aggregation" doesn't mean a delay, it means there is state
information carried which is involved in checking the signature.  This
question involves the abstraction level where authentication is taking
place.

Too often a particular situation is in mind and remains unspoken.
Making assumptions explicit is necessary for good design and useful
debate.

Eric





Thread