Herewith my 2c:
- run static code analyzer against GPG source code (e.g. llvm's
scan-build). Verify GPG source code against keys provided after
downloading. (Of course is manual inspection also a possibility, but at
least for our team scan-build catches more errors than the humans
involved).
- Question: do you trust your toolchain?.
- Compile from inspected source on a different (never Internet connected
and cleanly installed) system.
- generate checksums on binary and other related files.
- generate GPG keys.
- burn GPG binary and GPG keys to CD.
- mount CD (read-only) on system-at-risk using a cd-player without
writing capability.
- run GPG from CD.
Caveat: doesn't protect against e.g. live in-memory attacks on running
GPG and/or on data presented to user on screen, but minimizes the risk
for a lot of other possible mischief.
Criticisms concerning cookbooklet above more than welcome.
Sincerely, Erick
On 05/29/2013 07:20 AM, shawn wilson wrote:
This is sort of a trusting trust question. However, is there a way to
have gpg verify it has not been altered? Maybe by compiling it with an
internal key file and it asking for a password before decrypting
itself and then presenting some type of verification. I'm asking
whether something like this exists or is possible? Ie, how does
malware do integrety checking / try to thwart people from running it
if something is amiss? Can this type of thing be put into gpg?
_______________________________________________
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
_______________________________________________
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
