[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAH8yC8k08iF7oMgJ0DwQTq8nYS8spW2nP-Sn1yK672CK327h4w@mail.gmail.com>
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[1], 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.
>
> [1] 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.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
