From: Nickey MacDonald <i6t4@jupiter.sun.csd.unb.ca>
Date: Sat, 8 May 93 03:56:15 PDT
To: cypherpunks list <cypherpunks@toad.com>
Subject: A few different topics
Message-ID: <Pine.3.05.9305080722.A17896-c100000@jupiter>
MIME-Version: 1.0
Content-Type: text/plain


I have a couple of different things I want to talk about, so I'll make one
large post rather than several smaller ones.


I posted a link encryption post a while back, and one of the responses I
got back implied I was very naive in using a "shuffle" as part of the
initial manipulation of the packet to be sent.  I have spent some further
time thinking about this, and I still fail to see how reshuffling the order
of the data is anything but a good thing.

If the encryption algorithm generates one output character for each input
character, then I can see a situation developing where an "interloper"
could cause the message being sent to be changed:

   sender  --->  interloper  --->  receiver
                  ^
                  Knows senders password, but sender
                  is unaware.  Changes sent message
                  without senders knowledge.

Now this situation is a possibility any time a store and forward (such as
email) situation exists and someone (other than the sender and receiver as
appropriate) knows the password(s).  This could still be a problem in a
real time link, unless the data is sent in a nonlinear (shuffled) order. 
The implication is, that if the data has to be rearranged to be
understood, then the interloper is going to have to gather more than one
packet, and rearrange them to understand whats being sent, in order to be
able to know what changes to make to the message to make it have an altered
meaning for the receiver.  Collecting the packets would cause a delay that
would (should) be noticeable on a real time link.

I still don't like the idea of trying to use timing as the only control,
given the modern communications can be filled with arbitrary delays, but I
don't know of any other approach that will offer any hope of detecting
that someone knows your password.


This is probably another problem that would be solved by a "more powerful
mailer", but not having one on hand I do not know this to be the case:
I have a second thought about the subject handling of posts to this (and
other) email lists.  In my Bitnet days, I used to be on a number of
Listserv lists.  One of things I liked about them was that the messages
always showed up as being from the list.  The email I get now, all appears
to be a collection of private mail from a collection of individual people... 
The problem occurs when someone replys privately to one of my posts.  It is
impossible for me to tell which mail is sent directly to me, and which mail
has been redirected by the list.


I am about to start "spec"ing a software licensing system using public key
technology.  I would like any comments...  this is not something I have
seen discussed on the list in the short time I've been subscribed.  What I
propose is that the software would require (say in an environment
variable or a special file some where) an "activation key".  The
activation key would be some licensing data that was encrypted with a
private key by the software manufacturer (say a serial number, licensee's
name, and a license duration (or expiry date)).  The software would have
the public key compiled into it, and only if it could decode the
activation key, and it had not expired, would the software run.


The majority response on "should I try my survey" was positive (in fact I
only got one "count me out").  I was warned that it may end up meaningless
because everyone will submit anonymous responses...  I don't see where
that will be a problem, unless someone submits multiple responses or
unless hiding behind anonymity means someone still feels inclined to be
untruthful.  I guess maybe I'm just being foolish by assuming that
allowing anonymous posts would make people feel more secure in telling the
truth about themselves...  In any case, I will start collecting my
thoughts and form some questions...

---
Nick MacDonald               | NMD on IRC
i6t4@jupiter.sun.csd.unb.ca  | PGP 2.1 Public key available via finger