Going to leave this here -- encrypting all networks

[ki4jgt]

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.

Edited April 16, 2018 by ki4jgt

[Dave-ee Jones]

Although, it definitely sounds interesting, but wouldn't it only be as secure as AES?

[Forkish]

AES = Always Exxtra Secure

[Dave-ee Jones]

5 hours ago, Spoonish said:

AES = Always Exxtra Secure

Always Ends Sadly.

Stupid cryptos. :(

Edited April 17, 2018 by Dave-ee Jones

[ki4jgt]

6 hours ago, Dave-ee Jones said:

Always Ends Sadly.

Stupid cryptos. :(

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.

Edited April 17, 2018 by ki4jgt

[ki4jgt]

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.

[Dave-ee Jones]

10 hours ago, ki4jgt said:

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.

I think you're missing the humour in my response there. 

10 hours ago, ki4jgt said:

-snip-

I'm not sure about all the extra details you haven't elaborated on, but could a hacker simply not spoof the hash response? Think of it this way - if you can see the traffic between 2 entities on a network, you can see everything about their security. You might only see a wall of characters, but it's still how they're communicating. If a hacker knew that the AES keys are sent only in the first 2 packets exchanged then he could reply with a similar packet, couldn't he? Another theory - couldn't he just record all of the packets they used, setup an enclosed network and assign similar IPv4/IPv6 address onto 2 machines on his enclosed network and then re-send each packet from the machines - just as they were talking before - to see the traffic "unencrypted"?

Also, if the AES encryption is only done at the start of a connection, why can't a hacker get in during a connection. There's no way of 1 PC knowing that the other PC has been spoofed by another, the first being disconnected or pushed out.

This is all theory and can probably be blown away with a simple answer, but there still things that I'm concerned about in my ignorance. :)

This sounds very similar to another security method I saw recently, too..

[ki4jgt]

17 hours ago, Dave-ee Jones said:

I'm not sure about all the extra details you haven't elaborated on, but could a hacker simply not spoof the hash response? Think of it this way - if you can see the traffic between 2 entities on a network, you can see everything about their security. You might only see a wall of characters, but it's still how they're communicating. If a hacker knew that the AES keys are sent only in the first 2 packets exchanged then he could reply with a similar packet, couldn't he?

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.

17 hours ago, Dave-ee Jones said:

Also, if the AES encryption is only done at the start of a connection, why can't a hacker get in during a connection. There's no way of 1 PC knowing that the other PC has been spoofed by another, the first being disconnected or pushed out.

 

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.

[Dave-ee Jones]

6 hours ago, ki4jgt said:

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.

That's more like it.

However, there's only 1 hash for each public key - so wouldn't it just mean a more public "public key", if you catch my drift? It basically means that the hash is the public key, the public key is a slightly-more-public private key, and the private key is a private key. :P

6 hours ago, ki4jgt said:

The AES encryption is done throughout the entire connection.

I would hope so. :)

[ki4jgt]

On 4/18/2018 at 6:21 PM, Dave-ee Jones said:

However, there's only 1 hash for each public key - so wouldn't it just mean a more public "public key", if you catch my drift? It basically means that the hash is the public key, the public key is a slightly-more-public private key, and the private key is a private key. :P

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.