"Dead beef" attack against PGP's key management
Raph Levien
This post is signed by a forged key for Phil Zimmermann. I forged
the key this morning. The key has the same user id and visible key id
as an old key for Phil Zimmermann, which he has since revoked.
I should stress that this attack does not in any way weaken the
security of PGP's message formats. However, it does expose a problem
in the user interface of its key management. Namely, it is fairly easy
to forge a key that looks very similar to an existing key. In fact,
the only way to distinguish between real and forged keys in general is
by the fingerprint and keysize together.
My purpose in posting this is to demonstrate that such forgeries
are possible. The lesson is: please do not use the key id alone to
identify keys.
Another reason for the public posting of this forgery is to goad
the PGP development team into improving the user interface in PGP 3.0,
so as to make the detection of such a forgery much easier, if not
routine. Derek Atkins has assured me that PGP 3.0 will include a
cryptographic hash of the key, for use as a key id. If implemented
properly, such a facility would address this attack.
I am not the first to propose this attack. According to Derek
Atkins, Paul Leyland first proposed the attack two years ago. Also,
Greg Rose successfully mounted a similar attack six months ago,
creating a key with user id 0xDEADBEEF, thereby giving rise to the
name.
The pseudocode for the attack is as follows:
choose random 512 bit prime p
choose random 480 odd x
q = x * ((0xdeadbeef * (p * x) ^ -1) mod 2^32)
do {q += 2^32} while q composite
The above bit of pseudocode replaces the original selection of p
and q, which are normally just random 512 bit primes. Without having
done detailed analysis, I believe that the resulting forged keys are
just as good as ordinary PGP keys. Further, the modified key
generation is almost as fast as ordinary PGP key generation, and I
think I could speed it up a bit more.
The attack took me a few hours to design and code. Any good
programmer familiar with PGP could duplicate it easily.
One practical application of this attack is to implement a certain
degree of "stealth." Since PGP includes the key id in encrypted
messages, it is in most cases possible to identify the recipients of
encrypted messages. However, if a lot of people generated keys with
the same key id, then it would not be possible to tell from the
encrypted message which one was the intended recipient.
Here's the public key I forged, which can be used to check the
signature of this message:
Key for user ID: Philip R. Zimmermann <p...@acm.org>
1024-bit key, Key ID FF67F70B, created 1992/07/22
Also known as: Philip R. Zimmermann <p...@sage.cgd.ucar.edu>
- -----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.2
mQCNAyptNMAAAAEEALRhS3ZCFKLPNF/fZeluh/rNfpgZ5a0ddTBtxJ+1yLIkVurb
HWFFBsrmnA4hU4MhlA8DS/f2gnS0v3zyQ78JOY1SBIJrLdaIPIrh0ZTAZXWoQWDe
Qknm1ZgyLkIRJlt5aDLp+iLJ5sc+LSO5N/DtrL+Htc5MF0AVAWtzPhz/Z/cLAAUR
tCJQaGlsaXAgUi4gWmltbWVybWFubiA8cHJ6QGFjbS5vcmc+iQCVAwUQMWAremtz
Phz/Z/cLAQE//AP/bg9gMOuiBYkFCiyarJ/DIARWDf7e4bWFJloXAyPeBXCITDIw
tuHRJ41yFqnlLmdcuVhXQf/xrH248JyWpHqqED6eOU/PnBHo9IR6H0Fts+O3I+vk
tOYRjuTJy+6JV0s/8VN/Sgh8y6Jm2FGhhzhCp6KHNcTHpUud6iGScaEs/CG0LFBo
aWxpcCBSLiBaaW1tZXJtYW5uIDxwcnpAc2FnZS5jZ2QudWNhci5lZHU+
=Z1mf
- -----END PGP PUBLIC KEY BLOCK-----
Raph Levien
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBMWA2pGtzPhz/Z/cLAQELEQP/fam4tHS8TlMy7SFoUZvC0C4q0ID9Ze5W
rY2D++df4UtAFDITGs4lQqzeq6YCqk51oT8gZAACK6D6UlFgr5roIbgwa74Fxso1
B5mquC9axlOlxZJI1PuK+NflBJqCokuQGtG95ER6vbm4n4RACW43In9SAatIvduN
JfBSLYrAr14=
=V5U6
-----END PGP SIGNATURE-----
Preston D. L. Wilson
On 1 Apr 1996 22:06:46 +0200, Raph Levien <ra...@c2.org> wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>
> This post is signed by a forged key for Phil Zimmermann. I
>forged the key this morning. The key has the same user id and
>visible key id as an old key for Phil Zimmermann, which he has
>since revoked.
[snip]
> I am not the first to propose this attack. According to Derek
>Atkins, Paul Leyland first proposed the attack two years ago.
>Also, Greg Rose successfully mounted a similar attack six months
>ago, creating a key with user id 0xDEADBEEF, thereby giving rise
>to the name.
>
> The pseudocode for the attack is as follows:
>
> choose random 512 bit prime p
> choose random 480 odd x
> q = x * ((0xdeadbeef * (p * x) ^ -1) mod 2^32)
> do {q += 2^32} while q composite
[snip]
Well, I don't know if this is an April Fool's joke or not, but if
it is I fell for it hook, line, and sinker. The included public
key does indeed work to check the signature. But naturally the
original 0xff7f key of PRZ does not work to check the sig.
While this does indeed work, I would like to question the danger
involved. In most instances, the worst that is likely to happen is
that some people will get bad signature reports when a signature is
good:
o Jane has Dick's genuine key. Spot forges a copy of Dick's key,
and mails Jane a clearsigned message. Jane checks the sig,
which doesn't check out. In fact, it says that it doesn't even
have the correct key to check the sig. Therefore she doesn't
trust the message (and rightly so).
o Jane has the key that Spot forged in Dick's name. Dick sends
her a signed message, and when she tries to check the sig, PGP
tells her that she doesn't have the right key in her keyring.
It reports the key ID, and she checks it. Lo and behold, she
does have that key ID. She calls Dick and checks the
fingerprint, and they don't match. She gets a clean copy from
Dick.
The only way that Spot will be able to read Dick's mail is if he
gives his forged Dick's key to Jane, and Jane trusts that this key
is genuine. Perhaps Spot signed the fake Dick key, so Jane
(trusting Spot just as Othello trusted Iago) puts it on her
keyring. Jane's basic error is in not checking the key fingerprint
with Dick.
If Jane doesn't know Dick, and wants to send him private email,
there's no way she can fully trust the key anyway. If Jane and
Dick are strangers and Spot is acting as intermediary, Spot needn't
bother forging the key ID; he may as well just generate a new key
with the userID of Dick. Jane won't know the difference about the
key ID.
The moral of the story? Dogs can be really, REALLY vicious.
- -pdlw
pub1995/11/12 preston d. l. wilson <pd...@servtech.com>
1024/12B8CED1/EA66 A373 51E5 C1E4 49E8 2737 5267 D3C3
(Just in case something comes of this DEADBEEF thing.)
-----BEGIN PGP SIGNATURE-----
Version: 2.7.1
iQCVAwUBMWCqq8iN2c4SuM7RAQGntAQAo5OPPBOwsAts4oVTE55EXAOUqp0l0LFH
wlZjxkU17wmp/9VxypOmxrscBdDuO3ZOWjNxufctqITRhsxIoYoG5ac3H1Ve1tX+
9YOTb71gb6NXp/WgDpNBFxV/tgo7FOJKRRqho3lUE9yYME4Kb4pmEhHLO4yApccp
x4KHyXWiwVg=
=hTpl
-----END PGP SIGNATURE-----
Jack Repenning
> While this does indeed work, I would like to question the danger
> involved. In most instances, the worst that is likely to happen is
> that some people will get bad signature reports when a signature is
> good:
It's more serious than that, though good keyring discipline will
protect you. Then again, keyring discipline is pretty subtle, and
it's often been suggested that it's beyond the average computer user.
If you add one of these "Dead Beef" keys onto your keyring (where you
already had the key as which it is masquerading), it goes to the
front. You now have no way to specify that you want the older, real
one. If, for example, you try to encrypt, your message is encrypted
to the "Dead Beef" key, not the real one. If your enemy can also
intercept your email (an assumption you always make, or you wouldn't
bother to encrypt at all!), s/he can read a message or two before you
and the real person manage to alert each other. A longer-lived
assault could involve sending you several messages signed by the "Dead
Beef" key, which you faithfully sig-check and foolishly trust.
How does the "Dead Beef" key get onto your keyring? If you're careful
enough, of course, it doesn't. But how careful must you be? The key
might be Trojan'ed in with some key you do want to add (ever helped
out a newbie's "here's my key; please send me an encrypted message"?).
The risk also grows as mailers and news readers and web browsers add
PGP hooks: the PGP dialogs might be enough to protect you, but a few
more layers, built by someone not as knowledgable, intended to
simplify things for the common man, and the story could be different.
Mark M.
Preston D. L. Wilson (pd...@servtech.com) wrote:
:
: Well, I don't know if this is an April Fool's joke or not, but if
: it is I fell for it hook, line, and sinker. The included public
: key does indeed work to check the signature. But naturally the
: original 0xff7f key of PRZ does not work to check the sig.
It's not an April Fool's joke.
:
: While this does indeed work, I would like to question the danger
: involved. In most instances, the worst that is likely to happen is
: that some people will get bad signature reports when a signature is
: good:
:
: [...]
:
: The only way that Spot will be able to read Dick's mail is if he
: gives his forged Dick's key to Jane, and Jane trusts that this key
: is genuine. Perhaps Spot signed the fake Dick key, so Jane
: (trusting Spot just as Othello trusted Iago) puts it on her
: keyring. Jane's basic error is in not checking the key fingerprint
: with Dick.
:
: If Jane doesn't know Dick, and wants to send him private email,
: there's no way she can fully trust the key anyway. If Jane and
: Dick are strangers and Spot is acting as intermediary, Spot needn't
: bother forging the key ID; he may as well just generate a new key
: with the userID of Dick. Jane won't know the difference about the
: key ID.
This is a very large danger. Many people just put the keyID in their .sig
files and not their fingerprints. A naive user of PGP might check if the
key is genuine by just checking the keyID. Of course, a MITM attack is still
possible even if people put fingerprints in .sig files, but such an attack
is very difficult.
- -- Mark
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
ma...@voicenet.com | finger -l for PGP key 0xf9b22ba5
http://www.voicenet.com/~markm/ | bd24d08e3cbb53472054fa56002258d5
"The concept of normalcy is just a conspiracy of the majority" -me
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3
Charset: noconv
iQCVAwUBMWFiQbZc+sv5siulAQGtdQP/UIInMFt+6F1n2YE4db+ewjLFq1ExKMCy
lDWAhP5AWgE1kFAsBz2/GGqqKiHa7jD/PoX4t8sWGBwQ9QmNs8ev77nB4Fo+9PWq
tOTDTA1Psk6qIOZbXL9bCOu+2oBtI5K+ZuS0EU64M59uEv+RG2dPEl5+KTQB6lgK
IkfBhsVDDls=
=NqiZ
-----END PGP SIGNATURE-----
Raph Levien
Jack Repenning <ja...@netgate.net> wrote:
>How does the "Dead Beef" key get onto your keyring? If you're careful
>enough, of course, it doesn't. But how careful must you be? The key
>might be Trojan'ed in with some key you do want to add (ever helped
>out a newbie's "here's my key; please send me an encrypted message"?).
>The risk also grows as mailers and news readers and web browsers add
>PGP hooks: the PGP dialogs might be enough to protect you, but a few
>more layers, built by someone not as knowledgable, intended to
>simplify things for the common man, and the story could be different.
Thanks for pointing this out. The existence of the "dead beef"
attack makes it much more difficult to write trustworthy automated
tools for managing PGP keyrings, and that's the main reason to be
concerned about it. Because the only way PGP identifies its keys
through the user interface is user id and key id, both forgeable,
there is no way for an automated key management script to distinguish
between the real key and the forged key.
And, as everybody knows, doing PGP key management by hand is
clunky, awkward, and time consuming. Fixing the "dead beef" attack, by
allowing keys to be indexed by cryptographically strong hashes will
open the door for talented scriptwriters to build cool key management
things, and make PGP much more useful for the rest of us.
At the very least, it should be possible to go directly from an
email address to a trusted key, assuming that a trust chain exists to
that key. There's no technological reason why that can't be done
today; it wouldn't be that difficult to design protocols to
automatically pull the keys over the Web. However, I sense a certain
lack of will to solve the problem, which I feel becomes clear when you
consider that the "Dead beef" attack has been known for two years, has
been mounted three times by independent people, and still there's no
concrete proposal for fixing it.
Raph
Gary Woods
>In article <3160B5...@netgate.net>,
>Jack Repenning <ja...@netgate.net> wrote:
>>How does the "Dead Beef" key get onto your keyring? If you're careful
>>enough, of course, it doesn't. But how careful must you be? The key
>>might be Trojan'ed in with some key you do want to add (ever helped
>>out a newbie's "here's my key; please send me an encrypted message"?).
Interestingly enough, since I'm a suspicious sort, I didn't use
the key in the messsage, but requested the same ID from the MIT
keyserver. It, of course, sent me Zimmerman's (cancelled) one.
I'd guess that getting a key this way is a *little* better than
getting it from a total stranger by email, though nowhere near as
good as in person or from a trusted third party.
....Is the "DEADBEEF" from England?
Gary Woods O- K2AHC
gwo...@albany.net
finger for public PGP key, or get 0x1D64A93D via keyserver fingerprint = E2 6F 50 93 7B C7 F3 CA 1F 8B 3C C0 B0 28 68 0B
Paul Leyland
> >In article <3160B5...@netgate.net>,
> >Jack Repenning <ja...@netgate.net> wrote:
> >>How does the "Dead Beef" key get onto your keyring? If you're careful
> >>enough, of course, it doesn't. But how careful must you be? The key
> >>might be Trojan'ed in with some key you do want to add (ever helped
> >>out a newbie's "here's my key; please send me an encrypted message"?).
> Interestingly enough, since I'm a suspicious sort, I didn't use
> the key in the messsage, but requested the same ID from the MIT
> keyserver. It, of course, sent me Zimmerman's (cancelled) one.
>
> I'd guess that getting a key this way is a *little* better than
> getting it from a total stranger by email, though nowhere near as
> good as in person or from a trusted third party.
>
> ....Is the "DEADBEEF" from England?
Nope, but I proposed and implemented the attack a couple of years ago.
I'm (currently) in England
Paul Leyland BSe (Oxen)
--
Paul Leyland <p...@oucs.ox.ac.uk> | Hanging on in quiet desperation is
Oxford University Computing Services | the English way.
13 Banbury Road, Oxford, OX2 6NN, UK | The time is gone, the song is over.
Tel: +44-1865-273200 Fax: 273275 | Thought I'd something more to say.
PGP KeyID: 0xCE766B1F
Hal
Internally, PGP keeps key ID's as 64 bits. But it only shows 32 bits to
the user. Mostly I think it is because it is more manageable to type or
look at 8 digits vs 16, and partly perhaps because it is slighly easier
to print and parse 8 digit hex numbers than 16.
PGP has a check internally for two keys which are different but whose
ID's match. It prints a special warning message for that case. However
the check is on the 64 bit internal key ID, not the 32 bit visible one.
A 64 bit key ID forgery would be somewhat more serious than a 32 bit one,
because then PGP would not know to choose the right key to decrypt a
message or check a signature, and you would get some errors that aren't
supposed to happen.
If you do get a bogus key onto your key ring via Raph's method, there are
a couple of ways you can recognize and deal with it. First, the key will
be untrusted. So you will get a warning message when you try to use it.
If you maintain good key hygiene and don't engage in unsafe crypto, this
will be a red flag for you.
Even if you have been using a key and ignoring warnings, you get a
different warning message the first time you use an untrusted key than
later times. So again the first time you used one of these forged keys
the error message would be different from the one you have been seeing
before. Of course, if it is the first time you have sent mail to the
forgery target then this won't clue you.
Another possibility, particularly for the automated tools Raph is talking
about, is to run pgp -kv and pipe the output through a filter which
extracts just the key ID's and sorts them, looking for duplicates. This
could be done just after adding keys to the key ring, to recognize and
alert you to this attack. Then the new conflicting key can easily be
removed.
This will run into a problem if two different keys happen to have the
same 32-bit key ID, which can happen by accident. So ideally you want to
check to see if the names match too, to recognize Raph's attack. But
that doesn't quite work, because Raph's attack is just as effective if
the name is slightly mangled by changing whitespace, periods, or
spelling. So a simple check for equality of names can be easily defeated
by the forger. It ends up being a little more complicated than we would
like, but I think a reasonably good solution is possible for those who
are worried.
But again I think the best solution is to use trusted keys, to verify
them, to sign them, and to pay attention when you get a warning that a
key is not trusted.
Hal
Preston D. L. Wilson
>-----BEGIN PGP SIGNED MESSAGE-----
>
> This post is signed by a forged key for Phil Zimmermann. I forged
>the key this morning. The key has the same user id and visible key id
>as an old key for Phil Zimmermann, which he has since revoked.
[snip]
Could somebody help me out? I'd like to try make a PGP that lets you choose
your keyID, but I don't know what to change. I think there must be some
things in keymgmt.c and one of the rsa*.c files, but I'm not totally sure
what.
Could somebody email me either a copy of the source for these files, modified
for this function, or perhaps something a little more detailed (in C) than the
"pseudocode" supplied with Raph's original post? (BTW, I live in the US, so
anyone helping me out here won't be exporting crypto code from the US.)
Thanks!
-pdlw
C. Scott Ananian
In article <4k1msn$8...@jobe.shell.portal.com> hfi...@shell.portal.com (Hal) writes:
>A couple of points re the key ID forgery:
>
[heavy editing...]
>
>This will run into a problem if two different keys happen to have the
>same 32-bit key ID, which can happen by accident.
By *Accident*? A 32-bit ID? Not very likely.... but maybe you're the
type who wins lotteries?
I think you're pretty safe ignoring the possibility of overlap and
having to specially treat keys whose ID's match. I don't think very
many people would be annoyed...
[snip!]
>But again I think the best solution is to use trusted keys, to verify
>them, to sign them, and to pay attention when you get a warning that a
>key is not trusted.
Agreed.
--Scott
@ @
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-oOO-(_)-OOo-=-=-=-=-=
C. Scott Ananian: cana...@princeton.edu/ Declare the Truth boldly and
227 Henry Hall, Princeton University / without hindrance.
Princeton, NJ 08544 /META-PARRESIAS AKOLUTOS:Acts 28:31
-.-. .-.. .. ..-. ..-. --- .-. -.. ... -.-. --- - - .- -. .- -. .. .- -.
PGP key available via finger and from http://www.princeton.edu/~cananian
PGP signature follows....
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBMWTOOb3Z92aFrZ7tAQHFggQAi9k2ZoYI9E86YWm5iZzFGlDFzev8GHfF
X23YXRMbWtdu0M3ZMKs7wTQULFGKcJ2yd+k9QuCAHLa7WXwqs6iWoB118r/bUM11
JC/NRaH6oTmGXtdY8MsjNcEsfn7rugO/pC5XOi95ctMGyNWz/8CX32rgvQtB2JGG
iC28hhSx8Xk=
=lms3
-----END PGP SIGNATURE-----
Gary Woods
Raph Levien <ra...@c2.org> wrote:
This post is signed by a forged key for Phil Zimmermann. I
forged
>the key this morning.
Not to prolong this too much, but am I better off getting a
public key from a keyserver? This would seem, at least to be a
more public place to commit forgery/impersonation, and to get
noticed.
I tried getting a number of keys for people that post here, and
some of them are available by finger, but not public server.
Should I be suspicious, or is this no worse a way of getting a
key for someone I don't know?
Paranoidedly yours:
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQEVAwUBMWXJMTAssNodZKk9AQHs+gf9GnA2EZBZPvQWPFUtI/KER8RwruKKQE1y
9FQWhgntXXNJ+9VIpj8t7QkxnDJEI7MrGKZRjNDAb4pDOdqep8sCcT1r/UqmBqvR
oiW3ZUf8+mBGJD16ePHTRs5tO7XspgxmPI3DOicIQEAtO60Y81gyB8D/B4zkRJaN
xZsNISy+VCs2nx0sTS4vEP5z36tVUVdNGyAP51BFacvsV6+6nZTwxS3yKwIc1Abd
ZePl7d6BKEpXRwwkN/UO6kBA9tMFBTA8NNSmbp2lPwM8AzzLZPAIRYejnzS7MiHO
yDS7y5ImHRcbJ5K6PatX5OpOA8M+GzVC/8kPBfTXnEMDmAfAinY8/Q==
=3XGC
-----END PGP SIGNATURE-----
The Daniel Weber
]
]....Is the "DEADBEEF" from England?
]
I have no idea if this is what the author intended, but as soon as I saw
dead beef written as one word in all caps it occurred to me where I've
seen it before: it's a valid hexadecimal address ($DEADBEEF=3735928559)
and in-joke among some people. (Which kind of makes me suspect it could
have been an April Fool's thing, except other people seem to have
corraborated the theory.)
-D
Michael Elkins
>Not to prolong this too much, but am I better off getting a
>public key from a keyserver? This would seem, at least to be a
>more public place to commit forgery/impersonation, and to get
>noticed.
>
>I tried getting a number of keys for people that post here, and
>some of them are available by finger, but not public server.
>Should I be suspicious, or is this no worse a way of getting a
>key for someone I don't know?
I usually attempt to get a person's key from their web page or via finger
before a public server. It seems to me that it is much easier to pick up
bogus keys from those servers than from a keyserver. However, if you
use something like BAL's server via the web, it's not nearly as bad because
you have to actively choose which keys you want to retrieve, so you can
have a little better control of what gets on your key...
me
Don
About a month ago, I produced a keyring of the web of trust, starting with
one of PGP's authors, and added all keys that were trusted by previously
added keys. That got rather large (3 meg) so I made a second, smaller one,
that was much more restrictive. No more than 5 keys from the center of
the web of trust, for example, and only then if they have multiple independant
paths to the center. That keyring is only 1 meg, and is basically a who's who
on the USA/MIT web of trust. The keyrings are bigring.pgp.gz and
smallring.pgp.gz respectively, and are available from utopia.hacktic.nl, a
known cryptosite. (shameless plug: and trust me, they have some fine illegally-
exported goodies)
it's a few levels deep, in /pub/replay/pub/pgp/pgp-key-ring
Don
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQB1AwUBMWm31sLa+QKZS485AQHS3QL/aG5zm27e5G4D+zoATZovVkbg2gfauVa/
OwK4juiru1VA87Mm5mDtaFY+3NavVer6BGz7qFbcJNvkL5zDkUtDMfUhIrnFr3t0
am4ZPYzbjeZY+2rUzfMXW2PNnORFhTm9
=owUo
-----END PGP SIGNATURE-----
--
<d...@cs.byu.edu> http://students.cs.byu.edu/~don PGP 0x994B8F39 fRee cRyPTo!
"It is not worth an intelligent man's time to be in the majority. By
definition, there are already enough people to do that." - G. H. Hardy
** This user insured by the Smith, Wesson, & Zimmermann insurance company **
Raph Levien
As usual, Hal is quite correct on these points.
>Internally, PGP keeps key ID's as 64 bits. But it only shows 32 bits to
>the user. Mostly I think it is because it is more manageable to type or
>look at 8 digits vs 16, and partly perhaps because it is slighly easier
>to print and parse 8 digit hex numbers than 16.
Right. In order to make "stealth" keys as I described in my post,
you'd need to forge the 64 lower bits.
>PGP has a check internally for two keys which are different but whose
>ID's match. It prints a special warning message for that case. However
>the check is on the 64 bit internal key ID, not the 32 bit visible one.
>A 64 bit key ID forgery would be somewhat more serious than a 32 bit one,
>because then PGP would not know to choose the right key to decrypt a
>message or check a signature, and you would get some errors that aren't
>supposed to happen.
Of course, it is equally easy to mount the attack against 64 as 32
bits.
>If you do get a bogus key onto your key ring via Raph's method, there are
>a couple of ways you can recognize and deal with it. First, the key will
>be untrusted. So you will get a warning message when you try to use it.
>If you maintain good key hygiene and don't engage in unsafe crypto, this
>will be a red flag for you.
>
>Even if you have been using a key and ignoring warnings, you get a
>different warning message the first time you use an untrusted key than
>later times. So again the first time you used one of these forged keys
>the error message would be different from the one you have been seeing
>before. Of course, if it is the first time you have sent mail to the
>forgery target then this won't clue you.
All this assumes that you are actually paying attention to PGP's
warning messages. Many automated tools (including my premail) discard
these messages.
>Another possibility, particularly for the automated tools Raph is talking
>about, is to run pgp -kv and pipe the output through a filter which
>extracts just the key ID's and sorts them, looking for duplicates. This
>could be done just after adding keys to the key ring, to recognize and
>alert you to this attack. Then the new conflicting key can easily be
>removed.
That is, if you can easily identify which of the keys is bogus. If,
as Hal (and others) recommend, you sign all the valid keys on the
keyring, that's not too hard to do. But many people (myself included)
have many keys that are not signed.
>This will run into a problem if two different keys happen to have the
>same 32-bit key ID, which can happen by accident. So ideally you want to
>check to see if the names match too, to recognize Raph's attack. But
>that doesn't quite work, because Raph's attack is just as effective if
>the name is slightly mangled by changing whitespace, periods, or
>spelling. So a simple check for equality of names can be easily defeated
>by the forger. It ends up being a little more complicated than we would
>like, but I think a reasonably good solution is possible for those who
>are worried.
>
>But again I think the best solution is to use trusted keys, to verify
>them, to sign them, and to pay attention when you get a warning that a
>key is not trusted.
I agree that this is a good way to avoid the dead beef attack.
However, my concern is that most people are unaware of the rules for
good key hygiene. Part of the reason that I posted the attack widely
was to contribute to the education of users.
Ultimately, the goal should be to construct tools that are much
less fussy than PGP, and for which there are clean, simple rules for
key management that can be used by ordinary people, not just the
designers of the software (Hal and I have both contributed to the PGP
effort in some way).
Raph