From: snyderra@dunx1.ocs.drexel.edu (Bob Snyder)
To: cypherpunks@toad.com
Message Hash: e5873f356b856cf16055f60fcab2c6ab28c86cb98285cfc1fc2b4240523c94fc
Message ID: <aa6e54491b021023c7ab@DialupEudora>
Reply To: N/A
UTC Datetime: 1994-08-10 13:42:32 UTC
Raw Date: Wed, 10 Aug 94 06:42:32 PDT
From: snyderra@dunx1.ocs.drexel.edu (Bob Snyder)
Date: Wed, 10 Aug 94 06:42:32 PDT
To: cypherpunks@toad.com
Subject: Re: broadcast encryption
Message-ID: <aa6e54491b021023c7ab@DialupEudora>
MIME-Version: 1.0
Content-Type: text/plain
At 11:56 AM 8/9/94, Eric Hughes wrote:
>What is the policy purpose for signing packets? It will affect the
>design.
>
>Do you want to identify users, processes, or machines?
While I am a ham, I'm not directly on packet radio, so someone who spots
something incorrect please speak up. I'll probably be getting the needed
equipment within the month.
I would think machines would need to be identified. Every packet contains
a callsign within it, identifying the source of the packet. This is often
the only criteria BBSes on packet radio will discriminate callers. You can
change the callsign transmitted with a simple command to the TNC, and thus
easily forge messages.
Another situation this could solve would be the ability to log into a home
machine without compromising the security on it. Your password must go in
the clear, but if the packets are digitally signed, it would be difficult
for someone to log into your machine using a replay attack. I had
considered one of the challenge/response credit card devices out there, but
someone could still break in by waiting for the chalenege/response to take
place, and then send their own packets seemingly coming from the host that
answered the challenge/response.
I would say drop packets that are supposed to be coming from a signing
source that aren't signed or have a wrong signature. For example, the
local BBS would have listed that N2KGO uses signatures, and has a key on
file. Any packet destined for the BBS with my call with a abscent/bad
signature would be dropped. You need to keep the ability to respond to
unsigned packets, though, since not everyone will switch at the same time,
or switch at all.
>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.
This one is a toss-up. One of the main characteristics of packet radio is
its low bandwidth. A message digest on individual packets would probably
take up more space than a digest on an aggregate group of packets, because
the function should generate the same size digest either way. However, if
testing a group of packets, and the signature is wrong becuase of an error,
you now have many more packets to resend.
Bob
--
Bob Snyder N2KGO MIME, PGP, RIPEM mail accepted
snyderra@post.drexel.edu PGP & RIPEM keys on key servers
When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl.
Return to August 1994
Return to “snyderra@dunx1.ocs.drexel.edu (Bob Snyder)”
1994-08-10 (Wed, 10 Aug 94 06:42:32 PDT) - Re: broadcast encryption - snyderra@dunx1.ocs.drexel.edu (Bob Snyder)