Date: Fri, 8 Dec 2017 13:47:56 +0100 From: Marcus Brinkmann <marcus.brinkmann@...r-uni-bochum.de> To: Ludovic Courtès <ludo@....org> Cc: oss-security@...ts.openwall.com Subject: Re: Re: Recommendations GnuPG-2 replacement On 12/08/2017 12:01 PM, Ludovic Courtès wrote: > Hi Marcus, > > Marcus Brinkmann <marcus.brinkmann@...r-uni-bochum.de> skribis: > >> I started neopg.io two months ago to provide a modern replacement for >> GnuPG. It will go back to a single-binary architecture like gpg1 was, >> but move forward on just about every other issue: >> >> * Written in C++ >> * based on the Botan crypto library instead of libgcrypt >> * typical library + CLI (with subcommands) architecture >> * better testing (CI, static analysis) > > Given that you worked on GnuPG, can you give some background? It isn’t > clear to me why using C++/Botan/CMake to give a “modern” feel (what does > it mean?) will lead to “better” software (under which criteria?). These should all be blog entries. In fact, I commented on CMake here: https://neopg.io/blog/why-cmake/ The short version is: cmake has much less boilerplate, more stable interfaces, and it is snappier to use during development. It is also well supported by all five major platforms (Windows, MacOS, Linux, Android and iOS). Efficiency is the major theme here. I am a good programmer, I can solve all the problems that C++, Botan and CMake solve for me. But it doesn't make sense, because then I would be bogged down in tangent issues that don't help the users. For C++: if you look at GnuPG source code, a huge part of it is about memory management. For example, there are several implementations of a dynamically growing string buffer (membuf_t, es_fopenmem, several ad-hoc implementations based on realloc). The iobuf_t filter/pipe mechanism is object-oriented. The libgcrypt API is object oriented. In theory, you can write nice code in any language. In practice, C++ has solved all these problems years ago, and the language is evolving to include new features (C++11, C++14, C++17), while C has stalled. With C++ STL and boost, you can kick out most platform dependent code. std::mutex and std::thread are now the same on Windows and Unix. Boost::locale replaces iconv and gettext. It is much more efficient to program in C++ than in C. (BTW, C++ is a compromise. I have a love-hate relationship with the language, but I am picking languages for the job at hand, and for a fork of GnuPG, it is the obvious choice to me). For Botan: libgcrypt is a major maintenance burden on the GnuPG project. There have also been several embarassing CVEs this year, and crypto researchers have commented negatively on Twitter. To justify that, you'd expect the library to be used by many. Unfortunately, libgcrypt has never seen much use outside the GnuPG project. The only other major user I am aware of was gnutls, which switched to libnettle in 2011 (http://lists.gnu.org/archive/html/gnutls-devel/2011-02/msg00079.html). I also don't like how libgcrypt handles entropy. It makes a difference between "weak" random and "strong" random, and it will block if it can't get enough "entropy" from the system. It is a very conservative approach, and leads to bad user experience. Botan on the other hand is actively developed, and provides several very useful interfaces that not only replace libgcrypt for me, but also the iobuf (pipe/filter) interface in GnuPG, libksba (GnuPG's ASN.1 parser and X.509 support library), and several parts in dirmngr (certificate cache). Oh, and it has TLS support, while the GnuPG project is currently working on its own TLS library ntbtls (which is based on an old fork of PolarSSL). The maintainer is friendly and the project is very active. It has also been audited (and continues to be audited) by a local IT security company in a contract with the BSI (German Federal Office for Information Security). They chose Botan after evaluating many candidates, I hope that the documentation for the project will eventually be released to the public, so we can all learn their reasons and have better documentation of Botan internals. > The multiple-process design in GnuPG had clear justifications > AFAIK—e.g., having ‘dirmngr’ and ‘gnupg-agent’ in separate address > spaces makes sense from a security standpoint. Do you think these > justifications no longer hold, or that the decisions were misguide? I am not per se opposed to a multi-process design, but I'd rather have short-lived processes that are started for a single task (like decrypting a single message) than long-running daemons. And I'd actually use operating system features to actively isolate these processes. This is a complicated discussion, but note that gnupg's implementation does not protect you from attackers who gain remote code access to any process running under your uid, so the only protection here is against accidental memory disclosure akin to heartbleed. And yes, heartbleed happened, so there is obviously some value to it, but so far it is a single incident. When it comes to prioritizing concerns, process isolation comes somewhere below memory safety, code efficiency, refactorisation, readability, etc. So I'd argue that the "clear justification" is not as clear as you make it sound. The GnuPG project is bouncing between "defense in depth" and "it's game over if your uid is compromised" without a clear threat model from which to derive a priority of concerns.  https://dev.gnupg.org/T1211 > I’m also skeptical about “better testing” bit: GnuPG and libgcrypt are > among the first pieces of software that crypto and security researchers > look at, and they’re also the first ones to get fixes when new attack > scenarios are devised. I agree, and that would be a good reason for GnuPG to use openssl! However, those researchers focus on the MPI multiplication in RSA, and not on the porcelain around it. >From a software engineering point of view: Does the current master version pass the test suite? What is the code coverage of GnuPG's test suite? Which compilers and platforms are tested? How often is the code base fuzzed? Is there any static code analysis done regularly? > I’m sure you have a clear view on this but neopg.io doesn’t reflect> that. Yes, I am lagging behind in documentation. I plan to write all this down, and much more. Thank you for your interest, Marcus
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