Crypto anarchy in a VW? (not the bug)

Has there been any discussion of anonimity / crypto anarchy in a virtual world
such as the ones described in _Snow Crash_ or _Neuromancer_? When the nets to
support these technologies come into place (and I have no doubt that they will),
perhaps a form of anonimity could be written into the architechture, instead of
having to add it on later as is the case now.... I would certainly be very 
interesting, especially with the work being done on creating alternate personas
(or avatars, whatever).

Also, a while back someone mentioned in passing buried cables.. this stirred up
an old idea I had about server anonimity, that is that the actual physical 
location of a server would be very difficult to pin down... the only way to do
this with any real degree of security would be to bounce signals off a satellite
but this would be rather costly...

Skye
--
-----====> Skye Merlin Poier <====----- 
Undergrad in CMPT/MATH (Virtual Reality)       ||||      ||||
          email: poier@sfu.ca                  p-OO <--> OO-q   THINK
   PGP Public Key available on finger           \==      ==/

Skye Merlin Poier writes:
[...]
> Also, a while back someone mentioned in passing buried cables.. this
> stirred up an old idea I had about server anonimity, that is that the
> actual physical location of a server would be very difficult to pin
> down... the only way to do this with any real degree of security would be
> to bounce signals off a satellite  but this would be rather costly...

Try this idea out:  several machines agree to "host" a server.  Each machine
runs a virtual-server process that communicates with the other
virtual-server programs.  These programs then combine to run the actual
server (a sort of shared virtual multi-processor).  The server itself _has
no physical existence_ and could operate as long as only one of the hosts
is able to spare it some CPU and memory slices.  The "server" would
basically consist of it's instruction packets being bounced around the net.

Secure crypto communication between the "processors" with some reflectors
scattered around the net to provide easy access points for those wanting to
use the services and you have a service that doesn;t really exist, at least
not as far as current legal definitions go...  :)

jim

On Mon, 31 May 1993, Skye Merlin Poier wrote:

> Has there been any discussion of anonimity / crypto anarchy in a virtual world
> such as the ones described in _Snow Crash_ or _Neuromancer_? When the nets to
> support these technologies come into place (and I have no doubt that they will),
> perhaps a form of anonimity could be written into the architechture, instead of
> having to add it on later as is the case now.... I would certainly be very 
> interesting, especially with the work being done on creating alternate personas
> (or avatars, whatever).

I am glad to see some consideration of possible hypothetical future scenarios
here; it is important to have an eye for the future of things.

I think that building privacy into the architecture would be inherently 
dangerous, however, it is a perfect way for the people building the system
to oppress the users, all the while convincing them that the system is 
secure.

Clipper is a perfect example of this, anonymity is supposedly being built into
the system with the Clipper chip.  The trouble, of course, being the inherent
INsecurity--but consider how much more dangerous it would be if the
insecurities were not even known, yet we were expected to rely on the fact
that 'privacy and anonymity are built into the architecture'?

No, this is the perfect beginning for a system where the populace is
monitored with the argument that "if you had nothing to hide, you would
not be going out of your way to hide it, besides, the system has INHERENT,
BUILT-IN SECURITY...."

The only way to ensure your privacy is to seize it yourself.

> Also, a while back someone mentioned in passing buried cables.. this stirred up
> an old idea I had about server anonimity, that is that the actual physical 
> location of a server would be very difficult to pin down... the only way to do
> this with any real degree of security would be to bounce signals off a satellite
> but this would be rather costly...

There are a lot of ways to get a signal around the world without using a 
satellite, ask any amateur radio enthusiast.  Besides, the more diverse the
signal transmission methods are, the more difficult the signals will be
to both trace and interfere with.

I have always been kind of fascinated with the idea of a truly decentralized
system, much like the internet is today, where each node had
responsibilities to connect to the nodes around it, but the actual
interconnection was entirely up to the nodes involved, so that there could
be no standard, homogenous method of tracing connections.  A pair of nodes
could be connected by direct connection, hidden wires, satellite
connection, voice grade wires, ionosphere bounce, lunar bounce, repeated
packets, lasers, microwaves, IR, whatever...  This would provide a tight
net that would be almost impossible to control with heavyhanded
regulations and oppression.

If each node on the net had a seperate public key and all traffic
between nodes was decrypted coming in and encrypted going out to the next
node, aspiring Big Brothers would have even more of a headache.

Why is there not more work being done on encrypting all internode traffic
streams?  It doesn't seem too hard.


An aside:  has anyone dealt with the concept of on-the-fly encryption for
mass storage, kind of like the way the PCs can be 'stacked' or 'doubled'
or whatever with on-the-fly compression?  I was thinking about trying to
write some drivers for this for a 486 but I have never tried to write a
device driver before and was wondering if anyone might have any suggestions.

