3 replies to this topic

[liamzebedee]

I am creating an encryption algorithm. I have researched RSA, AES etc. and have examined all their 'methods'. I am now wondering when is enough enough. For example you could do all sorts of things to plaintext, reverse the bits, transform it into base64, compress it etc. but I am wondering when enough is enough. How can I measure this?

[Alexander]

One of the points is to have a good substitution box of which these ciphers rely on, allowing keys to be diffused from the result beyond recognition (and thus your intended result has no relation to the key) - Even an unknown one could do fine. Often these substitution boxes are patented or protected (see Confusion and diffusion - Wikipedia, the free encyclopedia). If your cipher accepts a key length, 2^1024 bits of key possibilities would be 179769313486231590772930519078902473361797697894230657273430081157732675805500963132708477322407536021120113879871393357658789768814416622492847430639474124377767893424865485276302219601246094119453082952085005768838150682342462881473913110540827237163350510684586298239947245938479716304835356329624224137216 keys to look through which is unfeasible. This does not prevent the fact that RSA does not have any random aspect, such as the result being generated the same regardless of the same key so a key is not in itself the most reliable. A cipher (with specific modes such as electronic code book) such as Blowfish does allow initialization primitives to add to the quality of randomness effectively making the key useless on its own. This could be seen as a viable solution to prevent lookup (especially if the cipher, initialization vector and mode is not known.).

As for your mentioned steps, you would work on the whole string as bytes and output as bytes, most certainly not work on the string as individual characters if you are doing so. This can lead to very easily spotted patterns, a single discovered pattern could in fact reveal two encrypted keys similarity.

[WingedPanther]

The issue generally comes down to two things:
1) how long does it take to brute-force the decryption, knowing how it was encrypted?
2) are there any shortcuts to avoid brute-force?

In general enough is enough when nobody will be able to decrypt your file using any known method, taking into account Moore's Law, for 10 times longer than you care about.

Also, there are some changes in computing that may come along that could completely circumvent the above.

For small files, the best usually isn't expensive enough to matter. For larger files, you want to consider whether it's actually worth the extra time to encrypt.

Finally, plaintext, reverse the bits, transform it into base64 are all highly insecure methods. For all intents and purposes, you might as well be sending the data in plain-text with those methods.

[Upstream]

You could also ask yourself: at what point does it become to much of a good thing? How sensitive is the data and from what needs it to be protected? If you write your own then I suspect that at best you offer protection against crackers that aren't interested in your data and maybe against your little sister :) But if you want to learn a bit more this site offers nice practice. Hack This Site!