1
$\begingroup$

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?

$\endgroup$
14
$\begingroup$

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.

More importantly

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).

"Unbreakable encryption"

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 want to succeed

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.

$\endgroup$
  • 2
    $\begingroup$ "It's inappropriate to encrypt passwords." That depends on the use case. For authentication, you are absolutely right. For storage (e.g. for a password manager), reversible encryption is a necessity (technically you could store the passwords in plain text and need no encryption, but that would be beyond stupid; with encryption, reversibility is a requirement for this use case). $\endgroup$ – a CVn May 3 '18 at 9:40
  • $\begingroup$ As for "there exists a non-negligible probability of failure", as opposed to a lot of other software development tasks any serious published cryptographic algorithm will have plenty of test vectors published which you can write unit tests around before you even write the first line of implementation. Iff OP isn't worried about things like sidechannel attacks, then symmetric encryption and hashes are probably among the easier parts of an overall solution to implement. It'd likely be hard to mess up symmetric crypto to the point of vulnerability; asymmetric crypto is another matter, though! $\endgroup$ – a CVn May 3 '18 at 9:44
  • 2
    $\begingroup$ @MichaelKjörling Actually, it is very easy to mess up the implementation of even symmetric crypto to the point of vulnerability, for example by neglecting to use constant-time operations and opening your implementation up to timing attacks... $\endgroup$ – Sean Burton May 3 '18 at 14:11
  • $\begingroup$ @SeanBurton I specifically qualified that statement with "iff OP isn't worried about things like sidechannel attacks". Timing attacks definitely count as sidechannel attacks to me. $\endgroup$ – a CVn May 3 '18 at 14:16
  • 2
    $\begingroup$ Fair enough, they are a side-channel attack. Not sure whether you include padding, modes, key generation, etc within part of the symmetric encryption, or whether you consider them other parts of the overall solution, as there's plenty of other ways those could get messed up (using ECB, reusing IV or counters, using a bad RNG, using insecure padding or not validating the padding, etc). $\endgroup$ – Sean Burton May 3 '18 at 14:40
3
$\begingroup$

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:

some cryptanalytic attacks on block ciphers (and year of publication)

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):

Visualizing the problem with DIY crypto.

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?

$\endgroup$
1
$\begingroup$

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.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.