This is not usually how this works.
First off encryption and hashing are two different things. The most notable difference being that hashing is a one way function to produce a fixed length output that can not be reversed to the original text, while encryption is designed to be decrypted.
Second it’s common to refer to “don’t roll your own crypto”. Existing crypt and hash functions have been vetted for years before getting into daily use. Most are still using Bcrypt while Scrypt and Argon are arguably better in every way. Other people have said this much better than what I’d do here so I’ll just shamelessly copy some in here
Your question, MikeAzo’s comment, and your reply practically could not be a better example of Schneier’s Law in practice. Schneier stated:
Anyone, from the most clueless amateur to the best cryptographer, can create an algorithm that he himself can’t break.
To answer your reply
How can you break it if I send you this “QTCPIGXKUXTGG” ciphertext encrypted by a merely a simple algorithm which you have no idea about how it was encrypted?
Because even though we might not know exactly what your secret algorithm is, the first thing an attacker is going to reach for are common tools to attack substitution ciphers or polyalphabetic ciphers. Given even a few sentences of ciphertext is likely enough to fully recover every plaintext.
The fact that you don’t know how to break it is irrelevant. It’s trivial to create a cipher that you yourself can’t break, but it’s another thing entirely to create a cipher that others can’t break. And the odds that you are capable of doing it when you’re not aware of even the most basic attacks against ciphers hundreds of years old — not to mention modern concepts like indistinguishability under different attack models — puts you at an insurmountable disadvantage compared to ciphers designed by researchers with decades of experience in the field who are building off of modern notions of security and the discarded remains of thousands of failed ciphers that came before.
As an example, even if your cipher is somehow secure against a ciphertext-only attack (it’s not), is it secure if I can trick you into encrypting a message for me? What if I can trick you into decrypting a message for me? What if I know part of or all of one of the messages you send? What if you encrypt multiple messages with the same key?
I’ll leave you with another Schneier classic, Memo to the Amateur Cipher Designer:
A cryptographer friend tells the story of an amateur who kept bothering him with the cipher he invented. The cryptographer would break the cipher, the amateur would make a change to “fix” it, and the cryptographer would break it again. This exchange went on a few times until the cryptographer became fed up. When the amateur visited him to hear what the cryptographer thought, the cryptographer put three envelopes face down on the table. “In each of these envelopes is an attack against your cipher. Take one and read it. Don’t come back until you’ve discovered the other two attacks.” The amateur was never heard from again.
So here’s your first envelope. Given a paragraph or two of ciphertext, your cipher will fail to language-based frequency analysis.
Let me know when you’ve figured out the other two attacks.
Edit: The comment about indistinguishability under different attack models is one reason why most “decipher this message crypto challenges” are completely bunk. They often simply give an attacker some ciphertext, ask them to decipher it, and declare victory when nobody produces the plaintext after some amount of time. Unfortunately that’s not how crypto works in the real world; attackers have many more tricks up their sleeve in practice. They can trick computers into encrypting data of their choosing, they can trick computers into decrypting data of their choosing, and they can usually even do these things thousands, millions, or billions of times. Moxie’s post shows how even the most terrible, horribly-designed, and obviously insecure ciphers can be effectively impervious when you restrict an attacker to a single ciphertext-only attack, which aren’t representative of attackers’ capabilities against ciphers as they’re actually deployed in practice.
Source:
https://crypto.stackexchange.com/a/43274
You can roll your own, but you probably will make a major security mistake if you are not an expert in security/cryptography or have had your scheme analyzed by multiple experts. I’m more willing to bet on an open-source publicly known encryption scheme that’s out there for all to see and analyze. More eyes means more likely that the current version doesn’t have major vulnerabilities, as opposed to something developed in-house by non-experts.
From Phil Zimmermann’s (PGP creator) Introduction to Cryptography (Page 54):
When I was in college in the early 70s, I devised what I believed was a brilliant encryption scheme. A simple pseudorandom number stream was added to the plaintext stream to create ciphertext. This would seemingly thwart any frequency analysis of the ciphertext, and would be uncrackable even to the most resourceful government intelligence agencies. I felt so smug about my achievement.
Years later, I discovered this same scheme in several introductory cryptography texts and tutorial papers. How nice. Other cryptographers had thought of the same scheme. Unfortunately, the scheme was presented as a simple homework assignment on how to use elementary cryptanalytic techniques to trivially crack it. So much for my brilliant scheme.
From this humbling experience I learned how easy it is to fall into a false sense of security when devising an encryption algorithm. Most people don’t realize how fiendishly difficult it is to devise an encryption algorithm that can withstand a prolonged and determined attack by a resourceful opponent.
(This question has more discussion of the above quote.)
If you are not convinced of “Don’t Roll Your Own [Cryptography/Security]”, then you probably are not an expert and there are many mistakes you likely will make.
Is your application robust against:
-
Timing Attacks. E.g., to the nanoseconds do completely-bad keys and partially-bad keys take the same amount of time in the aggregate to fail? Otherwise, this timing information can be exploited to find the correct key/password.
-
Trivial Brute Force Attacks; e.g., that can be done in within seconds to years (when you worry about it being broken within a few years). Maybe your idea of security may be a 1 in a billion (1 000 000 000) chance of breaking in (what if someone with a bot net tries a few billion times?). My idea is to aim for something like 1 in ~2128 ( 34 000 000 000 000 000 000 000 000 000 000 000), which is roughly ten million billion billion times more secure and completely outside the realm of guessing your way in.
- Attacks on user accounts in parallel; e.g., you may hash passwords with the same (or worse no) ‘salt’ on all password hashes in the database like what happened with the leaked LinkedIn hashes.
- Attack any specific account trivially simply. Maybe there was a unique random salt with each simply hashed (e.g., MD5/SHA1/SHA2) password, but as you can try billions of possible passwords on any hash each second, so using common password lists, dictionary attacks, etc. it may only take an attacker seconds to crack most accounts. Use strong cryptographic hashes like bcrypt or PBKDF2 to avoid or key-strengthen regular hashes by a suitable factor (typically 10(3-8)).
- Attacks on guessable/weak “random” numbers. Maybe you use microtime/MT-rand or too little information to seed the pseudo-random number like Debian OpenSSL did a few years back.
- Attacks that bypass protections. Maybe you did hashing/input validation client side in web application and this was bypassed by the user altering the scripts. Or you have local application that the client tries running in a virtual machine or disassembles to reverse engineer it/alter the memory/ or otherwise cheat somehow.
- Other attacks, including (but not attempting to be a complete list) CSRF, XSS, SQL injection, network eavesdropping, replay attacks, Man in the Middle attacks, buffer overflows, etc. Best protections very quickly summarized.
- CSRF: require randomly generated CSRF tokens on POST actions; XSS: always validate/escape untrusted user-input before inputting into the database and displaying to user/browser.
- SQLi: always use bound parameters and limit how many results get returned.
- Eavesdropping: encrypt sensitive network traffic.
- Replay: put unique one-time nonces in each transaction.
- MitM: Web of Trust/Same as site last visited/Certificate issued by trusted CA.
- Buffer overflows: safe programming language/libraries/executable space protection/etc).
You are only as strong as your weakest exploitable link. Also just because you aren’t rolling your own scheme, doesn’t mean your scheme will be secure, it’s quite likely that the person who created what you rolled out was not an expert, or created an otherwise weak scheme.
Source
https://security.stackexchange.com/a/18198/28591
TLDR: don’t. And if you have to at least have the code (not the output) vetted by someone else, especially if you’re going to sell it. Those “someone else” obviously have to be someone who know what they’re talking about. First person to come to mind if this is PHP would be ircmaxell