Re: [epoint] [issue] Verifiability of transaction database correctness

From: Szabolcs Nagy <>
Date: Sun, 15 Jul 2012 11:56:18 +0200

* Daniel A. Nagy <> [2012-07-15 02:17:15 +0200]:
> 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.

yes this is a bug
it was not intentional and it worked at some point

> 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.

i will fix the document id calculation so
an extra \n after the body is included
in the document hash

but i think first i will upgrade to the
latest go1 release
(official, freezed go api)

that will include some changes to the code
(go1 changed how packages should be built
so files will be moved around and build
instructions will change)

so it will take some time
Received on Sun Jul 15 2012 - 11:56:18 CEST

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