About PGP Signing a File.

[Matthew Flaschen]

Jeffrey F. Bloss wrote:
> Matthew Flaschen wrote:
> 
>>>>> It's entirely possible that the guy's keys were stolen in the
>>>>> intervening night.
>>>> Also true, but that's what revocation certificates
>>>> (http://www.pgp.net/pgpnet/pgp-faq/pgp-faq-key-revocation.html) are
>>>> for. Constant vigilance.
>>> If your keys have been compromised a revocation certificate is
>>> mostly useless.
>> Eh?  An attacker can sometimes create a false revocation certificate,
>> but that doesn't stop you from creating a real one.  It's true that it
> 
> There's no "can sometimes" about it. If your keys are compromised
> in this context an attacker can create revocation certificates all day
> long.

Right.  That's not the only kind of attack on PGP though.

> And neither the valid nor the invalid revocation certificate
> carries with it any mechanism at all to make a determination. That's
> the whole point.

Which means you should never use a revoked key, because it *could* have
been compromised.

> Out of band has nothing at all to do with this. Yes it's a valid way
> to establish some level of personal credibility, but that credibility
> doesn't scale to digital certificates at all like you seem to believe
> it does. Even knowing someone all your life and watching them generate
> a key in person right after the blood tests is meaningless once you
> leave the room, without a considerable amount of investment that has
> nothing at all to do with PGP.

How's that?  If I identify them in person, then get their key, I can be
sure that all messages generated by that key were made by them.

> No, it's *the* issue. There's any number of ways this sort of digital
> signature scheme can be trivially exploited or simply fail under its
> own weight. A "DoS" attack perpetrated by forged/bogus revocation
> certificates is just one of the inherent weaknesses that make PGP
> signatures so unsuitable for proof of authorship that most
> experts in the field people consider them utterly useless.

A (possibly fake) revocation makes them suddenly unsuitable, but between
verification out-of-band and key revocation/expiry, why can't it work as
a proof of authorship?

> As I've stated quite plainly several times already, there are ways to
> help give digital certificates the sort of credibility far to many
> people assign to them as a default. They're generally either
> unmanageable to the point of being ludicrous for most laypersons needs
> or fraught with their own perils.

How is it ludicrous to meet a close friend in person to exchange keys?

> Regardless of that, verifying someones
> identity at the time of key exchange is such a small part of any of it
> that it's almost irrelevant. The verification process itself is
> exploitable, and it offers absolutely *zero* forward security. So
> verification itself requires a high degree of complexity to be
> reliable, and evaporates when you blink.

I have no idea what you're talking about.  Once a key is personally
verified, it's usable until/unless a secret key is compromised.

> 
>> All security mechanisms are vulnerable if you lose the secret.  So,
>> don't do that then.  PGP is not unique, and is better than most
>> because you're not supposed to share a secret with anyone (unlike
>> e.g. passwords).
> 
> Irrelevant. What's "suppose" to happen, what "can happen", and whether
> or not some protocol or mechanism addresses what happens in reality are
> completely unrelated. The bottom line fact is that PGP/GnuPG do so
> little to verify a key holder's identity that if you want any
> reasonable level of trust you have to look elsewhere. Plain and simple.
> 
> 
> Once again, there simply is no reliable method of proving "digital
> identity" currently available.

I keep saying that you don't prove your identify digitally.

Matthew Flaschen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/ubuntu-users/attachments/20070213/1b203c82/attachment.sig>