17 Jul 2019, 10:44

Signing data

Somehow I have ended up reading lots of articles about how GPG sucks, not really sure I agree on, kinda enjoy using GPG, tho some of the comments are clearly warranted.

Oddly lots of focus is put on Signal and WhatsApp, I use both but I find them both to be quite a torment and trials of my patience. Super secure and all and forced to use android and apple. Who is to say that those software keyboards I'm using aren't leaking information about all the things I type anyways. But then again I don't care overly much about it and happily use hangouts to and still baffled by the fact that Google decides to give me commercials about Hamburgers after being a vegetarian for 10 years.

But on with the signing of information. I want to use detached signatures always, that way I could theoretically sign it with different programs and still keep control.


I have origfile.txt that has the following contents:

Hello World!

And I test failure of the file by lowercasing the first H to h.


Lets start here, I have already private, public and subkeys and use a smartcard to store the data, so wont go into writing about that, partly because I did it long time ago and I don't remember all the steps and would most likely mess something up.


Issue the command to sign, ASCII armored and detached like this:

gpg -sab origfile.txt

This generates an origfile.txt.asc:




To verify the file I issue the command:

gpg --verify origfile.txt.asc

This prints out:

gpg: assuming signed data in 'origfile.txt'
gpg: Signature made Wed 17 Jul 2019 11:00:13 AM CEST
gpg:                using RSA key CD43CCAE550A0A98CA76AA29A37072CDE5DA4998
gpg: Good signature from "Kent Gustavsson <kent@minoris.se>" [ultimate]

Neat it seams to have verified the file prints out my keys and lots of other information with the return code of 0

Messing with the origfile to try to invalidate the signature, issuing the same command for verification but it now yields:

gpg: assuming signed data in 'origfile.txt'
gpg: Signature made Wed 17 Jul 2019 11:00:13 AM CEST
gpg:                using RSA key CD43CCAE550A0A98CA76AA29A37072CDE5DA4998
gpg: BAD signature from "Kent Gustavsson <kent@minoris.se>" [ultimate]

And the exit code from the command is 1.

Looks usable.


This is a tool that was recommended in one of the bashing GPG articles I was reading. Looks to be what OpenBSD uses for signing its packages, I have never tried OpenBSD so I don't have any real idea how they are using it and how obvious it is that its being used.

Key generation

We will of course have to generate keys for signify like GPG, unlike GPG I'm going to explain how I did it because I want to have a reference my self:

signify -G -p key.pub -s key.sec

This will generate key.pub and key.sec, key.pub has the following contents:

untrusted comment: signify public key

The secret key I will not show to not encourage bad behavior.


To sign my text file I will now run this command:

signify -S -s key.sec -m origfile.txt

It will generate origfile.txt.sig and overwrite it if it already exists. It contained in my case:

untrusted comment: verify with key.pub


To verify my file I then run:

signify -V -m origfile.txt -p key.pub

It will automaticly assume there is a .sig file that it should check against. The output will be the following:

Signature Verified

With an exit code of 0

And again with trying to mess with it, it results in the following output:

signify: signature verification failed

And exit code 1, looks good and usable aswell. The .sig file has an untrusted comment section we could try to mess with that to and see if we get anything from that. But uppercasing the first V after the : gives as one would expect no failure, i.e. if it says its untrusted its untrusted.

Changing the text to trusted comment:

trusted comment: verify with key.pub

Gives the following result from the verification command:

signify: invalid comment in origfile.txt.sig; must start with 'untrusted comment: '

Witch in turn begs the question, if another line with trusted commend could be added, adding this right after the untrusted comment gives another error tho:

signify: unable to parse origfile.txt.sig

Adding it after the signature tho:

untrusted comment: verify with key.pub
trusted comment: Verify with key.pub

Its ok with and the result will be:

Signature Verified

This will be a thing that minisign will be using as will be seen down below.


Another tool to sign files, this one is a bit compatible with signify, to my knowledge they use the same algorithm but they differ how they store the private key and the signature file have a bit more content with minisign

Key generation

We need to generate keys:

minisign -G -p key.pub -s key.sec


untrusted comment: minisign public key FD9DD475D9711648


To sign we run command similar to signify:

minisign -S -s key.sec -m origfile.txt

This will generate an origfile.txt.minisig file:

untrusted comment: signature from minisign secret key
trusted comment: timestamp:1563358782 file:origfile.txt

More information here then in the signify file but this should be able to be verified with signify as well. Lets try:

$ signify -V -m origfile.txt -p key.pub -x origfile.txt.minisig
Signature Verified

Little more work here specifying the sigfile explicitly since it has an unexpected postfix for signify


Verification is done with the command:

minisign -V -m origfile.txt -p key.pub

Generates the output:

Signature and comment signature verified
Trusted comment: timestamp:1563358782   file:origfile.txt

Exit code is 0, some more output is generated here tho, timestamp and file name, this was the data that was presented in the .minisign file and is now verified to not have been modified. Lets start messing with things.

First lets try to mess with the origfile.txt and see what will happen, not the output is:

Signature verification failed

And the exit code is 1, neat.

If we mess with the trusted comment in the signature file this will be the output:

Comment signature verification failed

if we mess with both then the output is back to:

Signature verification failed

Signify trusted comment fail

Of course you can make the extra feature of minisig fail with signify, the trusted comment of minisig doesn't automatically gets verified with signify. As is explained in the minisid documentation.


GPG generates a lot bigger keys and signatures, this is a bit much at times, but GPG does a lot more then what signify and minisig attempts to do. With the entire key handling aspects removed. So its not easy to dismiss the advantages of GPG.

As seen tho one can use all of the above programs in parallel and sign your data with all, tho very little will be gained by using both signify and minisig. Personally I think minisig adds complexity thats not really needed for what its trying to do. Would much more have liked to see some kind of key chaining implementation. But I suspect that it quickly will become complicated.

Don't think anyone should stop using GPG, atleast not just yet. It has advantages like everyone knows what it is. And its specified how to handle the keys different chains of trust, and you can use the keys for encryption, signature and authentication. Tho I do not say that its rather cumbersome at times and not at all straight forward.

Signify is way easier to implement into code as well, looked at the code for the golang library for minisig https://github.com/jedisct1/go-minisign/blob/master/minisign.go and its quite easy to get confidence in the usage of that library instead of similar libraries for GPG.

The notion that Signal or WhatsApp is any kind of replacement for gpg I found truly ridiculus. I find both are next to useless for any kind of trust at all (easy to use so no bar for an imposter in hold of the phone to activate any key, the same company professing the security is also in control of the entire chain of usage, GPG would have to fool the email provider or other providers to get hold of the message, not only the gpg application it self and all the extra uses of the GPG application would look suspicious if it tried to send every message to the GPG developers, not tied to the phone that everyone carries around and leaves everywhere)