On Fri, Jul 25, 2003 at 08:20:41PM -0700, Ben Barrett wrote: > I was thinking that distributing a pre-configured locked-down bootable > CD, which turned any PC with supported wifi hardware into a node, and > assuming it can route to th internet, also a bridge. Maybe for those > who have existing wifi setups, it could allow any booted box on their > existing wifi to route the mesh traffic as well as whatever they > normally do. The mesh would offer some obivous benefits, once there are > enough nodes. Any number of services could be run locally, too, which > could tie in to, say the local economy movement. I don't understand the > OE, though (I'll do some reading later), but can you explain briefly if > every host wanting to join in must have the same key (single shared), or > if each host has its own...? Thanks ( =
All: long email, but worth the read if you've wondered about vpns, rsa, ssl/ssh [which uses rsa] or opportunistic encryption. Ben, There are three things going on here: 1) RSA public key cryptography. As I reviewed in my talk on vpns just before summer (where were you? ;) RSA works by each party having two keys, a public and a private. Everyone gives out their public keys and securely guards their private keys. A given key, when applied to the data encrypts it. However all of the keys are unidirectional. The key that encrypted the data cannot decrypt it. 'A' takes a piece of data and encrypts it with his private key, then he sends it to B. B uses A's public key to decrypt it. However A gave his public key to everyone so why bother? What we do know is that this message could have come only from A. This is digital signing. 'A' takes a piece of data and encrypts it with B's public key, then he sends it to B. 'C' captures it along the way, but can't do anything with it accept brute force it. Neither A's nor B's public keys nor any keys C has will decrypt this data. B alone, the only holder of his private key can decrypt the message. 2) VPNs are created by using the above technology to authenticate machines. Just because I have a vpn doesn't mean I want anyone to connect to my vpn. So I specifically enter in the public keys of machines that are allowed to connect. Each client has my public key. Pre-Shared Keys are not nearly as secure as RSA. A shared key is a password that both sides know, such as "This is a secret password." To have any security with PSK the clients need to have different passwords. This means a lot of passwords and a lot of setup and management. If they all have the same PSK, then if it gets out to an unauthorized user, the whole vpn is vulnerable and needs to be shut down and reconfigured (all servers and clients with the PSK). There is a great amount of difficulty however using different PSKs for each client, and allowing the clients to be road warriors (use different ip addresses). The PSK can't be sent over the wire, and it can't be encrypted because the encryption channels have not yet been established. So with an ambiguous key and an ambiguous ip address, the server has no way to determine which allowed client this is. Therefore with dynamic ips and more than one client, PSKs are not practical. With RSA the key is an identifier. It is safe to transfer the public key and so the server can obviously immediately identify the connection. 3) Opportunistic encryption is a variation of traditional roamer->lan vpns. 'A' wants to connect to B and finds a public key in B's reverse dns record. It says to B, hey I see you have a public key, let's talk in private. B does a reverse dns on A to get it's public key and they negotiate session encryption keys and create a dynamic secure tunnel to talk through. OE is using vpn technology to encrypt normal communications (smtp, http, etc) on the fly. It is Opportunistic. The only way your boot disk would work with OE for the wi-fi network is if you provided reverse dns services. All of the clients would need to be configured to use your dns server for lookups and reverse lookups. They would need to request a dhcp lease from your server as well. What you would probably want to do is have the cd create a set of RSA keys on boot up. It then requests a dhcp lease, which configures the dns settings. Next the client registers itself with the dns server saying, here is my public key. The dns server then creates a reverse map with the key in a TXT field. You may even be able to pass the key when requesting a dhcp lease (like as a hostname ;). Then with some hacks on the dhcp-dns package, you could have it automatically and securely update bind on the server, rather than having the client issue an update. Cory -- Cory Petkovsek Adapting Information Adaptable IT Consulting Technology to your (541) 914-8417 business [EMAIL PROTECTED] www.AdaptableIT.com _______________________________________________ EuG-LUG mailing list [EMAIL PROTECTED] http://mailman.efn.org/cgi-bin/listinfo/eug-lug
