Date: Sun, 10 Dec 2017 07:45:10 -0500 From: Jeffrey Walton <noloader@...il.com> To: oss-security@...ts.openwall.com Subject: Re: Re: Recommendations GnuPG-2 replacement Hi Marcus, Sorry to go off-list. Regarding: > 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). We had so many problems with Cmake we had to drop it. It accounted for nearly 20% of our bugs. We could not even set a "C++ project" (i.e., 'project(cryptopp, CXX)') without breaking Cmake. Also see https://www.cryptopp.com/wiki/CMake#CMake_Removal. Regarding: > 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... I think the library made a good design decision by moving secret key operations out-of-process and then interfacing through a message passing interface (i.e., Libassuan). In theory a compromise of the web server should not yield secret keys because the keys are in another process. Good luck with the replacement. I really like Jack Lloyd's Botan. Its a very nice library. Related, here are some of the upcoming engineering goals for Botan: https://lists.randombit.net/pipermail/botan-devel/2017-November/002242.html Jeff On Fri, Dec 8, 2017 at 7:47 AM, Marcus Brinkmann <marcus.brinkmann@...r-uni-bochum.de> wrote: > 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