-- Hopefully this question fits here --

Time and time again, there is always one person who asked about creating their own encryption standard/cipher, and we all agree to stop them early on because we all agree that it is very unwise to do so (such as preventing unknown or invisible weakness in their standard, etc.).

My curious question is: What about programming your own library of, let's say AES cipher, in your language of choice? It's not creating new cipher (still strictly adheres to AES cipher/algorithm), but just writing that algo in programming language of your choice (maybe do AES cipher again in C/C++ so we can use a new feature(s) built into new gen CPU and make it faster -> JUST EXAMPLE) or someone built a new programming language that has no AES library yet (and you want to contribute one). Is it still wise to do so?

  • $\begingroup$ You can join teams like OpenSSL and contribute. There should be a reason to implement AES in a new language to be helpful. $\endgroup$ – kelalaka Sep 29 '20 at 11:01
  • $\begingroup$ @kelalaka interesting that you brought up OpenSSL, since some people decided after heartbleed incident that it was better to just rewrite the whole thing again (and that's how we have LibreSSL (which is now under OpenBSD project) and BoringSSL (by Google)). So, is it wise for them to do that? Or is the better solution would be to contribute to OpenSSL and not make competing SSL library/-ies? $\endgroup$ – Jacobson123 Sep 29 '20 at 11:13
  • 2
    $\begingroup$ Well over the time it was a mess code. With the TLS 1.3 cleanup, it can be better. Nobody knows that others won't have, too. So there are two paths; help the OpenSSL to become better or join the other ( if possible ) to become the one. $\endgroup$ – kelalaka Sep 29 '20 at 11:17

What about programming your own library of, let's say AES cipher, in your language of choice?

Implementing AES yourself in a correct way isn't too hard. The specification is well-written, contains illustrations and intermediate test vectors so that essentially anyone can do that.

What is tricky for AES and the reason why it's generally ill-advised to write a production-ready implementation yourself is to write an implementation that is reasonably fast and (/or) resistant to common software CPU side-channels.

If you still want your language to have an AES implementation the usual way to go would be to use the foreign function interface to call into a C-based AES library.

As for implementing AES yourself, if your language compiles to machine code there's usually a way to access intrinsics for AES and with those usually there is little that one could do wrong - apart from not properly allowing the CPU to pipeline the instructions.

If you don't have a machine-code-compiled language and / or your target CPU doesn't have hardware AES instructions things get more tricky. You need to ensure that whatever you write in your language doesn't do some weird things during interpretation / just-in-time compilation to accidentally introduce extra instructions. You need to ensure that the implementation always takes the same amount of time independent of the key and data used. You need to ensure that the previous step is not actually potentially messed up by the interpreter / JIT compiler / CPU. You also need to ensure that your memory access patterns do not depend on secret data. Most of these points can be fixed, e.g. using bitsliced AES implementations, but this is of course far from a trivial task - especially if you want the implementation to be reasonably fast.

  • $\begingroup$ Truth be told, i wrote AES only because it's popular enough to convey this question. There are some good ciphers that can be made available as library for more language (example Argon2, which is now getting traction for pass hashing & verify in PHP replacing bcrypt), or maybe something like OpenSSL debacle after heartbleed, where people instead fork it and rewrite the implementation (to be LibreSSL and BoringSSL) instead of improving the original project. However, i think your explanation on the last paragraph summed it very well what are the pitfalls and dangers ahead. Thank you :) $\endgroup$ – Jacobson123 Sep 29 '20 at 12:54

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.