Thoughts on Encryption and Encoding

in security •  8 years ago 

Here are the basic ideas that we all know and love/hate (according to whether you belong to any three letter agency). A function can be symmetric (ie: applying it again reverses it), or it can be asymmetric (there is a different function that reverses it), or it can be many-to-one (ie: there are an infinite number of starting points that produce a single end point). A hash function will utilize something that's basically many-to-one but mangle it up so that the infinite set of valid reversals is an infinitesimal fraction of the much larger infinite set of invalid reversals. If you could just run the maths in reverse and pick any of the outputs generated, it wouldn't be much of a hash.

These are all examples of transforms. A transform takes some data varying in one domain and turns it into some data varying in another domain. When you encode sound files, you're doing the same thing. The difference with encoding something like sound is that you're turning difficult information into easy information. Encryption is about turning easy information into difficult information.

However, they're all basically the same thing. Huffman Encoding for data compression is not fundamentally different from Fourier Analysis, a Laplace Transform, TripleDES encryption or RSA public key encryption. It's just a way of changing the way the data - the same data - is represented.

That's all fine and good, people have understood transforms for a while, so is there any point to this?

Yes.

First, there is no reason why an asymmetric cypher should require two steps to complete. This is important. There is a lot of nervousness over on sci.crypt when anyone talks of encrypting compressed data or encrypting encrypted data, as there is a risk that you can undo some of the value of the encryption.

So you design a cryptographic system specifically to be multi-stage. Stage one compresses the payload. Stage two is some TLS substitute for securely connecting two applications. Stage three is your encrypted tunnel. All three stages can be folded into a single encryption stage, if you like, you you could plug the whole lot onto an ASIC on the network card. There is no reason to have them separated out.

Why would you want to separate them out? Well, your router might handle the tunneling better than your server, so you can farm out that part of the work. If the middle layer is symmetric, the outer layer can create a secure multicast channel. You can now multicast to subscribers using an efficient symmetric cypher, with none of the security risk implied because the channel itself is asymmetrically encrypted on a router-to-router basis.

Does this matter?

Well, yes it does. Both American presidential candidates are opposed to strong encryption. With scalable, reliable, encrypted multicast, there ceases to be any method of linking a specific transmission with a specific transmitter or specific receivers.

Doesn't TOR do this?

TOR doesn't do multicast, it doesn't really encrypt (applications are free to use whatever protocol they like), it hides specific paths and details to make the sender invisible. TOR is also often between hosts.

I am still working on the specific details, but I think it would be possible to end up with a lightweight core module that can route traffic reliably between multipoint systems securely in such a way that an outsider could not definitively pin a particular sent packet with a particular sender or receiver. In these days of increasing industrial cybercrime, corporations aren't going to disregard the possibilities.

If the same system can be used to augment TOR and have it as a plug-in for your router (you still use TOR on your home machine, but the pluggable TOR can spend time listening to SDRs and building up IPSec tunnels) then TOR should not only run much faster for you but also much more securely.

Why care about the corps? Because they have deep pockets and shrill screams. If they buy into the idea that they can have highly secure remote offices and extranets, with decent service level guarantees, without paying through the nose, then they aren't going to give that up. The tech wizard sees no-one, no-how.

Authors get paid when people like you upvote their post.
If you enjoyed what you read here, create your account today and start earning FREE STEEM!