I don't know much about the heavy math behind cryptosystems, I get stuck when it gets bad with the Z/nZ algebra, and sometimes with all these exponent of exponents. It's not I don't like it, it's just that the information you find on the web are not easy to follow blindly.

I was wondering: how reliable can a algorithm be when it encodes a message into plain binary. If my algorithm is arbitrary and known only to me, how can a cryptanalist study an encrypted file and decrypt it, with or without having the decoded file ?

I'm thinking about not using ASCII text to code my message, and I have some ideas to make this algorithm/program.

Attacking a AES or blowfish crypted file is more trivial for a cryptanalyst, than if the algorithm the file is encrypted with is unknown to him, but how does he do then ?

I don't know if I understanded well, but a CS teacher once told me that codes are harder to crack that crypted ciphers.

This sounds a bit like security by obscurity. Probably a bad idea!
–
ScottEJan 10 '11 at 17:06

2

Very bad idea. AES and Blowfish are considered secure exactly because they are open and available to everyone to analyze. Just because the details of an algorithm aren't available doesn't mean that it will suddenly be resilient to all cryptanalytic attacks. By all means, go ahead and write your crypto algorithm, but before you use it for anything, get it published and peer reviewed for a while so that people can discover any problems the system may have.
–
Reese MooreJan 10 '11 at 17:12

I suggest you try reading "Practical Cryptography" by Bruce Schneier and Niels Ferguson. It's interesting, and it explains why that isn't a good idea.
–
Andy BurnsJan 10 '11 at 17:14

1

If the "heavy math" in these algorithms is black magic to you, then so too will be the methods by which an expert cracks your cipher over lunch.
–
BetaJan 10 '11 at 19:57

@Reese: are there people available to test a coded file ? @beta what if the code is made of methods involving compact bit-words ?
–
jokoonJan 11 '11 at 9:19

5 Answers
5

Attacking a AES or blowfish crypted file is more trivial for a cryptanalyst, than if the algorithm the file is encrypted with is unknown to him...

What about:

Attacking an untested self written algorithm with no real research is more trivial for a cryptanalyst, than if the algorithm the file is encrypted with, is a well known and proofed one, that has been correctly used....

In short, DO NOT roll your own cryptography unless you're an expert, no unless you're part of an expert group in that field.

Nintendo failed when they implemented RSA on their own in the Wii, Sony failed too when using it in the PS3 (they pretty much used XKCD's random number function for M...)

And you really think you can win by using security by obscurity?

PS: That doesn't mean that you should take the Wikipedia entry on RSA and roll you own implementation from that one (that's exactly were Sony and Big-N failed), no use a tested, open source implementation.

Here's the ticket. While the way you are doing it remains a secret, the security stands tough. But once someone figures out how you did it, they will likely find a hole in it and crack all of your encrypted data easily... Security through Obscurity is nothing more than a house of cards. It can stand well and good until there's some wind. Then instead of being able to react, it all comes tumbling down. History is full of proof that open, secure algorithms like AES are better than "hidden" and obscured ones (like MS's password hash LM_Hash...
–
ircmaxellJan 10 '11 at 17:43

Note that Nintendo and Sony implemented a well known crypto primitives, just like you recommended the OP to do, and failed, so they're not really a great example here.
–
Elazar LeibovichJan 10 '11 at 21:51

@Elazar They implemented it on their own from SCRATCH. I'm not telling him to implement RSA on his own, but to use a tested implementation. Maybe I should edit my answer to state that more clear.
–
Ivo WetzelJan 11 '11 at 8:17

security through obscurity can be quite a vast subject... I'd like very much to study why AES/blowfish are that much secure, because I don't understand why those algos are the result on some community or cryptography contest. It's not that I don't trust it, but since it's adopted by the NSA for example I wonder what if someone finds how to crack it, if this person would either publish his findings or exploit it for other purposes. I'd prefer that one would learn about the theory behind those algo and make its own instead of just implementing an existing algo, but I guess I should learn first.
–
jokoonJan 11 '11 at 9:34

When the attacker has no idea which algorithm you used and it is safe, cryptoanalyst has a hard job. So it is unimportant if you use AES or your own cipher as long as it is as strong and safe as AES. Here is the but. Cryptography is a bit demanding and therefore you have many ways to shoot yourself in a foot without knowing it. I would suggest using standard algorithms, maybe with some safe variations.

'your own cipher as long as it is as strong and safe as AES' This is the exact problem...if one does not understand the math, they have no way of knowing if their cipher is as strong as AES.
–
JohnJan 12 '11 at 8:19

yes, that is what I was trying to say in remainder of my answer after the quote:)
–
Gabriel ŠčerbákJan 12 '11 at 13:20

The biggest part of your strategy is called "security through obscurity." You're making the gamble that, since nobody knows the precise details of your little variation on an idea, they won't be able to figure it out.

I'm not a security expert, but I can tell you that you probably won't come up with something incredibly new. Cryptography has been studied by people for millenia and your idea is highly unlikely to be original. Even if you're a relatively good programmer and code something really tricky, the question will come down to who you're up against. If you're just trying to protect your data from your kid sister, then it will probably be fine. On the other hand, if you're using it to send credit card numbers across the internet, then you're doomed to fail. It will be analysed in ways you didn't think of or don't know, and ultimately cracked.

Another way to think of it: algorithms like AES have been extensively studied by professionals in the field and its level of security is pretty well understood. Anything you come up with by yourself will not have the benefit of having been attacked by the best and brightest minds out there. You will have almost no idea of how good it actually is until people start reporting identity theft.

Common wisdom is that you should not build your own algorithms, and especially not rely on these algorithms remaining secret.

The conceptual reason is that good encryption is about quantified confidentiality. We do not want our secrets to get cracked, but in a more precise way we want to be able to tell how much it would cost to crack our secrets (and hopefully show that the cost is way too high to be envisioned by any entity on Earth). This is the real advance which occurred a few years after World War II: to understand the distinction between key and algorithm. The key concentrates the secret. The algorithm becomes the implementation.

Since the implementation is, well, implemented, it exists as some code or a device, which is tangible and stored even when it is not used. Keeping an implementation secret requires keeping track of the hard disk on which the code resides at all times. If the attacker sees the binary code, he may be able to reverse-engineer it, something which depends on his wits and patience. The point here is that it is very difficult to be able to say: "it costs X dollars to recover a description of the algorithm".

On the other hand, the key is short. It can be stored safely much more easily; e.g. you could memorize it, and avoid committing it to any permanent storage device. You then have to worry about your key only at times when you use it (and not when you do not, e.g. in the middle of the night, when you sleep). The number of possible keys is a simple mathematical problem. You can easily and accurately estimate the average cost of enumerating the possible keys until your key is found. The key is a sturdy foundation for quantified security.

So you should not roll your own algorithms because then you do not know how much security you get.

Also, most people who rolled their own algorithms found out, usually the hard way, that they did not get much security at all. Designing a good encryption algorithm is hard, because it cannot be automatically tested. Your code may run, and properly decrypt data that it encrypted, but it tells you nothing about how secure the algorithm is. The design of the AES was the result of a process which took several years and involved hundreds of skilled cryptographers (most of whom had a PhD and years of experience in academic research on symmetric encryption). That a lone developer could do as well, let alone better, in the secrecy of his own workshop, looks kind of... implausible.