Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!ucsd!ucbvax!PINOCCHIO.BERKELEY.EDU!bzs
From: bzs@PINOCCHIO.BERKELEY.EDU (Barry Shein)
Newsgroups: comp.society.futures
Subject: Digital Information Rights
Message-ID: <8811270029.AA05114@pinocchio.UUCP>
Date: 27 Nov 88 00:29:58 GMT
References: <7776@pasteur.Berkeley.EDU>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 75


From: agate!pasteur!ic.Berkeley.EDU!faustus@ucbvax.Berkeley.EDU  (Wayne A. Christopher)
>I've seen discussion on the topic of copyrights as they apply to digital
>information in a few places, and I'd like to know what newsgroup is most
>appropriate for this sort of topic.  In particular, I'm interested in what
>people think about how copyright laws must be modified to accomodate such
>things as software and digital images, and how to enforce such laws.
>Clearly, the current laws don't apply very well, and enforcement techniques
>such as copy-protection on disks are becoming increasingly ineffective.

USENET has a misc.legal list but if you're interested in speculative
changes in the copyright law to better support a digital inforamation
society I think you're on the right list already (INFO-FUTURES.)

The problem with legal issues, of course, is that people generally
don't understand them although they often have strong opinions anyhow,
usually representing what they wished the law said to better fit their
own moral sense.

That said (ahem!) I wonder if there *are* any folks on this list with
real legal training who might step forward as referees in such a
discussion and we'd all agree voluntarily to seriously consider their
referee'ing? If you like send me private e-mail and I'd be glad to
introduce you (it's so embarrassing to introduce oneself :-)

The idea of designated guest referees seems provocative, no?

>How about discussions of using public-key cryptography for identification?
>Why hasn't this become more widespread?  Is there really not that much of
>a need for reliable authentication?

Reliable authentication has certainly become a major issue of late
with this latest Internet "worm" and other similar problems. There is
a system from MIT's Project Athena called Kerebros which does this and
is publicly available. Authentication is, of course, only part of the
story. As we all (should) know data passes on networks right now in
the clear so anyone with the ability to eavesdrop can own the store.

The current issue seems to be the performance trade-off of encrypting
every packet (and the administrative issues of managing the encryption
strategy.) Let's try some quick numbers:

Assume a desired host-to-host throughput rate of 100KBytes/second and
a 512 byte packet (although hosts are capable of transferring more
quickly right now the limitations of their target devices such as
disks or screens tends to throttle things.)

That's 200 packets per second or 5 milliseconds to encrypt and
anything else you need to do, let's say 3 ms to encrypt.

On a 2 MIPS workstation that's time for about 6,000 machine
instructions. Assuming you can encrypt four bytes (one 32 bit word) at
a time and loop 128 (512/4) times to encrypt, the loop has to be
somewhat less than 50 machine instructions long, including loop and
pointer overhead, to keep up.

Anyone know a good encryption algorithm that can be implemented in
less than 50 machine instructions? The only one I know of uses a large
table of random values copied at each site which are kept in sync,
each word is (eg) XOR'd with the next random value. That's only low
security (although a lot more secure than cleartext) and of course the
tables getting out of sync is a definite problem as well as
guaranteeing the security of the tables.

I know, buy a faster machine :-) The fastest *software* DES
implementation I know of runs significantly less than 100 encrypted
words/second on a 2 MIPS machine, more than 2 orders of magnitude too
slowly for packet encryption in real time.

There are chip implementations of DES etc which might help although
I'm not sure how well suited they are to general public key methods
(perhaps someone else knows more and can even talk about it) or if
they're that much faster.

	-Barry Shein, ||Encore||