

Ask HN: Is it time for a public GPG audit? - anotherhue

With GPG being a common destination for those concerned by the recent privacy revelations, it bothers me a little that I can&#x27;t find any audit or security review of GPG&#x27;s codebase.<p>The Wikipedia page says that a German IT ministry funded a windows port, the EU Agency for Network and Information Security list GPG as part of their index of tools and claim it&#x27;s in use by some related parties [0] but don&#x27;t go so far as to recommend it. Considering that several governments within the EU are allegedly complicit in the SIGINT scandal, I don&#x27;t think their word counts for much.<p>GPG is open source, but while the code is readily available the knowledge and background to determine its security is somewhat rarer. Would you be willing to contribute to a project to fund a public audit of the codebase? If so, what sort of people would you like to see participate.<p>[0] http:&#x2F;&#x2F;www.enisa.europa.eu&#x2F;activities&#x2F;cert&#x2F;support&#x2F;chiht&#x2F;tools&#x2F;gnupg-the-gnu-privacy-guard
======
tptacek
That's not really how "audits" work. Coordinated public audits are responsible
for a tiny fraction of all vulnerability discoveries. Most discoveries are
independent. There would probably be a fairly poor return on investment for
funding an official audit.

Bear in mind also that even though _you 've_ never heard of an audit of GPG,
GPG is actually a pretty high-profile target. Smart people have already looked
at that code pretty carefully.

Since GPG is an open source project, a better approach would be to find a way
to sponsor a bounty for vulnerabilities in GPG. But here too you'll run into
problems:

* It will take fo-re-ver to adjudicate what does and doesn't qualify as a serious finding. Google and Facebook manage this problem by hiring very smart vulnerability researchers and allowing them to come up with criteria pretty much by fiat. Here, you're going to end up in a 2-month-long argument about whether man page bugs are vulnerabilities because of the nature of the project.

* Output of these programs is nonlinear and unpredictable, so it'll be tricky to figure out how much money needs to be set aside to satisfy reward payouts. In the meantime: who holds that money? And where does it go when the bounty outlives its utility?

If you really want to do some good, consider starting a project (which would
require no funding) to either:

(a) Build a replacement GPG in a more modern development environment, _or_

(b) Annotate all of GPG's source code.

~~~
unimpressive
>(a) Build a replacement GPG in a more modern development environment

(c) Build a replacement GPG that developers can (easily) use as a cross
platform library.

~~~
dsl
This has already been done by people who understand the fundamentals of
crypto. Check out [http://nacl.cr.yp.to/](http://nacl.cr.yp.to/)

It is even available natively in Go
[http://godoc.org/code.google.com/p/go.crypto/nacl](http://godoc.org/code.google.com/p/go.crypto/nacl)

~~~
tptacek
I thought I might have been this site's loudest proponent of Nacl, but maybe
not? Here, though, Nacl isn't a useful suggestion; it isn't compatible with
PGP. (There is a project that wrapped PGP's UX around Nacl's crypto, but one
presumes it's virtually unused, since it can only talk to itself).

~~~
jlgreco
Nacl is good, but is Go a suitable language for crypto work yet? I understand
there were some reservations in the past, though I can't recall exactly what
those were.

~~~
Jayschwa
I think Go is in a bit of a chicken-egg problem right now w.r.t. crypto. I
recall one of the core devs saying you shouldn't use it for anything where
security really matters, because their implementation hasn't really had the
tires kicked. The tires probably won't be kicked as much with that sort of
suggestion though either.

~~~
dsl
Go serves HTTPS for many Google properties and is a first class citizen for
security applications internally.

~~~
Jayschwa
Good to know.

------
runlevel1
Git provides us with a great deal of transparency.

Here's an overview of GnuPG's committers:

    
    
      Werner Koch:      2677 commits over a period of 5764 days.
      David Shaw:       1197 commits over a period of 3807 days.
      Marcus Brinkmann:  202 commits over a period of 3753 days.
      NIIBE Yutaka:       53 commits over a period of 641 days.
      Moritz Schulte:     39 commits over a period of 1756 days.
      Timo Schulz:        29 commits over a period of 896 days.
      Stefan Bellon:      21 commits over a period of 765 days.
      Repo Admin:          9 commits over a period of 2634 days.
      Andrey Jivsov:       8 commits over a period of 37 days.
      Ben Kibbey:          6 commits over a period of 20 days.
      Neal Walfield:       5 commits over a period of 1 day.
    

So it looks like the codebase has been touched by remarkably few hands!

This doesn't negate the need for a code review of some sort, but it does
suggest that it would be difficult for an outside agent to silently introduce
changes in master without the core developers noticing.

EDIT: Formatting.

~~~
strictfp
I think it would be rather easy to infiltrate a development team, especially a
geographically distributed one.

~~~
unreal37
What about cracking the password to one of those people's Git account, and
then submitting a commit without anyone knowing? What if Github is compelled
by a National Security Letter to allow others to modify source files and erase
the logs for those changes? What if one of those guys is the next Sabu -
facing 50 years in jail unless they cooperate?

~~~
estebank
You realize that you cannot modify a commit's content without modifying the
commit hash for every subsequent commit?

Your attack would be practically impossible against a git repo.

------
rsync
It is time for a public OpenSSH audit.

Word on the street is the code is horrific and last I checked was not even
checked into git, in any way, yet.

~~~
LukeShu
It's not checked into git... because they use CVS.

~~~
anotherhue
The OpenBSD guys are usually pretty good at security, but does CVS have the
integrity verification of more modern RCS?

Since OpenSSH is probably responsible for more data than GPG, (the importance
of that data aside) I think you're spot on.

------
jpalomaki
Would it make sense to somehow record what was audited and by who, in "machine
readable format"? Something that would allow others to later check how much
the audited parts of code (or code that the audited part is relying) have
changed since the audit.

Could be for example just a simple message "Audited, file: aaa/xyz.c, checksum
3ea1b.. revision 1c030.." signed with auditors public key.

------
neur0mancer
It's always a good time for a revision of privacy/security tools.

------
Canada
Have a look at the changelog. It's not as if people haven't been looking at
it.

