[General Topics] atErik:
GPG / PGP Based File Integrity And Actual File Author Authentication / Verification

[SIZE="+1"]How to verify a file's integrity & same file's author/developer, both/etc all at same time ?[/SIZE]

A Brief/Short ([SIZE="+1"]PGP / GPG[/SIZE]) Summary is:​

When we carry out a file's checksum/hash verification process, or a file's integrity checkup process, then this process makes sure if the file under investigation, whether has correct & intact (md5/sha1/sha256 etc) integrity or has got modified/altered, it answers or clarifies ONLY those area or aspect. An integrity verification process does not verify a file's author, and does not verify if the file has correct byte-size or not.

When only checksum/hash/intergrity code is shown & obtained from a popular HTTPS based (encrypted) website webpages, then it has suffice (a minimum low-level of) security or suffice (a minimum low-level of) trust-level, but Not One-of-the-Best (O-o-t-B) security-level or O-o-t-B trust-level. Because, it does not tell or indicate & does not PROVE to users/visitors, WHO EXACTLY made that file (aka, Which exact developer developed that file, or Which exact author created that file), AND, it (checking only hash-integrity) also does not prove WHAT'S the actual file size (which was released by the actual-&-original developer or author).

So, to verify a main file's integrity, and to verify the actual maker/creator/author/developer/releaser of main file, and to verify if the main file has correct size, ... any shared main file must also have a (PGP or OpenPGP or GPG based) "signature" file (aka, "sig" or "asc" file), and such file must be shown next to the main file download link. And a "signature" file (it is a very small file, usually under 8 kilo-bytes) must be delivered to user/visitor over a HTTPS encrypted connection. And then, main file can be delivered to user/visitor over any type of open or not-encrypted connection, (or even over any encrypted connection).

And for this to work, user/visitor also needs the FILE-SIGNING public (aka, pub) KEY, which was used to create the signature-file (SIG or ASC). And user must obtain it over a HTTPS encrypted webpage or connection. So, developer or author MUST SHARE file-signing GPG/PGP pub-key over an encrypted webpage or file, shared from their OWN main/source website/server (it means, pub-key MUST be shown from a such Server Computer which the original developer/author has full-control & kept in their/his/her own office/home, it means, Beside the original author/developer NONE-OTHER have any-control on it. And original author/developer MUST ALSO OWN the SSL/TLS certificate for the sub-domain or main domain used in that server). When a File-Signing Gpg/Pgp/OpenPgp Pub Key is shared/shown from a Mirror or CDN or hosting or Cloud Hosting server or Forum website or shared project site (like Github, SourceForge) etc 3RD-PARTY websites, or, When pub-key is shared/shown over open/unencrypted connection like FTP or HTTP etc, then such Gpg/Pgp pub KEY has "ZERO" (aka, NO, none, nada) security. When used all components or all tools or all factors/vectors or all connection or all software or all portions, etc ALL & each, are secured (encrypted & verified & authenticated), to keep the security-level & trustworthiness-level checked at a Fully/Totally/Completely-"TRUSTED" level. If EVEN-ONE of the "SINGLE" used tool/portion/factor/vector is NOT WHAT is mentioned previously, then it is NOT-TRUSTED (aka, NOT-SECURED), or Not-Fully-Trusted, or Not-Totally-Trusted, or Not-Completely-Trusted, etc. We also need to realize, Reaching an absolutely "Trusted"-level (for infinite amount of time duration into future) may not be possible in real life (with finite amount of resources), So we MUST need to TRY AT-LEAST to reach a "COMPARATIVELY-MORE TRUSTED-Level" or "COMPARATIVELY-MORE SECURED" level, FOR "SIGNIFICANT" AMOUNT OF TIME (INTO FUTURE), so that, those who are "REMOVING-TRUST" (or those who are "DECRYPTING & STEALING" private-data), CANNOT COMPLETE decryption+theft process for SIGNIFICANT amount of TIME DURATION, so that we can avoid assist them in decrypting+stealing our private-data, so that we can make it MORE-HARDER for them to decrypt+steal our private-data. Always use most strongest encryption, because each new computing hardware, in each 12 to 18 months, is becoming double-time powerful & capable than before, to decrypt quickly. Encryption is like a cloth/jacket/envelope (a wrapper/cover) for digital data packet, we use cloth/dress on a civilized human-body for privacy & decency & for protection of body, and we use envelope when we send private/personal mail via post-office, to a destination person's address. HTTP/FTP/POP/SMTP/IMAP etc is like sending or mailing a postcard, which is open, anyone can see+steal+record. But, HTTPS/SSH/VPN/PGP/GPG/IMAPS/POPS/SMTP+STARTTLS etc is encrypted, it is like sending an enveloped mail or using a non-transparent tube for data-transfer or communication. Read the top-most 1st post (in this forum topic thread), to understand more on Encryption, Decryption, Privacy-Rights, Civil-Rights, etc.​

Non-encrypted data packets are faster, because its easier & faster to generate non-encrypted data packets, as such data packets require lesser computing & lesser processing & lesser verification. Generation of Encrypted data packets are computing resource consuming, and thus time consuming, (inside the server computer which will generate it), as these type of encrypted data packets are intended & directed toward certain specific & different destinations, and each destination's encrypted data packets need to be different & unique than other destination. Once encrypted data packets are generated, then transfer process of it via/thru other computers, is comparatively less resource consuming.

Public = pub. Openly available for any public/person. for public use, for general use, for open use.

Private = prv = priv = pvt. Private or personal or secret portion-&-use purpose, it is Not for public/general eyes.

A file's author/maker/developer need to load an OpenPGP or GPG or PGP software, and create an openpgp/gpg based (encryption) key-pair for file-signing purpose, and keep the "private-key" (or "secret-key") portion private (in an external write-protectable SD flash-memory media/storage drive or inside a secured read&write-protected Keyring or Keychain usb device), and then author/dev can share the file-signing "public-key" portion (aka, public-key-file) of file-signing key-pair, with the users/visitors over a HTTPS encrypted secured webpage.

Some dev/author may also choose to "sign" files, with their own primary identity pub-key-file profile. Portable apps (like, email client software, portable gpg/pgp/openpgp software/tools, etc) can be kept in a portable usb storage device or in a (write-protectable) flash memory media/storage card. These "portable" software must not write into or use host computer's storage media, for better security. Multi partitions can be created inside external storage media/cards, for storing "secret"/"private" portion, and "public"/general portion.​

Then author/developer of software tool, can (bundle into a zip/7zip/tar etc compressed format file, and then author/dev can) gpg-sign (or pgp-sign) the main file before releasing it, and gpg/openpgp/pgp tool will create a signature-file for the main file, and then author/dev need to share & show the url-link of the "signature"-file (next to the url-link of main file) in the author's/dev's own primary/source website (not in a mirror or 3rd-party website), for all users/visitors, over a HTTPS encrypted webpage. Also show link to a (HTTPS based) webpage (or show a link to a HTTPS based file-url) from where any user/visitor can get dev's/author's file-signing pub-key code or pub-key-file. And certain command-line option or appending (or piping) command can also output & create a signature-file with the main-file's hash/checksum integrity code & it's byte-size, etc shown inside it, beside the must-have the file-signing openpgp/pgp/gpg code.

On the other side (OTOS), a visitor/user also need to load a openpgp or gpg or pgp software in their side on a secured laptop computer or store sensitive private file stuff (like, gpg/pgp "keyring"-file) inside an external secured portable private flash-memory storage usb-drive, or inside a write-protectable flash-memory media/storage SD drive, or inside a (read & write) RW-protected Keyring or Keychain device.

id = identity, identification.

And then all users/visitors must 1st try to obtain software or file author's/developer's file-signing public-key-file by using a very trustworthy way:

either directly from him/her from a convention or from a key-signing party, which he/she is attending, after a face-to-face conversation. Give the author your (primary-id) pub-key CD/DVD disc (or your write-protectable SD storage card). And get back your signed pub-key and also get author's (primary-id) public-key-file and file-signing pub-key-file, before the end of key-signing party or convention, in a different (write-protectable or write-protected) secured storage media (like, another CD/DVD disc or another SD flash-memory card), to reach one-of-the-highest-trust-level (OOTHTL) or to reach highest-trusted-authority-level (HTAL) in PGP or GPG WEB-OF-TRUST (WOT) LEVEL. If you have original pub-key-files, then GPG/PGP commands can show with higher assurity, that, if the author/developer himself/herself has trusted his/her own file-signing pub-key or not. And, gpg/pgp tool can also show, if the "signature"-file & main-file has been authenticated or not, when you will have author's/developer's file-signing pub-key (inside your own gpg/pgp tool's keyring fille).

And if its not possible for a user/visitor to meet face-to-face, then such user/visitor can obtain file-author's or file-developer's FULL fingerprint-code for his/her file-signing public-key-file, or file-author's primary-id public-key-file, from the author's own-hand-given visiting-card or business-card (if it is published or written or shown in it), then user/visitor can use a gpg/pgp command, to initiate a HKPS encrypted download of author's public key from a public key-server, and then, user can match if the fingerprint-code shown on hand-given visiting/business card has matched with the downloaded key file or not. And then user can also check, if author/developer has indeed trusted his/her own file-signing key or not.

And if even-that-is not-possible, then such category of user/visitor can obtain file-author's older public-key-file codes from the author's any paper-based published book (if entire code was published in it) or obtain shown fingerprint-code of author's pub-key-file from any published book, and use a public key-server & HKPS encrypted protocol, to obtain the full pub-key, and then match book-shown fingerprint code with the downloaded key's fingerprint code.

And if even-that-is not-possible, then such user/visitor can obtain file-author's pub-key file over a HTTPS encrypted webpage or connection from author's own (and author's very trustworthy) website, (which should be DNSSEC secured authenticated domain as well, to reach a double-trust-authority trusted level).

And also, always try to match any downloaded key file's fingerprint, with fingerprint code obtained from author's any published paper source materials. And then find out, if author/devloper has "signed"/"trusted" his/her own file-signing key or not.

And, when any user/visitor is obtaining author's pub-key-file from a public Key-server (even if an encrypted HKPS connection is used) and when that user/visitor does not have the author's/developer's fingerprint code from a trustworthy trusted-authority (TA) or from any published paper materials, then such pub-key cannot be trusted enough, and in such case public key-server is just a middle-man entity, which is very likely to have various multiple keys with same (or similar) name as file-author's name, but actually only one of them or none is correct, which is very likely not possible to be detected by a general level visitor/user.

And, if author shows file-signing pubkey file or fingerprint code on a HTTP (not-encrypted) webpage, then it is not trustworthy enough either, but slightly-better than none/nothing at all.​

After previous steps, then a visitor/user is finally ready to do a PGP or GPG based "AUTHENTICATION" of file & file's author, correctly. So now user/visitor can use a pgp or gpg software and load the obtained file-signing (and author's primary-id) pub-key into his/her own gpg/pgp-"keyring"-file, and run a gpg/pgp command, to use (author's file-signing pub-key code and) the "signature"-file which was downloaded (encryptedly), to authenticate (aka, verify) the downloaded main file. GPG / PGP software can show if a downloaded file is specifically verified by the specific author/developer or not, AND, it can also show if the file INTEGRITY is intact or modified, and if the file byte-size has matched or not.

Usually authors & developers associate the shared (primary-id & file-signing) public-key with one of their own (or different) email address. Users/visitors should also create their own key-pair, and try to obtain trust+sign on their pub-key from other people, after meeting them face-to-face & get to know each-other via key-signing party/events or conventions or meetings etc.

When a developer/author is publicly known in real physical world, or has public events with video of lectures/training/guides seminar/convention etc, which are present or visible publicly, then such dev/author person should attend key-signing parties/sessions/events, and increase your WOT level & connections+network with other trusted devs+authors. Exchange business-card or visting card. Share your updated pub-key or at-least share your (long+full) fingerprint with general or other users, from your own website (HTTPS/TLS secured + DNSSEC signed). Also create a file-signing key, and trust+sign it with your main/real/primary identity key, with a higher-level of trust-level. Then you can sign the file-to-be-released with your file-signing key. Also share full file signing pub-key or at-least it's fingerprint-code over a trustworthy HTTPS/TLS secured+encrypted website + DNSSEC signed domain name-servers. Also declare (aka, publicly share) your (and your group member's) main/primary id pub-key & file-signing pub-key fingerprints, in your domain's DNS record & dnssec sign it. When you will reload back your own pub-key after (or during) a key-signing party, then your own keyring will have all necessary codes & data showing who have signed it and who has set what trust levels on it. Then if you update your pub-key with a key-server, then key-server will have updated key, and it will contain data showing who has trusted+signed your pub-key.

But when a dev user or a dev-persona or a user, has some reason(s) to remain less-known physically in real world, or wants to protect privacy or if a dev/user prefers to remain as a virtual presence only person in cyberworld (aka, internet-world, aka, virtual-world), then don't do gpg-sign & don't do gpg-trust with highest trust level, for your pub-key which you will be using for file-signing purpose, with your main/real/primary world identity key. Keep real world main or primary identity pub-key file aspects separate, from a cyberworld-only identity's file-signing pub-key aspects. But if you want to, you can & may sign+trust a pub-key of a cyberworld person or cyberworld person's file-signing pub-key, with a lesser-trust level (like, internet-level or cyberworld level). If a cyberworld entity or identity owns domain & website, then such user can also publish the identity pub-key or file-signing pub-keys, fingerprints, etc over HTTPS+TLS secured/encrypted webpage + DNSSEC signed domain + DNNSEC signed key-fingerprint.

General users or a general visitors, when has not physically seen a person face-to-face in real world, and do not fully trust, and do not really know what this person is really doing in various times, and did not see/view/inspect this person's any official/government issued ID (and photo-ID), then in such cases, general users or visitors should not set trust or gpg/pgp sign any type of (real world or cyber world) pub-key with a Higher-Trust level.

But when a released software/tool file was helpful, and if it was checked via multiple checking / monitoring / benchmarking / analysis / inspecting tools, and if the software/tool was found to have no backdoor, and if the tool did Not send user's private or personal info back to some outsider data-harvestor or data-mining or mass-surveillance or bulk-data-collection entities or adversaries or groups, and if the tool has Not violated various public Privacy-Rights & Civil-Rights & Laws which were passed with majority public's voted public decision, and if the tool is Not assisting corrupted-groups (or corrupted-interests) who created unhelpful & conniving newer Rights & newer Laws, and if the tool is Not assisting corrupted-groups (or corrupted-interests) who created unhelpful & conniving newer Rights or newer Laws or newer Provisions or newer Codes inside a closed-door & non-public & non-publicly-voted session, and if the tool has earned+gained real provable trustworthiness, ONLY then a general user/visitor can trust that specific file's file-signing pub-key with a lower-level trust (cyber-level / internet-level trust), to indicate this dev/releaser/author is trustworthy, at-least at that lower-level of trust-level.

REFERENCES:

* PGP ~=~ OpenPGP ~=~ GPG ~=~ GnuPG ~=~ IETF RFC 4880 . WOT . PGP/GPG Keys Via DANE DNSSEC , DNS OpenPGP Key , DANE .

* https://www.GnuPG.org/ , GnuPG-HowTOs , GnuPG-FAQ , GnuPG-Handbook/Manual/Guides

* https://EmailSelfDefense.FSF.org/ , https://EmailSelfDefense.FSF.org/en/windows.html

* https://people.via.ECP.fr/~clem/nist/gpg-enigmail-howto.php

* http://www.CryptNet.net/fdp/crypto/keysigning_party/en/keysigning_party.html (GnuPG/GPG/PGP/OpenPGP Key Signing Party, WOT) -- by V. Alex Brennen.

* http://pgp.cs.uu.nl/ - Trust Paths of keys, and Key statistics (WOT) -- by Henk P. Penning.

* https://www.rubin.ch//pgp/weboftrust.en.html -- by Patrick Feisthammel.

* key server article on Wikipedia , https://sks-keyservers.net/status/ (Pool list of SKS = Synchronizing Key Servers).

* https://www.gnupg.org/related_software/swlist.html

* https://trac.torproject.org/projects/tor/wiki/doc/TorifyHOWTO/GnuPG (GnuPG, Keyservers, WoT, Key Signing, Trust Levels, Cyberspace, Privacy-Rights, Anonymity, Tor).

Note: i have copied various info portion on this & my other posts, from various other websites & authors, with their permissions obtained.