One of my friends was talking to me:
Hey you see that guy? He is a very good programmer and he knows a lot of stuff.
I asked him whether he knew anything about this encryption algorithm. He told me that he knows a lot about encryption algorithms. In fact he writes his own encryption algorithms. He told me that it is always better to write your own algorithms.
Yeah.
Now I know how knowledgeable he is.
I have small request to make to all of the self proclaimed cryptographic experts out there:
Cryptography is hard. It is hard because there are always smarter people out there who can break your home-made super-duper encryption algorithm. If you are so confident in your abilities, use your own encryption algorithms in your own applications. Please don’t give it to the public. If are sharing your application with us, specify that you are using your own encryption algorithm so that we’ll understand how awesome you are and how awesome your products will be (and probably avoid using your awful application).
I know what you will be thinking right now:
But, nobody ever cracked my encryption algorithm!
That is because nobody cares. People have their own work to do rather than trying to crack your pet algorithm. If you really want to test the strength of your algorithm, try announcing a million dollar prize for the guy who breaks it.
And please don’t spread messages like “it is always better to write our own algorithms” among us mortals. May be you can do good security on your own; we can’t.
@Forgotten: “Theoretically, yes. Real-world, I just don’t buy it, Al. Say you’re the first human being who just made up ROT13. Layering that around an encrypted session does not actually reduce the strength of the encryption within.”
Yes, in the case of ROT13. But of course ROT13′ing your encrypted data stream doesn’t *increase* the strength of the encryption either.
The trick with ROT13 is that its cryptotext has the same amount of entropy as the plaintext. Most encryption implementations aren’t like that. Here’s a trivial example: To encrypt a file with ROT13-ULTRA (which I just made up), start with the 6-byte file header “ROT13″ and append the ROT13 encryption of the plaintext. Now, since you know all about encryption and known-plaintext attacks, you can easily see that it’s marginally easier to crack AES(ROT13-ULTRA(plaintext)) than it is to crack AES(plaintext).
Since you know all about encryption, you have also heard the phrase “security through obscurity”.
Forgotten:
> Say you’re the first human being who just made up ROT13. Layering that around an encrypted session does not actually reduce the strength of the encryption within.
It could. What if your encryption was ROT13? You’ve just removed all encryption by your act of double-encryption.
As for adding “human engineering hours” to the cost of brute forcing some encryption, it is a silly misunderstanding of scale. If it takes 10^13 years (age of universe: ~13 * 10^9 years) to exhaust the keyspace of my encryption (e.g. 128-bit AES), then yes, I don’t mind giving some engineer a couple of hours’ head start.
I suppose mathematical flaws are possible, but in this case I’d prefer that there be as many smart researchers trying to publish all about those flaws in my well-known algorithm as possible.
Most people commenting are full of it.
I’ll write a crypto algorithm that is unbreakable:
1) Fill a 1 TB disk with random bits (from a truly random source, such as quantum noise)
2) Duplicate said disk
3) Send one of the disks to the other party on the end of the crypto link; put it in tamper-proof packaging.
4) Now, take plain text and XOR with the bits from your 1 TB disk, and send those bits over a clear channel (e.g. email).
I’ll give you one BILLION dollars (if I had it) to crack this scheme.
Of course, in practice you’d run triple DES over your plaintext, and then run that into AES, and then XOR in those random bits from disk. Good Luck, NSA!
MikeC,
That’s not a new algorithm. As you no doubt are aware, that’s a classic One Time Pad. Niyaz’ point holds.
Hi,
My name is Gus and I love writing my on encryption algorithms and nobody will ever be able to crack them. I am a self professed genius!
89098asqH67543g^&4hkyuiiiiuuuuuuu^4332dsdRF*Sh*t
Your link to ‘Double Encryption Is Not A Good Idea’ in the comments actually points to a post telling the reader that it is, in fact, a good idea. The post was made in a thread with the subject ‘Double Encryption Is Not A Good Idea’ though.
Bruce Schneier has a “Self-Study Course in Block Cipher Cryptanalysis” that is very relevant.
http://www.schneier.com/paper-self-study.html
Here’s a quote from the paper:
“The only way to become a good algorithm designer is to be a good cryptanalyst: to break algorithms. Lots of them. Again and again. Only after a student has demonstrated his ability to cryptanalyze the algorithms of others will his own designs be taken seriously.
Given that many many ciphers are invented every year – some published, some patented, some proprietary|how do cryptanalysts know which ones are worth further study? They look at the pedigree of the algorithm. An algorithm that has been invented by someone who has shown that he can break algorithms – he’s
studied the literature, perhaps using this course, and published a few breaks on his own that had not been discovered before|is much more likely to invent a secure cipher than someone who has done a cursory read of the literature and then invented something. In both cases the inventor believes his cipher is secure; in the former case the inventor’s opinion is worth something…”
Forgotten said:
“Hey, if you want to keep on using vanilla implementations of standard published crypto methods to secure your data, be my guest. Your encryption will be easily identified for the type it is, and then easily broken, either through mathematical flaws or brute force.”
Your are fundementally failing to understand what good encryption is. I.e. a public well understood algorithm that has been attached by everyone and a *secret* key. It doesn’t matter if the algorithm is known as there are *no* currently known “mathematical flaws” (e.g. to AES) and you can’t brute force it if your keys are big enough.
I say go with well-known military grade encryption but get creative with your salts and seeds.
I have written encryption algorithm – as a matter of fact, I have created two. One was a port of the WWII enigma machine into javascript. So technically, the algorithm is not mine.
But that was just for learning purposes – it goes without saying that if I have something to encrypt, I would choose a method that was created by pros(and is open source – can’t trust encryption that’s not open – the old ‘security by obsurity’ argument pulls no weight with me).
Reminds me of the joke about using triple rot-13 rather than the less scrambled single rot-13 in usenet posts that movie spoilers.
‘me’:
The post in question starts with a quote, with the response below.
Relevant section: “”"The only circumstance in which double encryption fails it’s (naive) expectations and triple encryption should be used instead is when you are using multiple encryption in order to increase keyspace – which is usually a bad idea in the first place, you should normally use a bigger and better cipher instead. “”"
In short, layering the encryption is something you do for specific technical reasons, not something you do to generically ‘make the encryption stronger’.
cwillu,
Exactly!
Security through obscurity doesn’t work.
I totally agree with the author.
In my opinion:
* Creating your own “very secure” algorithm may take longer to design and code than using an existing algorithm.
* Existing algorithms are proven to be secure to a certain level. A custom created algorithm is not proven to be secure. Proven by yourself and your team members cannot be compared to the hundreds (or thousands) of experts who analyses popular encryption algorithms.
* The popularity or internal knowledge of how works an encryption algorithm does not necessarily expose it to be easily broken. During the initial phases of exposure to the public several flaws will be identified. People will then judge the algorithm and either people will propose corrections or it will be negatively criticized as being weak or impractical.
* As computing power gets cheaper existing encryption algorithms that were strong at certain time in history are becoming obsolete. The purpose of the algorithm will determine who strong should be the algorithm. SHA-1 (a hash function, 1 way encryption algorithm) is said to be broken because a group of people were able to find collisions requiring 2^69 operations rather than 2^80 (which would be with using brute force). There is now a SHA-2 that is stronger and there are considerations for SHA-3. The algorithm is known and overtime is getting stronger. Yet, if you will use SHA-1 for protecting the personal information of 10 users in your database you will be fine. The people hacking your database probably will waste more time and money for cracking it than what is worth (unless those 10 people are rich). Probably they will even ignore it if they see that there are only 10 users.
* A comment regarding the encryption algorithm that uses the 1 TB hard disk:
- The 1 TB disk in this case needs to be sent to your customer, which involves shipping cost taking into consideration the safety material used for transportation.
- The 1 TB hard disk itself cost few hundred dollars.
- The disk needs to be connected to the server, which involves time of a technical person (not everybody knows how to connect a hard disk and don’t ask a Manager to do it).
- You need to keep hard disks inventory, which requires space (there is an associated cost with maintaining inventory).
- Someone will need to ship the hard drives to the customers, if you do it yourself it either takes a lot of time go to FedEx or a postal office or you pay for pickup.
- A 1 TB hard disk key will take a while to be generated and it will take a while for a computer to encrypt and decrypt messages.
The point is: An encryption algorithm can be very strong but is useless if it is impractical.
* The ego of a person can make him think that his or her code is better than anyone else. It could be true, but is not practical spending 1 week (being optimistic) designing and coding an encryption algorithm if there are many available in the internet for free and with no legal implications for commercial software, and possibly in the programming language of your application.
Example: Internet search + copy paste = 2 hours (and if you are lucky on the first search hit, 5 minutes).
The person could be a good programmer, but is not efficient in his work.
* All encryption algorithms are susceptible to brute force attacks regardless how many layers you are using.
Example: There are iPhone applications for protecting your personal information that uses a 4 digits encryption password. This means that there are only 10,000 possibilities for the password (from 0000 to 9999), which could be easily cracked. A fixed length password is a lot easier to crack than a variable length especially if the characters are only digits.
>All encryption algorithms are susceptible to brute force attacks regardless how >many layers you are using
yes, the question is, can they crack a single encrypted file before the writer could have already have died and been eaten by worms?
I hope the guy you met wasn’t Bruce Schneier. [http://en.wikipedia.org/wiki/Bruce_Schneier]
I think he writes crypto algorithms for time pass, and heard he’s pretty good too.
Watch out for him
Jokes apart, changing your keylayout to Dvorak and typing QWERTY, and vice-versa is a good way of fooling may ‘trained’ eyes.
Carb0n,
Yeah, but that is just a simple substitution cipher!
Hi Folks,
Please get set to welcome my own encryption algo – due to be released in about 2 months from now (after successful tests). A combination of some math & probability laws makes it extremely complex to break. Currently being tested on a 24 parallel-processors hardware with 64-bit deciphers for past 30 days.
A set of hints on how it works:
a. Develop a linear-pattern tree of every unique character;
b. Obtain relative differential values from every alternate tree;
c. Build a fresh tree-set using the supplied master-password;
d. Shuffle the step “c” tree-set by generating a new seed, using a combination of the master-password and base-2048 ultra thin-recurrence likelihood probability;
e. Using the “d” seed, build the 2048-bit long index array;
f. Shuffle & obtain a new character against each user-data character through this array (total 4,294,967,296 possible combinations of each character).
The proposed name of my algorithm is: GalacticRouter.
[...] As a precautionary step you may want to make the algorithms/protocols used in your application easily replaceable. This will make your life easier when the algorithm is broken and you want to replace it. Also, as a programmer you should understand that even if the algorithm is not yet broken, your implementation may be flawed. Most of the security vulnerabilities are caused by crappy implementations of secure algorithms/protocols. And did I mention that you should not write your own encryption algorithm? [...]