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
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
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
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
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
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
participants (4)
-
Eric Hughes -
Jim McCoy -
poier＠sfu.ca -
RYAN Alan Porter