I was thinking of something along the lines of:  your entire drive is
encrypted with your public key.  That way people can send you files and
deposit files and all of that jazz no problem.  When you boot up the
system each time it asks you to insert a floppy with your private key on
it.  You would keep this floppy on you as if it were an actual, physical
key. (perhaps in the future PCMIA cards or something more durable and
portable can be used)  It asks for your password to verify your key and
loads that key somewhere into memory.  It then uses they key for the rest
of the session to decrypt everything coming from the specified mass
storage devices and encrypt everything going to them transparantly.

This seems like a great idea to me, my two problems that I was hoping
someone might be able to help me with are:

    1) these public key algorithms that we are working on are slow as
balls, any idea if this would be feasable, given how PC users like to
equate hard drive speed with penis size?

    2) it seems that having your private key hanging around somewhere in
memory the whole session would be horribly insecure, and would make it
very easy for someone to walk up to a running PC and run some program that
would snatch it from memory (assuming something like this catches on and
there are some standard programs out there that poeple become familiar
with) so how could I protect the key from getting filched from a running
system aside from the standard 'password protect your screen saver' and
other insecure hacks like that?

> 
> Skye
> --
> -----====> Skye Merlin Poier <====----- 
> Undergrad in CMPT/MATH (Virtual Reality)       ||||      ||||
>           email: poier@sfu.ca                  p-OO <--> OO-q   THINK
>    PGP Public Key available on finger           \==      ==/
> 



Hugs and kisses,
    -Ryan
the Barcode Guy

>I think that building privacy into the architecture would be inherently 
>dangerous, however, it is a perfect way for the people building the system
>to oppress the users, all the while convincing them that the system is 
>secure.

We build the privacy into the system, not the government.  The
question is _who decides_?  If we decide by creating, then more
privacy will exist by fiat.

>The only way to ensure your privacy is to seize it yourself.

Absolutely.  This does not contradict our activity of building the
privacy into the system.  Any privacy system you can build on top of
an insecure network such as the internet can also be built on top of a
privacy-friendly network.

>There are a lot of ways to get a signal around the world without using a 
>satellite, ask any amateur radio enthusiast.  

One of the really great techniques I've hear about recently is a data
channel that runs at 90% T1 speed over the ~900 MHz spread spectrum
band.  The legal limit is 1W transmitter power and 4W antenna gain
(transmitted energy focusing).  From what I hear, though, the antenna
gain requirements are being ignored by lots of folks.  What this means
in practice is that you can set up a directional antenna and easily
get a twenty mile hop on one of these units.

>Why is there not more work being done on encrypting all internode traffic
>streams?  It doesn't seem too hard.

Cylink has had a T1 link encrypter out for years.  It uses D-H for key
exchange.  It's also costs (not-known-to-be-accurate) about 10K$ per
end.

Eric

Ryan Alan Porter <ryan@rtfm.mlb.fl.us> writes:
[...]
> An aside:  has anyone dealt with the concept of on-the-fly encryption for
> mass storage, kind of like the way the PCs can be 'stacked' or 'doubled'
> or whatever with on-the-fly compression?  I was thinking about trying to
> write some drivers for this for a 486 but I have never tried to write a
> device driver before and was wondering if anyone might have any suggestions.

Sort of.  I am still trying to work out a few design problems on a system
such as this for unix hosts.  At the moment it looks like I will be doing
this in linux but I still have a few issues to hammer out before I start
coding. 

>     1) these public key algorithms that we are working on are slow as
> balls, any idea if this would be feasable, given how PC users like to
> equate hard drive speed with penis size?

The PKE stuff would only need to handle the key management, so this could
conceivably be done in software.   The actual file encryption/decryption
must be done in hardware if you want to have any sort of speed at all.
This is actually the part I am still trying to figure out.  A research lab
in Switzerland designed a chip to do IDEA rather quickly, but I have still
not been able to get any information on how/when this might be marketed or
available outside the research lab (although I might be able to get one for
research purposes...)  Lacking an available IDEA chip I will have to use
DES (multi-pass or some other variant to get around the limits on DES
keyspace) in order to get the necessary throughput on the disk.

>     2) it seems that having your private key hanging around somewhere in
> memory the whole session would be horribly insecure, [...]

This I why I am hoping to use linux.  For those who don't know what linux
is, it is a fairly popular free unix for 386/486 intel machines.  With
linux I can start by burying the private key in the kernel during runtime
to give it some protection against snooping and hope to add a few kernel
hacks to make it a little more secure against examination.  Linux provides
a dos emulator for those who need PC programs and unix/x11/whatever for the
rest of us...

Such a system would not be completely secure but would provide some
protection for files, which is more than they get now...

jim

>   The actual file encryption/decryption
>must be done in hardware if you want to have any sort of speed at all.

Please, everyone who is working on this, remember.  You can't do hard
disk encryption in software on the host CPU.  Thanks to Jim for
reminding me to stress this.

>Lacking an available IDEA chip I will have to use
>DES (multi-pass or some other variant to get around the limits on DES
>keyspace) in order to get the necessary throughput on the disk.

