20

I feel like there must be a simple explanation, but I've been looking around haven't found any wholesome answers.

Take for example my name is Alice and my best friend Bob and we want to communicate securely.

If I write a program that takes my text and obscures it through several dozen filters and can successfully reverse the process, assuming I then wrote the program on a piece of paper and gave Bob my paper in the middle of the desert where he then memorized it and burned it, how would anyone ever possibly crack our code?

To elaborate on obscurity take for example I do the following:

  • Take my original string and convert it to binary
  • From there I add the last digit of the year to each number
  • Then I reversed the text
  • Then I added a randomly generated character once every 3 characters
  • And so forth, on and on, until I had several dozens obscurities filtered through.

Why wouldn't it be more-or-less impossible to decrypt our message without the program or formula itself (or at least for several years)?

Side note: I would understand completely why security through obscurity wouldn't work for people saying things like "I'll just use weird OS and I'll be safe because who the hell understands weird OS!" I am asking purely asking about sending an encrypted message back and forth, that if intercepted by a third party would not be able to realistically crack due to its obscurity.

lzam
  • 872
  • 5
  • 16
Vale
  • 303
  • 2
  • 5
  • Use a [one-time pad](http://en.wikipedia.org/wiki/One-time_pad). (For some people it might be hard to memorize, but [Shereshevsky](http://en.wikipedia.org/wiki/Solomon_Shereshevsky) would have no trouble.) – Matt Sep 02 '14 at 08:32
  • 1
    Even if the created ciphertext is hard enough to analyze, the mechanism will only be good for Alice,Bob and you. Generally we want to have algorithms that we deploy widely, which means that sooner or later we have to give implementations of that algorithm to people that have the ability to reverse engineer it. – PlasmaHH Sep 02 '14 at 09:34
  • 1
    To quote Schneier's observation: _Anyone, from the most clueless amateur to the best cryptographer, can create an algorithm that he himself can't break._ Often security by obscurity falls under this because with increasing use, things get noticed. And the underlying message traffic doesn't withstand statistical analysis, so it ends up being soul salve that bitterly proves to be useless. – Fiasco Labs Sep 23 '14 at 04:36

5 Answers5

22

The reason that relying on security through obscurity is frowned upon, is that once the algorithm is leaked or broken, you've totally lost all the security gained by obscurity. So if any actor with access to the algorithm ever leaves your organization, or you are hacked, or source code (or an executable) of a encryption/decryption program is somehow leaked/stolen, then you've completely lost all the security from your algorithm being obscure.

To regain the security through obscurity, you have to come up with a totally new cryptographic algorithm, get cryptographic experts to securely analyze the new algorithm, and secretly exchange the algorithm with all parties that need to communicate.

Meanwhile, while using standard well-vetted cryptographic algorithms, we separate the algorithm (where you don't mind if someone steals it) from the key that is computationally unfeasible to brute-force (e.g., to brute-force a 256-bit symmetric key if every proton/neutron on Earth (all 10^51 of them) each tried a billion keys a second, in a million years of brute forcing it, you'd only have a 1 in 1000 chance of breaking it).

Only the key needs to be kept secret. If you lose a key through an attack or need to securely send messages with a new party, you don't need to invent a totally new algorithm. You just need to generate a new key.

With a well-vetted public algorithm anyone can come along and try to analyze it and see if there are any serious vulnerabilities. That can't be done with your private algorithm which often are much weaker than the implementer may think. (E.g., as Daniel mentioned the algorithm you described would be vulnerable to many standard attacks like letter frequency analysis, analyzing periods in the text, exploiting patterns in underlying plaintext, etc.)

Additionally, using secret algorithms is significantly more difficult from a usability standpoint. There's much more the user has to remember for every exchange with every other user. When you find some file you encrypted 5 years ago or someone sends you a file, even if you still have the key/password it will be much easier to decrypt if you know it was encrypted with AES256 in CBC-mode, as there file meta-data stating that information, versus trying to remember what type of secret custom encryption algorithm you may have been using with this particular individual. If users work on a variety of platforms, it becomes troublesome to get your custom secret encryption algorithm working perfectly on all of them.

dr jimbob
  • 38,768
  • 8
  • 92
  • 161
19

If you are only sending one short message (a sentence or two), then it would be difficult to break. However, once you start sending large messages or frequent messages it would probably be very easy to break using techniques like language letter frequency.

For example, with many simple encryption techniques, an "a" will always translate to the same encrypted letter. As a result, with enough text, it is easy to figure out which letters are which based on the frequency.

You can even do it without knowing anything about the formula which encrypted the text. Even ciphers which seem to hide letter frequency can still expose it (see this one for example). With computers, evaluating letter frequency can be automated and done very quickly.

There are other ways to break codes; letter frequency is just an easy to understand example.

Daniel
  • 381
  • 2
  • 3
  • 1
    This is the most logical thing answer I've heard found so far, thank you. – Vale Sep 02 '14 at 00:36
  • Here's a counterexample: if I use an obscure PRN generator, send each message prefixed with a large random key as its seed, and XOR the message with the generator's output, it's going to be pretty hard to use any analysis techniques to figure out what's going on, and the attacker is unlikely to bother anyway, because they'll think it's likely to be AES-encrypted, like a lot of encrypted traffic these days. Even if they do bother, (but they don't know the algorithm of our PRN), it's going to be very hard for them. We don't even have to invent our own PRN — just combine a few of different types. – Evgeni Sergeev Sep 02 '14 at 10:57
  • 1
    @Evgeni Sergeev - That's a bad idea. If you just take an off the shelf RNG, there's a significant chance you'd using something like a 32-bit random number generator with a small period which would very much be attackable. See [this question that states your method is easy to attack with elementary techniques](http://security.stackexchange.com/questions/6740/). Even if you combined multiple linear congruential generators with large non-overlapping periods, in essence the parameters of the LCGs are the key - and probably come from a smaller key space and would still be quite vulnerable. – dr jimbob Sep 02 '14 at 19:41
  • @drjimbob By "obscure" I meant the algorithm would be obscure, not the implementation. But suppose I limit myself to a few LCGs running in parallel and affecting each other's state in an obscure way. The discussion you link mentions Salsa20 http://en.wikipedia.org/wiki/Salsa20 See how simple that is? And the best cryptanalysis of it takes 2^251 ops to break it... While in my scheme I would mix up the bits with even more turbulence, as I'm not worried about performance. – Evgeni Sergeev Sep 03 '14 at 07:23
3

Have a look at This Question, and in particular, This Answer. You're question is almost identical to mine, and Thomas Pornin gave the best answer to this question as ever there as been. You'd best just go read it. Here's an excerpt:

"Security through obscurity" is an expression which uses the term obscurity, not secrecy. Cryptography is about achieving security through secrecy. That's the whole difference: a password can be secret; an algorithm is, at best, obscure. Obscurity is dispelled as soon as some smart guy thinks about bringing a metaphorical lantern. Secrecy is more like a steel safe: to break through it, you need more powerful tools.

Community
  • 1
tylerl
  • 82,225
  • 25
  • 148
  • 226
3

Using keys or using a secret algorithm is the same. Let me repeat that: Using keys in well known cipher algorithm or using a special clever algorithm of your invention is the same: both ways, there's a shared secret that can be measured in bits of raw information.

All cipher methods are based around 'obscurity', what is basically the protection of the shared secret. Basically, it's about keeping the shared-secret secret. Secrecy of your key is correlated to the randomness of it (its entropy). The less random it'll be, the more I could guess part of your secret. As these guessed parts are not anymore secret, and we could say that the shared-secret is bits of raw information.

And, you are perfectly right in the sense that you can devise a way that is unbreakable provided you have a long-enough pre-shared secret.

However, you don't need to get too complicated about the algorithm: If you use standard keyed encryption and your key is long enough (longer than the message for example), then it's quite easy to understand that your protection is perfect. Just as a reminder: a simple XOR cipher with a truly random key longer than the message is unbreakable. But don't forget the following: you need a long-enough pre-shared secret (and a new one for each communication).

So where's the issue ? Why don't we just do this ? Because your shared-secret worns out each time you use it. And you'll eventually run out of it. Using your key gives away subtle part of it: for instance looking at what produces your algorithm gives some subtle hints. The more we see coming out of your algorithm, the more patterns will be noticed.

So, in most practical cases, we like to start from the point where Alice and Bob don't share at first a secret, or at least this secret is not long enough to cover their communication. Remember that in your case, the secret is the algorithm, and in the standard case it's often a key and we call this shared secret.

So, in standard cryptographic case, concerns is shifted towards creating (more) shared secret. So, most of the effort is then spent to find way to create some key which then will lead to the point where Bob and Alice are protected by theory and a standard unbreakable cipher: having a long-enough secret.

Most of now-a-days cryptographic communication will work this way: create a shared key on-the-fly (often at regular time interval in continuous communication), then use any trivial but perfect cipher algorithm (as the XOR one for instance) with this key. Diffie Hellman is one of these algorithm. Usually, the first part is the most complicated and can take a lot of computer power, and the second is trivial.

So the hard part is to have (or generate) enough shared secret to encrypt your data.

vaab
  • 131
  • 3
  • 1
    Actually, this is not correct. A basic underlying assumption of any symmetric crypto is that the sender and recipient (whether different entities, or the same entity separated in time or space) **shares a secret.** (In the case of most modern algorithms, that secret being the key.) How to *establish such a shared secret* is a separate problem, and it can be done using techniques like public-key cryptography, pre-shared secrets, and so on. – user Sep 02 '14 at 11:25
  • @MichaelKjorling Thank you for your comment. I rephrased my content to take into account your remark. I hope this is clearer now. – vaab Sep 23 '14 at 05:43
1

Imo being secure, and being able to prove that you are secure are two different things. Ideally you want to be able to lay everything out on the table for inspection.

That involves identifying your points of failure and what secrets there are in the system, and how those secrets are being protected.

For infrastructure secrets, your applications may use key phrases to access resources, and those keys are protected within DMZ firewall and encrypted by machine keys. And you can prove that and the auditors and they are happy.

For user access, the idea is that only the user knows that secret, and you can prove to the auditors that you aren't storing the secrets anywhere in a way that can be derived, among other password best practices, and you can prove that to the auditors and they are happy.

Obscurity is when you're hiding something, and this is different than keeping your keys and passwords secret. You're hiding how the system or your algorithm works.

I don't think obscurity is bad. I think it is probably a bad choice for most businesses. It isn't necessary and can cause complications throughout the business.

Andrew Hoffman
  • 1,987
  • 14
  • 17