2

I came across DJB's Curve25519 implementation site (https://cr.yp.to/ecdh.html) and noticed he states in reference to using it:

You can and should include it in your own programs, rather than going to the effort of linking to a shared library; the compiled code is around 16 kilobytes, depending on the CPU

I assume by this he means to static link the lib in your program which seems odd to me from a security perspective. Would it not be safer for your crypto code library to be a shared lib so if there is ever an implementation vulnerability it would be much simpler to patch it instead of recompiling all the dependent programs?

Neil Smithline
  • 14,621
  • 4
  • 38
  • 55
Anthony Kraft
  • 1,139
  • 1
  • 8
  • 18

2 Answers2

4

Using a shared library is a good idea for getting security fixes without having to recompile all the applications that use the library -- but this holds only if there is indeed a shared library that several applications use, and that is actively maintained by somebody else.

In an ideal world, you would not even download the source code for the Curve25519 implementation. You would use the OS-provided package that contains the shared library. If a bug were to be found, it would be corrected upstream and the packager would publish a new, fixed version, that your application (and others using the library) would automatically benefit from the fix. It would have similar benefits for performance (e.g. if a new, faster implementation more optimized for your current hardware is produced).

However, such a package does not exist for the moment. DJB does not appear to be willing to maintain such a package, for any version of any OS (in fact he has been quite vehemently opposed to how most if not all package managers work; he also expressed misgivings about shared libraries). If you use the code, then you are importing it in your application, and the maintenance effort, i.e. keeping track of changes and propagating fixed versions, will fall squarely on your shoulders. Even if you make it a shared library, it will still be your shared library, not shared with any other application. You might as well link the code in; it won't change things for security, and it will be simpler.

Tom Leek
  • 168,808
  • 28
  • 337
  • 475
  • The solution is obviously to use a shared library and convince others (such as your distro) to maintain it. – Ángel Feb 23 '16 at 23:54
-1

On one hand it's easier to update if a vulnerability is found, but on the other hand, it's easier to update with a backdoor and now the backdoor will exist system wide in whatever binaries are dynamically linking to it.

d1str0
  • 2,348
  • 14
  • 24
  • I had not thought of that angle before, but surely we put greater emphasis on ability to patch future systems over the thought that a backdoor could be placed somewhere. This is assuming we only install software from trusted sources. – Anthony Kraft Feb 23 '16 at 21:15
  • I think if someone's crypto is found to be vulnerable, the application is way more likely to release a new version than waiting for someone to patch a library on their system. – d1str0 Feb 23 '16 at 21:31