Efika 5200B ProjectRemote Aid Deployment Systemin category Other
proposed by ronin on 2nd March 2006 (accepted on 20th March 2006)
posted by ronin on 15th October 2007
This blog needs more jokes :D. In that vein, I seriously doubt that a million monkeys on a million computers will create anything of value, maybe a bunch of destroyed computers or WinME :P
Anyway I have been continuing to write code the node server and considering the algorithms for traffic routing that i can employ. The biggest road block I have been having is how to set up the wireless adapter on the efika to start playing nice and work. As far as the hardware is concerned the efika is set up with a wireless card and a linux image (basically a cut down debian install) installed on a usb key. The image is nothing to be proud of as it is completely chaotic and many services that will be needed have not been even touched upon at all. When i can get the time I shall have to do or find a very cutdown version of linux that can fit within a 32MB or less footprint.
One of the issues that I have also been facing is interfaces, especially for the "hyper-nodes" that are designated to communicate between clusters of nodes (villages). These hyper-nodes would have two wireless interfaces most likely. One of these would be hooked up to a directional antenna pointed towards another hyper-node in another cluster and the other would be for the local cluster of nodes.
Moving onto the software side of the equation:
Encryption between nodes, this is a bit of a mystery to me as encryption will definately make the nodes enticing for corporations to employ in their businesses as a dirt cheap networking solution. The trade-off however is the computational overhead that is needed to encrypt transmissions between nodes. There are a number of approaches to encryption that can be taken:
1. Encrypt traffic between nodes. Each node only needs to know the encryption hashes for each connected nodes. The packets need to be decrypted and re-encrypted at each node.
2. Encrypt the data itself, but not the header. This guarantees end-to-end security as it is only seen unencrypted at either end point. The down-side to this is that the two nodes have to negotiate an encryption keyset to use, and this negotiation may happen over an unsecure link thus making the security of the following transactions void.
3. Use public key encryption. When a node recognises the network it requests the authentication public key (all nodes have this, but not the matching private key), which it then uses to encrypt its credentials. This packet is then routed to the master node in the cluster, which decodes the message, generates a private key for the new node and encrypts the resultant packet with a keyphrase provided by the new node in its authentication packet. This new packet is routed to the new node, which is now able to decrypt packets with its own private key.
All these methods ensure that nodes that are authenticated can decrypt packets, and unauthenticated nodes can just function as routing nodes ignorant of the data being passed around.
I suppose I will need to create a proper document with all the specifics in it for interested parties.
Hopefully I will have some time to implement the designs and have someone test the code for me, because it is quite hard to test with only one device.