Caddy: Cryptographic Signatures for Releases?

[paragonie-scott]

I'd like to verify that the copy I am downloading is authentic, particularly in deployment scripts.

Ideally:

mkdir /tmp/caddy && cd /tmp/caddy
wget https://github.com/mholt/caddy/releases/download/v0.8.3/caddy_linux_amd64.tar.gz.asc
wget https://github.com/mholt/caddy/releases/download/v0.8.3/caddy_linux_amd64.tar.gz
gpg --fingerprint $MHOLT_GPG_FINGERPRINT
if [ $? -ne 0 ]; then
    echo -e "\033[33mDownloading PGP Public Key...\033[0m"
    gpg  --keyserver pgp.mit.edu --recv-keys $MHOLT_GPG_FINGERPRINT
    gpg --fingerprint $MHOLT_GPG_FINGERPRINT
    if [ $? -ne 0 ]; then
        echo -e "\033[31mCould not download PGP public key for verification\033[0m"
        exit 1
    fi
fi
gpg --batch --verify caddy_linux_amd64.tar.gz.asc caddy_linux_amd64.tar.gz
if [ $? -eq 0 ]; then
    tar zxvf caddy_linux_amd64.tar.gz
    # Then continue to deploy...
else
    echo "Bad PGP signature"
    exit 1
fi

[mholt]

Indeed, something like this is what I want to implement with the new build server in the future.

[paragonie-scott]

You could do it manually today. All you would need to do is:

1. For each .tar.gz, etc. in the Github releases, sign them with GPG to get an associated .asc file containing the signature.
2. Upload the .asc along with each tarball. (You can rename them to *.sig if that makes it easier for people to associate.)

I noticed you do sign your git tags. That's excellent. :)

[paragonie-scott]

An easier way might be:

1. sha384sum all of the release files.
2. GPG sign a checksums file.
3. Upload the file and its associated signature.

We can then just GPG to verify the installs, then sha384sum -c to verify the checksum on each tarball. That means less clutter in the releases page, but equivalent security levels.

(SHA-384 isn't vulnerable to length-extension attacks like SHA-256 and SHA-512 are.)

[tdsmith]

Aren't length-extension attacks irrelevant in this application?

[paragonie-scott]

Length extension attacks are relevant when you know M and H(M) and you want to create M' such that H(M') = H(M) and H() is vulnerable to length extension attacks.

[tdsmith]

You're describing a hash collision attack and that would indeed make sha256 useless. My understanding was that length extension attacks are relevant when you know H(K+M) and M, do not know K, and wish to predict a hash H(K+M+M') for a message M+M'; they are why HMACs are useful constructs for guaranteeing message authenticity.

[paragonie-scott]

Let's make this easy:

• Write-up
• Exploit tool

Yes, they're most useful when you have an unknown key prefixed to the message, but they work just as well when you know the entire message and there is no unknown key.

There's no downside to SHA384, but if you can use SHA-512/256, use that instead.

[FiloSottile]

Length extension is fully irrelevant in this scenario. All the messages (the binaries) are public, so the attacker can just as well calculate a SHA-512/256 of the "extended" message. But what they can't do is then fake the GPG signature.

[paragonie-scott]

@FiloSottile I was suggesting make a file that contains the hashes of each binary, then sign the file.

You can't forge a signature, but if you can collide a signed hash you could bypass validation. So using a hash function for which you cannot easily create a collision via LEA is a good hygiene step to take.

That's all I was getting at.

[tdsmith]

Right; the length-extension property does not let you generate collisions. :) Sorry for the pedantry; it was borne of personal curiosity since Homebrew uses sha256 hashes to verify binary integrity and I wanted to make sure I hadn't missed an important caveat.

[mholt]

Any opposed if I use the key at https://keybase.io/caddy ?

[mholt]

This has been implemented on the new build server which is still under construction. Thanks for the discussion everyone!