Simple answer (and I know this is a simple yes or no) is it possible to write an encryption that is 100% uncrackable, as long as I keep certain parts private? It's just for personal use.
I'm a computer programmer and need my own encryption to encrypt things like my passwords. Is this possible so that its 100% uncrackable, or is it simply not possible?
I'm a computer programmer and need my own encryption to encrypt things like my passwords.
This does not imply that you need to write your own encryption algorithm. Being a programmer does not make you a cryptographer, cryptography is a skill unto itself that takes lots of experience and practice.
Plenty of experienced cryptographers have gone through the trouble of designing and analyzing algorithms for people in your situation, precisely so that you don't have to write your encryption algorithm.
It's inappropriate to encrypt passwords. Standard good practice dictates the use of a slow, memory-hard password hashing function such as scrypt or argon2 (or pbkdf2 at the very least).
is it possible to write an encryption that is 100% uncrackable, as long as I keep certain parts private?
The One Time Pad in theory provides information-theoretic security, which means that no amount of computational advantage or sophisticated algorithm can help an adversary who has a ciphertext learn more about the plaintext than they already know.
Using the One Time Pad in practice is clunky and prone to failure (and here's another Q/A supporting that conclusion if that was not sufficient). It is difficult to fulfill the assumptions that the proof rests upon, and so it is not used very often in practice despite the theoretical guarantees.
In practice, algorithms such as AES and Salsa20 will remain unbroken when implemented and used correctly.
While solid encryption algorithms do exist, encrypting passwords is a poor idea.
If you care about fulfilling your security goals, then it is a good idea to stick to battle-hardened algorithms and pre-existing software libraries that implement them. Libsodium is a solid recommendation.
Do not create your own implementation (except as a learning experience) - your information and/or your users information is at stake, and there exists a non-negligible probability of failure.
If you really expect it to be
… 100% uncrackable…
you’ll have to start by abandoning your “keep certain parts private” idea and assume that “the enemy knows the system”.
See Kerckhoffs’ principles – Why should I make my cipher public? for details on that one.
And that is just the beginning of a long journey on your way towards creating your own cryptographic solution. Besides, good programmers use well-vetted cryptographic algorithms instead of reinventing the wheel – which comes with a truckload of pitfalls if you don‘t have in-deep knowledge of algorithm design as well as cryptanalysis.
See, there are many way to attack cryptographic solutions and chances are high that you’re not aware of those attacks, how they work, and what a specific algorithm needs to prevent them. That in itself is already a reason not to start creating your own unless you really know what you are doing. And that tends to end up with learning a truckload about algorithm design and cryptanalytic attacks.
For example, when it comes to block ciphers, you’re facing cryptanalytic attacks like:
Note that this isn’t even considering other important things like authentication (encrypt-then-MAC) and stuff yet.
There‘s this saying along the lines of “first learn to break it, then you can try to create it”, which boils down to: you can’t create a secure cryptographic algorithm unless you know all the ways it could be attacked – and actively construct your algorithm to prevent such attacks as good as possible. If you don’t, you’re bound to fail because you might close and lock a door while leaving a window wide open.
Fact is that you have to be able to apply the latest attacks to your newly designed crypto algorithm to ensure it is immune to the present day attacks.
To visualize this problem in a much simpler way (quoting myself):
As said: good programmers use well-vetted cryptographic algorithms instead of reinventing the wheel. There are ample good solutions to almost every cryptographic problem out there; especially for encryption purposes. So, there really is no need to create your own (which is bound to end in a security disaster if you don’t have the according knowledge and experience).
For further reading, check “Why is writing your own encryption discouraged?”
Simple answer is no. Even though the encryption algorithm is keep in secret, there are bunch of works(cryptanalysis) to break such a "black box" encryption algorithm. But when you design encryption algorithm(block cipher in this case), you have to evaluate your cihper against from known attack methods. I hope this might help.
