make sure you downloaded the SHA512SUMS.sign from the same directory as the iso.

https://keyring.debian.org/

https://www.debian.org/CD/verify

https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/9.4.0+nonfree/amd64/iso-cd/

https://bits.debian.org/2016/08/debian-and-tor-services-available-as-onion-services.html

otherwise you will get BAD signature.

steps to reproduce:

# download the iso image with non-free drivers (yes it sucks non-free drivers are still giving the best hardware compatibility - sue your vendor for privacy breach)
wget https://saimei.ftp.acc.umu.se/cdimage/unofficial/non-free/cd-including-firmware/9.4.0+nonfree/amd64/iso-cd/firmware-9.4.0-amd64-netinst.iso

# download file containing the sha512 filename and checksums
wget https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/9.4.0+nonfree/amd64/iso-cd/SHA512SUMS

# download PGP signature of the public key
wget https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/9.4.0+nonfree/amd64/iso-cd/SHA512SUMS.sign

# this will give you an error message telling you what public key to download
gpg --verify SHA512SUMS.sign

# download the public key
gpg --keyserver keyring.debian.org --recv DA87E80D6294BE9B

# because you specified the keyserver it should be okay to use the short key ID
# which is otherwise no: problem with short key IDs 
# longer key IDs identify the key more precisely

gpg --recv 0xDA87E80D6294BE9B
gpg: requesting key 0xDA87E80D6294BE9B from hkp server keys.gnupg.net <- pgp uses this keyserver per default
gpg: key 0xDA87E80D6294BE9B: "Debian CD signing key <debian-cd@lists.debian.org>" not changed
gpg: Total number processed: 1
gpg: unchanged: 1
# verify the downloaded 
gpg --verify SHA512SUMS.sign SHA512SUMS
gpg: Signature made Fri 16 Mar 2018 09:58:41 PM CET using RSA key ID 6294BE9B
gpg: Good signature from "Debian CD signing key <debian-cd@lists.debian.org>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: DF9B 9C49 EAA9 2984 3258  9D76 DA87 E80D 6294 BE9B

# now you can procede to actually check the iso file:
sha512sum -c SHA512SUMS
# should give you
firmware-9.4.0-amd64-netinst.iso: OK

you are now good to go

if you downloaded the wrong SHA512SUMS.sign you will get:

gpg --verify SHA512SUMS.sign
gpg: Signature made Fri 16 Mar 2018 09:50:55 PM CET using RSA key ID 6294BE9B
gpg: BAD signature from "Debian CD signing key <debian-cd@lists.debian.org>"

testing:

what happens if one changes SHA512SUMS?

echo "file_was_changed" >> SHA512SUMS

gpg --verify SHA512SUMS.sign SHA512SUMS
gpg: Signature made Fri 16 Mar 2018 09:58:41 PM CET using RSA key ID 6294BE9B
gpg: BAD signature from "Debian CD signing key <debian-cd@lists.debian.org>"

how to sign a file:

create a gpg sign signature, so other people can verify the file is probably from the author and was not altered.

# sign
gpg -a --output file.sig --detach-sig file
# verify:
gpg --verify file.sig file

https://security.stackexchange.com/questions/73657/what-is-0xxxxxxxxx-asc-sig-and-how-can-i-generate-this

src: https://www.gnupg.org/gph/en/manual/x135.html

chain of trust:

How Do I Build Trust?

This is little complicated as you never met Igor Sysoev face to face. To vouch for the key’s authenticity you can do so by signing it with your own private key and mailing it back to its owner. This is simple and easy way to build a trust relationship. Another quick option is to use the following command:

gpg --edit-key {user@example.com} trust

Type the following command

gpg --edit-key igor@sysoev.ru trust

Sample outputs:

gpg (GnuPG) 1.4.9; Copyright (C) 2008 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

pub  1024D/A524C53E  created: 2009-09-04  expires: never       usage: SC  
                     trust: unknown       validity: unknown
sub  2048g/58AC2CDD  created: 2009-09-04  expires: never       usage: E   
[ unknown] (1). Igor Sysoev <igor@sysoev.ru>

pub  1024D/A524C53E  created: 2009-09-04  expires: never       usage: SC  
                     trust: unknown       validity: unknown
sub  2048g/58AC2CDD  created: 2009-09-04  expires: never       usage: E   
[ unknown] (1). Igor Sysoev <igor@sysoev.ru>

Please decide how far you trust this user to correctly verify other users' keys
(by looking at passports, checking fingerprints from different sources, etc.)

  1 = I don't know or won't say
  2 = I do NOT trust
  3 = I trust marginally
  4 = I trust fully
  5 = I trust ultimately
  m = back to the main menu

