[epoint] [issue] Verifiability of transaction database correctness

From: Daniel A. Nagy <nagydani_AT_epointsystem.org>
Date: Sun, 15 Jul 2012 02:17:15 +0200

Hello,

One of the design goals of our system was to make as much of its
consistency and correctness verifiable as possible using open (and
trusted) tools written by others, with no connection to our system.

In particular, we chose OpenPGP for cryptography and it's most widely
used implementation, GnuPG for its verification not because these are
perfect (far from it; they suck in many ways), but because they are the
best standard and open tool that are available and in wide enough use to
be sufficiently good not only in theory and/or plans but also in
practice. Nowhere near perfect, but good enough.

There are two things that can be verified with gpg: the signature on
certificates and their hash value (without the signature). The reason
why the hash value does not include the signature is because OpenPGP
signatures can be altered without changing their correctness and
therefore it could result in the creation of documents for which it is
not clear whether they are part of the legitimate public record or
forgeries, as they cannot be retrieved by their hash. The hash value of
the body of clearsigned documents is immutable by definition.

The body of the clearsigned document can be obtained by piping the
document through gpg. It does, unfortunately, add a newline to the end
of the hashed content. Thus, right now piping the cert through gpg and
calculating an sha1 hash gives a different result than the reference
hash of the cert. That prevents simple verification using command-line
tools.

This issue obviously has two satisfactory solutions: change the server
to include and extra newline in the reference hash or to change gpg not
to emit an extra newline for the body of clearsigned messages. While
theoretically the latter is obviously more elegant (that newline is
entirely superfluous and clearly not part of the signed document), in
practice the latter is our only reasonable option, unless gpg was broken
recently (which I believe not to be the case, but I might be wrong). So,
I propose to change the transaction server in such a way. I can provide
the patch, if necessary.

Any thoughts or comments?

Cheers,

-- 
Daniel

Received on Sun Jul 15 2012 - 02:17:15 CEST

This archive was generated by hypermail 2.3.0 : Sat Sep 14 2013 - 19:00:03 CEST