Why trust gpg4win?

[NdK]

Il 13/09/2013 11:33, Jan ha scritto:

> My "security perimeter" should be "equal" to the maximum of the
> "security perimeters" of my usual communication partners. That is so
> because with their private key they protect my mail and with my private
> key I protect their mail. What is "usual" is not always easy to
> determine. Lets say I'm looking for the maximum of security an average
> user can achieve with common hardware. This user is willing to do some
> inconvenient things like reboot, burn CDs or wait.
Then you can't defend it. :) You can't even completely audit it, since
it involves a lot of "things" that aren't under your control.
What happens if one of your correspondents is willing to undergo the
whole procedure and he's an FBI agent? :)
You can be paranoid as much as you want, but you will never be paranoid
enough. If FBI (or, more realistically, your wife) wants access to your
data, there's nearly nothing you can do to avoid it...

> Generally I distrust certain hardware like smartcards or HSMs because
> they are main targets for secret services, who have a lot of money.
You could use a Chinese smart card: quite sure it's not been tampered by
FBI :)

> Recently I red about this intersting (English/German) article on FBI
> backdoors in openBSB and scmartcards:
> http://www.h-online.com/open/news/item/FBI-back-door-in-IPSec-implementation-of-OpenBSD-1153297.html
> http://www.heise.de/newsticker/meldung/FBI-Backdoor-in-IPSec-Implementierung-von-OpenBSD-1153180.html
Well, that's one reason I don't like "random blobs" in crypto (like OAEP
requires): it could be quite easy yo use such a blob as steganographic
covert channel.

But for OpenBSD I'd be more incline to thinking that FBI stopped funding
since they couldn't have their backdoors installed.

> It should be possible to create a rather secure system using "norml
> technoligies" (CDs, offline PCs etc.) which are harder to target by
> secret services.
Never heard of TEMPEST?
You boot from an accurately audited CD, decrypt your top-secret email
and as soon as you display it on the monitor it gets aired to that van
in front of your house :)

> If you manage to have a rather secure file transfer
> between an online and an offline PC, the only security relevant
> technology you need to focus on is gnuPG itself.
No. Side-channels are everywhere. You can't ignore 'em. If you want to
certify that your security perimeter is secure, you first have to
accurately define where it is and the threat model. And even then you
can only certify it's secure against the attacks you could think of.

> Some people read the
> source code to check its integrity but are there people who focus on its
> output? To me this is a very important point. I'm not sure how this
> could be done in practice, but I was thinking about someone who knows
> the theory of RSA etc. and who "manually" encrypted a text and would
> compare that with the output of gnuPG to see whether the two results
> match.
Take OAEP signature as an example. *IF* the random bytes are really
random the signature is secure. But since they should be  random, you
can't say if they are truly random or just the output of a cypher that,
given the right password, is transferring your secret key
chunk-by-chunk. And against that, even manually encoding is useless: the
RSA encryption is done correctly, the key is the right one, the protocol
is followed, but soon someone else will have your key and will be able
to decrypt all your messages.
IVs are another potential channel, but they're needed to make many
encryption schemes secure.

> Some other approach might be to compare the output of several
> versions of gnuPG, PGP etc.. This way you could check whether the
> information was secretly decrypted with a second "FBI key". This is even
> possible for someone how is no programer. Do you think checking the
> output in that way is useful?
No. You can only check if the protocol is followed accurately.
How can you check there isn't a weakness in RNG, for example? In other
terms, how can you tell apart a TRNG from a good cypher?

BYtE,
 Diego.