I'm going to implement a small crypto lib/tool. The "do not implement crypto by yourself" rule does not apply here, since this crypto system is new and not implemented yet. ;) So the first step is the choice of the implementation language. And my question here is, if there are reasons to prefer one over another.

Since it has to be efficient, I sympathize with C or C++. And with C or C++ it should be easy to create bindings for other languages like Java or Python, later.

So if you agree with me, that C or C++ is nice for this purpose, lets focus on C vs. C++.

C may be a bit simpler and the lack of stuff like objects could help avoiding critical bugs. On the other hand, C++ might offer the ability to do some things in an easier way. Like the use of the C++11 random device for cryptographically secure random numbers (e.g. from /dev/urandom). Or exception handling etc.

There are probably more points. But maybe the choice isn't that important?!

What are your thoughts?

1 Answer 1


Choice of programming language for cryptography depends on a lot of parameters, including (but not limited to) the following:

  • If the goal is to support research (e.g. to try variations) then the language should be one that is most mastered by whomever will do the research. For instance, people who want to "investigate crypto" and feel most comfortable with Python will use Python.

  • If the goal is to serve as a pedagogical tool, e.g. for a reference implementation of a new algorithm, then a widespread language with clear semantics should be preferred. Cryptographers have long used C for that job, but, arguably, Java or C# would be better choices since they have much fewer "dark corners".

  • If the goal is efficiency, then the target architecture is of paramount importance; for instance, many embedded platforms support only (a subset of) C, and any implementation will have to be more or less directly implemented in C (automatic translation from other languages is possible but requires work). If you have the choice, then compiled languages (e.g. C) and languages with efficient JIT compilers (e.g. Java, C#) are appropriate.

  • If the goal is maximum efficiency, and you want to run in the least possible number of clock cycles, then some assembly will be needed. This hardly matters in practice, outside of microbenchmarks (in most practical applications, memory and network bandwidth are the bottleneck, not cryptography), but it is a fun exercise.

  • Most cryptographic algorithms process secret elements (e.g. keys) and may be vulnerable to side-channel attacks. Preventing such attacks requires intimate knowledge of all the arcane management of cache memory, jump prediction and other subtle details. Implementations which are robust against such attacks are awfully difficult to build, but the problem becomes easier (not easy, just easier) with a lower-level language. Hence, assembly or C (with C, you still have to understand what is going on at the assembly level). Arguably, if you know enough to implement a side-channel-free cryptographic implementation, then you already know that...

  • If you are weary of life, use C++.

Personally, I have implemented cryptographic algorithms for various goals, including research, pedagogy and efficient production-level code (currently deployed in the field) in C, Java, C#, Forth, a dozen of assembly dialects, and a few other languages. None of these languages was "better" than the others in an absolute way; it is all a matter of context.

  • 3
    +1 for "If you are weary of life, use C++."
    – user10211
    Commented Feb 3, 2014 at 5:24
  • Thank you very much for your answer. :) Could you please justify the C++ point. That's what I'm most interested in and I'm curious if it is just the "I hate C++" attitude or if there are reasonable reasons to avoid C++ here. ;-)
    – firefexx
    Commented Feb 3, 2014 at 11:19
  • 3
    Language preferences are always a matter of opinion. However, in the case of C++, it is a complex language, with semantics full of dark corners and unspecified behaviour, for the sake of retrofitting an object layer into the C syntax, which, for some reason which is beyond me, has been deemed "natural". The object layer is mostly useless for crypto. C++ compilers, as a rule, have bugs and produce mammoth unreadable error messages.
    – Tom Leek
    Commented Feb 3, 2014 at 13:33
  • A subset of C++, more appropriately called "C with classes", can be used, but it has little advantage over plain C. Crypto code is very procedural; in fact, you want it to be procedural with the least possible compiler magic, so that you may tame and remove side-channel leaks.
    – Tom Leek
    Commented Feb 3, 2014 at 13:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .