make sure you downloaded the SHA512SUMS.sign from the same directory as the iso.
https://www.debian.org/CD/verify
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 # or manually specifying the internet hosted keyserver gpg --keyserver pool.sks-keyservers.net --recv-keys 0xDA87E80D6294BE9B gpg: data source: http://hkps.pool.sks-keyservers.net:11371 (1) F-Droid <admin@f-droid.org> 4096 bit RSA key 0x41E7044E1DBA2E89, created: 2014-04-25 Keys 1-1 of 1 for "0x41E7044E1DBA2E89". Enter number(s), N)ext, or Q)uit > 1 gpg: key 0x41E7044E1DBA2E89: public key "F-Droid <admin@f-droid.org>" imported gpg: Total number processed: 1 gpg: imported: 1 # it might be "okayish" (better-than-nothing-approach) to trust a public keyserver # it might be better to publish public_key.file next to the file to download # and then directly download public_key.file and import it like gpg --import public_key.file # 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
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.”
liked this article?
- only together we can create a truly free world
- plz support dwaves to keep it up & running!
- (yes the info on the internet is (mostly) free but beer is still not free (still have to work on that))
- really really hate advertisement
- contribute: whenever a solution was found, blog about it for others to find!
- talk about, recommend & link to this blog and articles
- thanks to all who contribute!
