klionwines.blogg.se

1. Security obscurity software#
2. Security obscurity code#
3. Security obscurity professional#
4. Security obscurity crack#

Security obscurity code#

The take home message, then, is that having one lump of excellent security code that is well vetted and bug free like a standard encryption function can still be undermined if you put a buggy home grown program (of any sort, encryption or otherwise) onto the same system.įirst of all, Encryption algorithms are designed so that you, me, and everyone around us can look at it and try to break it. Perhaps a bug in your custom layer lets a remote adversary run arbitrary commands on your machine then they could just email themselves the plaintext!

Security obscurity software#

There are still risks, though, because every extra piece of software carries additional risks. At least, it won't be possible to bypass the standard encryption. it works with data that has already been securely enough encrypted for transmission and doesn't touch the keys of the standard encryption, then it may be safe. If your custom encryption layer does not interact at all with secret information: i.e.

Security obscurity crack#

That doesn't sound like much information, but if an attacker can watch enough encryptions they can potentially work out what the plaintext is without having to crack AES or whatever you're using on top. This makes them vulnerable to timing attacks: because of the way CPU caches work if two letters in the plaintext are close together they will likely encrypt faster than two letters that are further appart. Unfortunately, substituion ciphers are inherently reliant on doing array lookups from private information (i.e. You first use a simple substitution cipher and then use your choice of heavy hitting algorithm. If you use your own encryption first, even if the second layer is military grade encryption, you risk decreasing your security compared to just using the standard encryption.įor example, suppose that you are encrypting text. Standard encryption algorithms are vetted to make sure they're resistent even to these powerful adversaries. At the high end you're up against an attacker who knows the plaintext and ciphertext pairs of hundreds of other messages, who can coerce your computer into encrypting other messages with the same key, who can monitor the power lines to your building and measure the tiny variations in power draw as the encryption process proceeds, and all kinds of similar attacks. The first question to ask when assessing any sort of security system is "Who is the attacker, and what can they do?" At the low end, you're against an attacker who can just see the encrypted output of one of your messages. Don't shoot yourself in the foot and instead use proper algorithms.

Security obscurity professional#

The only time you should ever actually do this is if you are a professional cryptographer. Actually using your own homebrew crypto is a very bad idea, no matter how you use it. While it may be fine in theory, the real world works differently. It was pointed out to me in a comment that I may not be sufficiently emphasizing just how bad of an idea this is. From a purely theoretical point of view, they are out-of-scope. There can also be bugs in your implementation that result in other security vulnerabilities. It can leak information about the plaintext through length. This is partially why your second example, with your custom algorithm applied before standard encryption, is indeed worse. A compression function is still a function, and sometimes compression and encryption can lead to very bad results. I mentioned length-preserving above for good reason. The only possible way it could reduce security is if your homebrew function does not use a different, independent key and leaks the key in the ciphertext, for example with f k(x) = x ⊕ k done on each individual block of input x, a classic XOR cipher vulnerable to known-plaintext attacks.įrom a practical standpoint, there are gotchas that can matter. In fact, even the identity function, defined as f(x) = x, will not reduce security, assuming the keys used for the standard cipher and your homebrew cipher are mutually independent. From a purely cryptographic point of view, any length-preserving bijective function cannot reduce security.