[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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[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.
