ki4jgt

Well, CJDNS actually uses the public key but I figured that with the onset of non-binary computers, the processing power needed to break such a small key would significantly decrease. So, I went for a longer key 4096-8192, with a reference hash to the key in question.

There would need to be some time contingent information involved but generating a key which matched the hash exactly would prove complicated as CJDNS uses an actual asymmetric key as their IPv6 address for their users. They don't even use hashes. To generate an exact hash for an onion address in the TOR network takes eons. All onion addresses are simply hashes of the public keys of their hosts. So you can spoof the hash, just can't prove you're the owner of the hash without the private and public keys. The keys would then need to use time-coded data to exchange the AES keys. If the time in the data is out of date, the receiver knows the packet is not valid. The AES keys should be randomly generated by the software, so the hacker doesn't know if they've broken the key or not and should be different for each connection from your machine. The AES encryption is done throughout the entire connection. There is no part of the conversation which doesn't have AES encryption besides the AES key exchange which is in RSA. RSA public key matches the IP address because the IP address is a hash of the RSA key. The RSA key is public so it doesn't matter if anyone has it. The only person who can create messages that the public key can read is the private key holder.

Going to elaborate a bit: This is all over an unsecured network (so Alice and Bob both have IP addresses -- let's say in the IPv4 spectrum for local wifi with an open network). Alice wants to talk to Bob and each of them have the networking software (virtual networking device) installed. The virtual device works by creating an IPv6 address for its client (so they both have one). The IPv6 is a hash of each client's public key. Let's say Alice's public key hash was 00:11:22:33:44:55:66 And Bob's was 77:88:99:10:11:12 Alice's virtual interface would broadcast a message over the IPv4 network asking for 77:88:99:10:11:12's public key (since the IP is a hash, the key must match and since Bob is the only one with the private key to match the hash, he's the only one who can communicate. Once Bob's interface sends Alice's interface his private key -- in response to the broadcast -- the interfaces can exchange AES keys and then communicate. The communications can't be hijacked at any point, just stopped.

I was under the impression that SSL handed off to aes after RSA. That's been the standard for years. Once you've exchange your encryption key you exchange an aes key and then have communications from there because AES doesn't take as much processing power as RSA. AES is pretty secure mate. In fact, that's what a lot of encryption systems do, even whole hard drive encryption. It stores the AES key in an asymmetric encryption then uses the key to decrypt AES -- again to spare the processor the heavy burden of using public key cryptography for everything as it is very resource intensive.

So, I've been bored and when I get bored, I come up with awkward ideas out of the box. I'm wanting to develop a networking software which encrypts the connections of the devices on any network which has the software installed. The general idea would be to generate an IP from a hash of a public key. This IP would be assigned to a virtual networking device which communicated via whatever networks were available to the user. Skipping the whole DHCP server bit, a newly joining PC could thus get the IP of a computer by broadcasting a request for that specific IP's public key and IP. The key would verify the IP. and have no need for a DHCP. Then they could exchange AES encryption keys and communicate. By doing this, any computer on the network that had the software, would have a secure channel of communication over the network, even if it were a wide-open network. This could also come standard in Linux and thus the end-user would have no need to perform special tasks. I don't have the time to work on this myself and I was wondering where I could put the idea to get people interested.

So, I've created bulletin software that can be used in any neighborhood. Essentially it just has to be run on an ad hoc network with OLSR protocal prefered. It's a server that can take addons and modifications. It's only going to get better though. You can find the project here: http://buckysroom.com/page.php?pid=78