Writing your own encryption algorithm? Duh!!
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.
« « Nails into the wall using Stack Overflow | Bharti AXA Investments is spamming me, challenging me to complain » »
hey, that is true, if the guy is a beginner then it is difficult to write the secure encryption code. But there are people (human only) out there who write encryption algos for the best of all the tools and services that we use. So there can be one doing it for the very first time and who could be better than all, who knows!
Tejaswini,
It is true that there are people who are capable of writing good algorithms, but they too can make mistakes. So what do you do to make a new encryption algorithm?
Publish the details of the algorithm and let the mathematicians and cryptographers around the world analyze your algorithm and try to find flaws in it. If they fail to do so, you can say your algorithm is a good one.
Read the Advanced Encryption Standard process to know how they took 3 years to select a winner for the AES process!!! For that 3 full years the cryptographers in the whole world were trying to break the algorithms. If you stand that test, then you know that you have a pretty good algorithm.
Ha… this guy’s smoking crack. You don’t just “become” a good encryption algorithm writer, it takes years of training. And that training would initiate with some fairly sophisticated mathematics. I’ve taken encryption courses in graduate school and I can tell you that the most sophisticated encryption algorithms are based on number theory and advanced mathematics. It’s not just in rearranging letters!
If the guy in question were truly writing innovative stuff he would have been scooped up by the NSA years ago…
Globe,
Yup.
If he is a good programmer, then he probably meant he implements encryption algorithms on his own. I just can’t imagine anyone with common sense to say that it is a good idea to design a brand new encryption algorithm.
There is a forgotten point here. It is much easier (compute hours + man hours)to attack something that is made with a well known encryption algorithm than it is to attack a black box.
The often repeated line is “you need to stick with the major algorithms because they’ve been proven.” Most have accepted it.
An untested encryption method could easily have a simple flaw that allows for a quick solution. The downside is the number of human hours required to analyze and find the flaw to exploit.
Want a tough compute hour + man hour encryption? Layer them.
Forgotten,
It has been shown that layering encryption algorithm does not lead to a better security always and sometimes they even lead to a worse security that any of the individual algorithms.
“…layering encryption algorithms does not lead to better security… and sometimes even leads to worse security”
I don’t understand how that’s possible- Can you explain or provide a link? I’m curious to see how that would work-
I know that other algorithms are like this- For instance, if you shuffle a deck of cards enough times, the ordering can become predictable. Not sure why that would be the case with encryption, though.
Alex,
Instead of double encryption, it is always better to use one algorithm with double the key length.
Here are some links on the topic:
double encryption
Double Encryption Is Not A Good Idea
What is Multiple Encryption
Double encryption(Blowfish->Rijndael) Stronger? Or dumb?
Alex and Forgotten, here’s your link:
http://www.amazon.com/Introduction-Cryptography-Discrete-Mathematical-Applications/dp/1584881275/ref=sr_11_1?ie=UTF8&qid=1234372088&sr=11-1
It’s a really solid introductory text and will answer your questions and (in the case of Mr. Forgotten) clear up your terrible misconceptions about encryption.
Y’know, Cory Doctorow talks about this in quite some detail in Little Brother, and it’s actually somewhat to do with the plot.
Make your algorithms public and safeguard your encryption keys. Security by obscurity is not security at all.
Even if you had the necessary math background as a programmer/developer one doesn’t have enough time come up with a good algorithm that will stand the test of time. That said, there are a few algorithms that were thought to be secure are no longer secure with today’s increased processing power.
GB
> And please don’t spread messages like “it is always better to write our own algorithms” among us mortals.
You are so WRONG about this. I don’t know about your guy, but what I know is that if people I admire contented themselves with existing algorithms (Dijkstra, Wirth, Hoare just to name few), there wouldn’t be any progress at all.
Victor,
If you know the rules, you can break them.
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.
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.
If you don’t want to add human engineering hours to the cost of decrypting your data, hey, you’re doing someone a big favor. Keep everything standard, willyah?
Hey, hey, hey. HEY!
I’ll have you know that I have authored several forward-only encryption systems that perform their function with great expediency and efficiency.
Sadly, my boss didn’t really approve since I was supposedly writing a “billing system” for “the accounting department”.
No-one appreciates my work.
Once you’ve mastered writing your own encryption algorithms, key distribution is a piece of cake. PIECE OF CAKE!
-PaladinZ06
>Your encryption will be easily identified for the type it is, and then easily broken,
>either through mathematical flaws or brute force.
Easily? Only if by “brute force” you mean “kick ass of man who encrypted data with until he decrypts everything”.
s/with unti/< favorite encryption method >
Instead of double encryption, it is always better to use one algorithm with double the key length.
No one’s ever broken by double ROT13 encryption
It actually _is_ better to have custom encryption algorithms. But nobody with a gram of brainmatter would hand the matter to anyone other than a cryptologist.
@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.
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? [...]
Hi,
can any one tell me how to make a encyption algorithm
I have great encyption algoritm..
mailme at
ralphnaderralphnader@gmail.com
Hi,
some of you guys have forgotten one thing:
- if there were no one who tried to write a own good algorithm, there wouldn’t be a good algrithm on earth
I want to learn encryption. I know c c++ langauges. Can you suggest how should i start and from where to start??
Vivek,
Start by reading the book: Applied Cryptography: Protocols, Algorithms, and Source Code in C, Second Edition by Bruce Schneier
Even though the above book will give you an introduction to cryptography as a subject you should follow up by reading the book Practical Cryptography by Niels Ferguson and Bruce Schneier to be able to understand the real-world implementation of cryptography.
Read this comment too.
I am a bit confused how it is hard to create cryptography.
xor the data with a key continuing every byte as long as the key, loop at the end of the key. Then don’t give the key out. This works with all kinds of data.
I know you guys will have a fit over this, “that’s so easy to unlock”. Really? What are you going to do attempt to decrypt with every possibility of length and bit order? Fine if the key is dumb and short (“god”), if its 64 characters and doesn’t contain in standard characters you will have a bit of trouble.
Slam it all you like, if no one knows the length of the key or its contents you are going to spend a hell of a lot of time trying to decrypt that data. And by the time you find it is their grandmothers name or their birth year it wont matter.
Isn’t that the purpose to encrypt and have a simple cypher, make it hard for others to decrypt?
Door and key guys. Doesn’t matter what the door has or is, if you have the key it will open.
And never forget if there is a way in people will always find a way. That is part of our nature.
I have to also agree with MikeC
You are all making this neat-o encryption so hard when it isn’t.
And as for no one caring as the author says about your encryption, well that is the best right? The data no one tries to break would be the most secure.
Hi guys and girls
im new to this but i need someone to help me with this tool i am developing.
I need a great or rather an entertaining level encryption program for text.
Any help please email me
klashmania@gmail.com
cheers