Best way to send cryptography keys?

Hey guys,

So, I've been thinking of an algorithm to encrypt data suitable for Rednet transmission.
(Just a few randomly generated byte-wide numbers to do some bit-wise operations with)
The question I keep coming back to is : how do I let the receiver know what the crypto key is,
since I don't have an encrypted connection to send it on?

I'm assuming the worst conditions - a packet sniffer on every channel that knows the cryptography protocol.
The only thing that this sniffer does not know (obivously) are the keys generated to encrypt with.
It knows how the encryption/decryption process works, but doesn't simply brute-force for keys.
It even theoretically knows how I'm sending my crypto keys over to the receiver.

Any suggestions? I've been thinking about this in my spare time for a day or two now,
and it's driving me nuts that I don't have a solution.

(Note : Not opposed to using an established protocol, but this is also for learning experience, not just for cryptography for security's sake.)

~Sora

To repeat a quote that I read on some website at some point in time,

There is no such thing as an "unhackable" security system. Provided enough time, effort, and skill, no security measure that you take could ever be enough

Or something along those lines.

But my point is that you seem to be looking for a completely safe way to transfer a key over wireless rednet. There is none now. You could do it fairly safely using physical measures such as disk drives/turtles and the like, but rednet is completely vulnerable. Of course you are also making some rather large assumptions about the sniffing software, considering that a unique cryptography program would be pretty damn near impossible to break for the average ComputerCraft user.

If you have HTTP enabled on the server however, you can be a bit more creative. Have a webpage which generates a new key after two requests for a key (I have never done this, but I do know that it is possible) and you have yourself a secure way of insuring that only you have the key. That is of course assuming that your computers are the first visitors to the site, but it would be fairly simple to verify that.

Alternatively you can wait for LANs or use one that is already in existence ;)/>

Well there is no way to send a key across a secure connection, because how would they read that key? what key would you use to send the key? then what key would you use to send THAT key across a secure connection……………… (recursive) so at some point the key would need to just be sent plaintext.

Now one thing you could do is have a key based on a formula, this ensures all the computers have the key without sending it in plaintext, obviously if they have the formula they can have the key too, but this is a problem that cannot be avoided. There is no solution without its floors even a LAN connection has downfalls. Also as Bubba said you could have something based on HTTP, but again if they have the web address, its not 100% secure.

Now some useful reading could be on Cryptography in modern computing. Now obviously there are more methods to which computers work, but the common two, which are detailed in that first link, are Symmetric-key algorithm and Asymmetric algorithm, which if you can get working in CC would be nice, however probably would require some advanced knowledge (not saying you don't have it, just saying you would need it) … sorry if those links are too hard to understand.

I see the point you are trying to make. I'd rather have a safer way than simply transmitting the keys unencrypted over the channel, even if that wasn't hack-proof in itself…

I dunno. For now, primary usage of the cryptography would be on my private server. I'm the only person in our group that even HAS computers, let alone actually using them to such extents. Our group isn't the most technical around. :)/>
Again, here and now, this is mostly for learning and getting experience for when it 'matters.'

I would like to see eventually me using this crypto in other places, but I don't play anywhere but my servercurrently…
Ah well. I guess it was kinda fun to see if I could do it. Chalk this one up to learning about security. :)/>

EDIT: BIT, you ninja'd me. I've already come to the recursive catch-22 key problem. I see there isn't way to encrypt it to send, obviously. I'll take a look at those links.

Thanks,
~Sora

Another thing you could do is have half the key sent on one channel, some sort of formula applied to that to change the channel, and get the other half of the key on that channel, combine the 2 and there you have it. your key. again, still has flaws. but it means that if they don't have the formula they only have half the key.

That sounds as if it would work. The key has been separated, and even though the sniffers on those ports KNOW that they both have a portion of the key (in reality, a portion of one of four keys), it would still take too much time to piece the key back together, or brute-force the encryption based on the key portions.

Thanks! I'll give that a shot.

~Sora

Diffie-Hellman key exchange?
Might be too hard to implement in CC because of the large numbers involved - you wouldn't be able to process them as normal numbers, you'd need to encode them in tables or something.

You can also make it so that a substantial part of the key is contained in the copies of your de/coding program, set to rotate according to a world-time based schedule. That way the sniffers would have to have a copy of the current version of the de/coding program as well as the transmitted keys.