2
$\begingroup$

I will be making (in the near future) an app that will contain some pretty heavy crypto. As it is possible that my app will be ported to different devices (initially it will be iOs only, but Mac, Android & maybe even Windows ports will eventually exist). The question is how to make the crypto library as portable as possible. I'm thinking about writing it as a C11 header & .c implementation. That way it would be easy to integrate on every platform ( I may use Androids NDK to access the C code from Java). As I understand, Visual C++ can use C headers and functions. Then I will just write a wrapper class in the platforms default language (Objective-C 2.0 for iOs) that will access the cryptographic primitives from the C library...

  1. Is this an ok design?

  2. I will be using sleep() to make all operations last the same time (anti-timing attacks); does this work the same on all platforms? Should this be done in the wrapper rather than the C library?

  3. Should I use open source implementations of the algorithms, or just write my own? (I would like all the code in the crypto library to be 100% C11)

BTW: I'm going to use some non-standard algorithms that most public libraries don't have (Serpent, TwoFish, ThreeFish, as a key derivation function I'm thinking about scrypt) ...

Improve this question
$\endgroup$
8
  • 2
    $\begingroup$ I don't understand how the sleep function can help you prevent timing attacks : how do you know how much time you need to sleep ? Also if your using the worst case running time as a reference you need to know what it is precisely on the platform your library is running which requires fine tuning after every install which. May I ask why you're not using and existing library (NaCl, openssl ect) ? $\endgroup$
    – Alexandre Yamajako
    Apr 29, 2013 at 13:13
  • $\begingroup$ Or you could just use existing portable crypto solutions (yes, yes, there are some). By the way, using sleep() won't do anything against side channel attacks, an attacker will be able to distinguish the processor sleeping from the processor actually doing crypto work. $\endgroup$
    – Thomas
    Apr 29, 2013 at 13:14
  • $\begingroup$ @Thomas, not if all they have access to is say network traffic, right? How would they be able to distinguish a sleeping processor vs a proc doing crypto work? I agree that if they have physical access to the device your statement is true. Not sure if that is something the OP is worried about, however. $\endgroup$
    – mikeazo
    Apr 29, 2013 at 13:17
  • $\begingroup$ @mikeazo Yes, with only network access it wouldn't be possible, I agree with you, though for handheld devices I would assume physical access is rather easy. But the question is quite vague on the intended threat model. $\endgroup$
    – Thomas
    Apr 29, 2013 at 14:34
  • 3
    $\begingroup$ If you think that adding calls to sleep is a good way of preventing timing attacks against a C library, you have absolutely no business implementing your own crypto. $\endgroup$
    – Stephen Touset
    Apr 29, 2013 at 16:46

2 Answers 2

Reset to default
4
$\begingroup$

Almost all other languages can call C code, so using C is a safe bet. Serpent, Twofish, Threefish and scrypt all provide C implementations. (See the links.) Some even provide optimized code. Writing objC or C++ wrappers seems unnecessary since both can call C funtions.

The sleep(3) library function is part of POSIX. So you'll find it on linux, mac, *BSD but maybe not MS Windows. POSIX systems generally also have nanosleep(2) which has much better granularity (nanoseconds instead of seconds). But as others mentioned, it is possible to differentiate between a process that is sleeping and one that is actually working. It might be better to do some work to fill up the time. (e.g. check if a large random number is a prime, invert a big random matrix et cetera)

Writing your own implementations is definitely not recommended. Errors in the reference implementations will generally be found, publicly discussed and fixed. Who is going to fix your code if you don't publish it? And I would suggest using the reference implementations as-is, unless your changes pass all the existing tests.

Improve this answer
$\endgroup$
0
6
$\begingroup$

It's generally strongly recommended you use an existing library for your crypto, instead of trying to reimplement it. One big advantage of a widely used existing library is that it's been improved over time to deal with new threats. You may be aware of timing attacks as a current weakness, but these libraries have already solved those problems and many others, and fixed them.

OpenSSL is written in C, widely used and trusted, and could meet your needs. Cryptlib is distributed under the Sleepycat license (sort of compatible with the GPL) and is also written in C, and has a paid support team. GnuTLS is LGPL, if you really want GPL compatibility.

Improve this answer
$\endgroup$
5
  • $\begingroup$ I don't want GPL code at all... I need proprietary code... my own .. :) $\endgroup$
    – user1028028
    Apr 29, 2013 at 15:33
  • 1
    $\begingroup$ "Need"? That sounds like a severe case of Not Invented Here syndrome, and is the bane of secure systems. What you "need" is a valid business case. What is your business reason for writing your own? Money? Consider the potential for loss and lawsuits if someone breaks your home-written system. Pride? Pride does not deliver value to your customers. Fame? You'll certainly get notoriety if your system is broken, but that's not the same as fame. Learning? That's a valid reason for you, but don't inflict it on your customers. $\endgroup$
    – John Deters
    Apr 29, 2013 at 16:08
  • $\begingroup$ I understand what you are saying... However (see the latest edit) most of what I need is not properly implemented in available sources. The code from the AES submission packages seem a little dated to me... And BTW do thous cipher implementations protect against timing attacks ? $\endgroup$
    – user1028028
    Apr 29, 2013 at 16:16
  • 1
    $\begingroup$ There was a weakness in OpenSSL that brought timing attacks to the attention of the IT industry at large a few years ago, and yes, they've been fixed. I don't specifically recall, but the code submitted for AES consideration was likely a reference implementation. I'm still uncomfortable with your "non-standard" reference above. Algorithms and protocols don't become standards until they've been studied and attacked mercilessly. Threefish, no matter how cool Bruce is, is not a standard, and has not been studied as well. Bruce would be the first to admit it. $\endgroup$
    – John Deters
    Apr 29, 2013 at 17:50
  • 3
    $\begingroup$ @user1028028 You asked for advice, and the advice you received has universally indicated that what you're doing is likely a poor idea, and that your "needs" appear to be completely incompatible with sound cryptographic practices. Do with that information what you will. $\endgroup$
    – Stephen Touset
    Apr 29, 2013 at 19:13

Your Answer

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

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