DES hardware is already available and tested.  Use it.  Use a
triple-keyed EDE version of DES.  

Is someone selling a raw DES chip on an ISA card?  If so, use that so
that others don't have to hack together their own hardware.

>Such a system would not be completely secure but would provide some
>protection for files, which is more than they get now...

The keying material for the disk should not be one key for the whole
disk.  The keying material could easily be one key per track without
the keys growing too large.

Ideally this keying material would be held on a removable PCMCIA card
and would talk directly to the device encryptor hardware with a
protected channel.  That will have to wait.

Eric

Eric Hughes <hughes@soda.berkeley.edu> writes:
[...]
> 
> >Such a system would not be completely secure but would provide some
> >protection for files, which is more than they get now...
> 
> The keying material for the disk should not be one key for the whole
> disk.  The keying material could easily be one key per track without
> the keys growing too large.

Actually I was sort of thinking of the keying being done on a per-user
basis.  The user would supply a key (with the pub key kept online and the
private part stored in kernel memory during the user session) that would be
used for thier files and the system key would only be used to provide a
secure channel between the user and the system (user encrypts thier key
pair with the system key and transmits it).  I have several ideas on how to
close up some of the holes on the OS side, but at the moment I am trying to
concentrate on finishing up the details of just the filesystem side so I
can get coding.

Right now I am working on making the system provide security such that the
only way to get at a file is to either have the legitimate user's private
key or to have the system private key and run the system as a sort of
trojan horse collecting keys as users login.  Having the system private key
will not give you any sort of "replay" data (you will not be able to use
the system key to get any past user keys or much of anything else...) and
having the physical hardware without the system private key will give you
nothing at all.

jim

I argue that encrypted hard disks should be encrypted at the transfer
level.

>Actually I was sort of thinking of the keying being done on a per-user
>basis.  

Never fear.  Layered encryption is the way of the future.  One layer
of encryption for the disk as a whole, another for the users.  When
the stuff gets cheap enough, it will be everywhere.

The question is "Who is your opponent?"  If you are concerned with the
users against each other, then use user level encryption.  If you are
concerned with the outside world against the machine, then encrypt at
the disk controller or device driver level.  If you are concerned
about both, then do both.

Eric

On Tue, 1 Jun 1993, Eric Hughes wrote:

> >   The actual file encryption/decryption
> >must be done in hardware if you want to have any sort of speed at all.
>
> Please, everyone who is working on this, remember.  You can't do hard
> disk encryption in software on the host CPU.  Thanks to Jim for
> reminding me to stress this.

Well thanks for the advice, but you fergot to mention why...

> >Lacking an available IDEA chip I will have to use
> >DES (multi-pass or some other variant to get around the limits on DES
> >keyspace) in order to get the necessary throughput on the disk.
>
> DES hardware is already available and tested.  Use it.  Use a
> triple-keyed EDE version of DES. 
>
> Is someone selling a raw DES chip on an ISA card?  If so, use that so
> that others don't have to hack together their own hardware.

I would be very interested in a card like this, if anyone can find one.

> >Such a system would not be completely secure but would provide some
> >protection for files, which is more than they get now...
>
> The keying material for the disk should not be one key for the whole
> disk.  The keying material could easily be one key per track without
> the keys growing too large.
>
> Ideally this keying material would be held on a removable PCMCIA card
> and would talk directly to the device encryptor hardware with a
> protected channel.  That will have to wait.

Another possibility until then, and one that would be fun for people who
like to play with EPROMS, is a card that had a cable leading to an external
EPROM socket that you could lay on your desk or on top of the case or 
wherever.  You burn your keys for the HD into a chip and use it as a key,
physically inserting the chip in the socket each time.  There are lots 
on new ways to make chips easy to plug in and out, I'm sure it wouldn't 
be too hard.

I still don't see why all of the actual encryption couldn't be done in 
software though...

> Eric


-Ryan
the Bit Wallah

>>  You can't do hard
>> disk encryption in software on the host CPU.  

>Well thanks for the advice, but you fergot to mention why...

Performance.  Look at how long it take to do encryption via software
and how long by hardware.  Consider that a Unix box can do other
processor tasks while the disk is stepping.

Re: EPROM as key

A fragile device makes privacy for hackers only.  General privacy will
require something significantly more physically robust.

Eric

>this
>stirred up an old idea I had about server anonimity, that is that the
>actual physical location of a server would be very difficult to pin
>down... 

This presumes a model where the logical server is a single machine.
That doesn't have to be the case.  By using a secret sharing protocol
(M out of N reconstruction), one can multiply site any database, with
sites anywhere in the world.  A database then is in actuality not in
any single place.

>the only way to do this with any real degree of security
>would be to bounce signals off a satellite but this would be rather
>costly...

Cryptography is all economics.  If you are doing something where the
location of a machine must not be revealed, then you've got the money
to pay for a satellite link.  High security means high expense, and
there is no way around that.

Eric