I'm a regular developer and thus not a crypto expert. I'd like to use ECDSA as a library in a programming language, Idris, which still doesn't have one. I could, obviously, try and port a particular implementation of my choice, run some tests, and call it a day. But that sounds unprincipled for something that needs strong security.

Is there any standard procedure or best practices to guide a normal developer to implement such a thing properly, without falling on the "don't roll your own crypto" trap?

  • $\begingroup$ ECDSA signature generation is tricky, as if you get the random number generation wrong (and a small bias is enough), you can leak the private key. You might want to consider something like EdDSA (which avoids that particular rake-in-the-grass) instead $\endgroup$
    – poncho
    Aug 10, 2017 at 18:34
  • 2
    $\begingroup$ @MaiaVictor You could probably use something like libsodium with Idris's C FFI. Unless you're trying to do something like have, say, the entire thing implemented or represented in a lambda calculus (based on your optimal lambda calculus evaluation work I've seen). $\endgroup$
    – David
    Aug 11, 2017 at 0:27
  • 1
    $\begingroup$ @MaiaVictor What is "a language that can easily run inside other languages?" I don't think I've ever seen one of those. Javascript, Lua, Python, LISP... none of those are easy, and those are the easy ones that I know of compared to others like C, C#, or Java. I suppose you could implement it in brainf---k. That's easy to interpret. $\endgroup$
    – Cort Ammon
    Aug 11, 2017 at 0:55
  • 1
    $\begingroup$ @MaiaVictor In my experience, most compilers do go to a smaller intermediate representation (LLVM bitcode is probably the closest to what you're describing and somewhat widespread. The clang C and C++ compiler compiles to it and GHC, eventually, generates that by default, I believe). As far as using Idris's JS FFI here goes, it looks like there is a JavaScript version of libsodium. Speaking of LLVM, it looks like it was generated using Emscripten, which converts LLVM bitcode to JavaScript. $\endgroup$
    – David
    Aug 11, 2017 at 1:33
  • 1
    $\begingroup$ @MaiaVictor In order for very different languages to interact, you must destroy logical structure. Ultimately, the only thing that languages necessarily have in common are the instructions that end up being executed by the machine. Imagine trying to interface INTERCAL with Python (or INTERCAL with anything, frankly) at a high level, preserving high level structures. Or CUDA with Forth. Whether it's represented in lambda calculus or assembly, there will be enough of an impedance mismatch that you will need a manual FFI. $\endgroup$
    – David
    Aug 11, 2017 at 5:24

1 Answer 1


The best option is to avoid doing so as much as possible. Ideally, your language of choice will offer a wrapper around a battle tested library such as libsodium (or maybe bearssl one day).

Additionally, in a perfect world, the interface that the library/wrapper provides should be designed to make it difficult if not impossible for you as the developer to shoot yourself in the foot. For example, if generation of the nonce for some kind of CTR-like mode is left up to you and not handled by the libraries you're using, you probably want to use a different library.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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