Your decision? 5
Do you really want to set this key to ultimate trust? (y/N) y

pub  1024D/A524C53E  created: 2009-09-04  expires: never       usage: SC  
                     trust: ultimate      validity: unknown
sub  2048g/58AC2CDD  created: 2009-09-04  expires: never       usage: E   
[ unknown] (1). Igor Sysoev <igor@sysoev.ru>
Please note that the shown key validity is not necessarily correct
unless you restart the program.d

Command> q</igor@sysoev.ru></igor@sysoev.ru></igor@sysoev.ru>

src: https://www.cyberciti.biz/faq/pgp-tarball-file-signature-keys-verification/

the problem with short KeyIDs: Short key IDs are bad news (with OpenPGP and GNU Privacy Guard)

every public key uploaded to a keyserver get’s an ID, this id can be short, medium and long.

short is: 6294BE9B

medium is: DA87E80D6294BE9B

long is: DF9B9C49EAA9298432589D76DA87E80D6294BE9B

short version:

https://sks-keyservers.net/pks/lookup?op=get&search=0x6294BE9B

medium version:

https://sks-keyservers.net/pks/lookup?op=get&search=0xDA87E80D6294BE9B

longer version:

https://sks-keyservers.net/pks/lookup?op=get&search=0xDF9B9C49EAA9298432589D76DA87E80D6294BE9B

different keyserver:

https://keys.gnupg.net/pks/lookup?search=0x6294BE9B&op=vindex


pub  4096R/6294BE9B 2011-01-05            

uid Debian CD signing key <debian-cd@lists.debian.org>

https://keys.gnupg.net/pks/lookup?search=0xDA87E80D6294BE9B&op=vindex

pub  4096R/6294BE9B 2011-01-05            

uid Debian CD signing key <debian-cd@lists.debian.org>

https://keys.gnupg.net/pks/lookup?search=0xDF9B9C49EAA9298432589D76DA87E80D6294BE9B&op=vindex


pub  4096R/6294BE9B 2011-01-05            

uid Debian CD signing key <debian-cd@lists.debian.org>

Summary: It is important that we (the Debian community that relies on OpenPGP through GNU Privacy Guard) stop using short key IDs. There is no vulnerability in OpenPGP and GPG. However, using short key IDs (like 0x70096AD1) is fundementally insecure; it is easy to generate collisions for short key IDs. We should always use 64-bit (or longer) key IDs, like: 0x37E1C17570096AD1 or 0xEC4B033C70096AD1.

TL;DR: This now gives two results: gpg --recv-key 70096AD1

If someone signs and encrypts their code or email with their PGP digital signature, you could, in theory, be sure they are who they say they are and their words or code are indeed their words or code. If they use a short (32-bit or smaller) key, they have no real security. In that case, a hacker can now easily forge a fake PGP signature. And that’s exactly what happened to Linus Torvalds, Greg Kroah-Hartman, and other leading Linux kernel developers.

On the Linux Kernel Mailing List (LKML), it was revealed that for the last two months, since about mid-June, „some developers found their fake keys with same name, email, and even ’same‘ fake signatures by more fake keys in the wild, on the keyservers“.

This isn’t a new attack. Linux programmers have known since December 2011 that short PGP keys IDs were inherently insecure. It’s just that no one bothered to break the PGP keys… until now.

In June, hackers Richard Klafter and Eric Swanson saw that GPG [a popular open-source implementation of PGP] usage had continued to grow, but people were still using short keys. On the site Evil 32, they state: „32-bit key ids were reasonable 15 years ago but are obsolete now. Using modern GPUs, we have found collisions for every 32-bit key id in the WOT’s (Web of Trust) strong set. Although this does not break GPG’s encryption, it further erodes the usability of GPG and increases the chance of human error.“

How bad is it? It took them four seconds using the scallion program to generate a colliding 32-bit key id on a run-of-the-mill graphics processing unit (GPU), such as a Nvidia GeForce GTX.

This is not an attack aimed at Linux. Indeed, no damage seems to have been done. As Kroah-Hartman, Linux kernel maintainer for the stable branch of Linux, explained on Google+: „It wasn’t just targeted at kernel developers, but at all 24,000 keys in the ’strong‘ ring of PGP trust, and yes something like this has been possible for a very long time now so it’s not really that much news, and yes, GPG really is horrible to use and almost impossible to use correctly.“

src: https://web.archive.org/web/20180103125630/https://www.zdnet.com/article/pgp-security-weakness-exposed/

admin