🚀 go-pugleaf

I think Terry Ritter is underestimating the effort needed to successfully
carry out the spoofing attack he describes.

As others have pointed out, the spoofer, to attack me, must filter out
*all* messages which would allow me to receive someone else's public key.
(That is, the spoofer must, for each such message, generate his own
"fake" version of the sender's key, and substitute it in the message.)

Otherwise, if I do get an accurate key for someone else, the spoofer
can't tell what I might be sending to him.  Also, any message which that
person *signs* and sends to me cannot be altered by the spoofer without
being detected.  Something as simple as "your public key is XXX", if sent
to me in signed form, would expose the spoofing.

A corollary to this is that if I validate *any* other key through a
non-email channel, such as the telephone or a personal meeting, the jig
is again up.  If the key has been spoofed (and all keys must be spoofed
if any are), it will be detected.

(Of course, an even simpler measure is to call someone up and ask what my
public key .sig was at his site.  If I am being attacked as above,
it must be different from my actual public key.)

Ritter makes much of "validated" keys using a Certification Authority.  I
will note that it will be cheaper to subvert the CA than to crack RSA,
so one of Ritter's arguments against decentralized public key use applies
to the bureaucratic approach he favors as well.  Plus, any system which
involves a national monopoly arrangement for CA's (as we may have on a
de facto basis in the U.S. due to the patent protection of RSA) is, IMO,
going to be *more* vulnerable to government pressure than a decentralized
system.  A compromised CA is far more dangerous than a single compromised
net node.  (And thus, far more valuable to the attacker.)

Another corollary to the need for a successful spoofer to alter all
incoming keys has been stated here as well: if such spoofing is a danger
more of the future than of the present, then collecting keys *now*, before
such spoofing begins, is a very good idea.  If, ten years from now, a
spoofer attacks me as above, and I've saved some of these currently-
published keys, they can be used to expose the spoofing.  All it takes
is for me to send a message encrypted with one of these old keys which
includes my public key in the encrypted portion.  Since I collected these
keys before the spoofer went into business, he can't tell what I am sending,
and he can't change my public key in the encrypted part of the message.
The difference between what everybody else thinks my public key is and
what I think it is will again be exposed.

Hence, this practice of publishing keys now, which Ritter decries, may
actually provide a foundation for preventing the spoofing attack in the
future.

Ritter points out that even if I follow all of these precautions, there is
no assurance that my correspondant is.  If he is the one being attacked,
and, as a naive user, has not taken any of these elementary measures to
prevent it, then my messages to him will be compromised.

But of course, any encrypted communication with a person inexperienced
in the need for care must be viewed with caution.  There are plenty of
other ways inexperienced users can compromise our conversation.  Failure
to guard the secret key carefully is probably a far greater danger.  And
no CA hierarchy will help with that.  The best approach is to enlighten
my correspondant as to the need for the simple precautions I've outlined.
But hopefully, in an environment in which most email conversations are
routinely encrypted (a practice I consider likely in a few years), the
need for this kind of care will be widely understood.

Adam Boyles   -   a-boyles@cup.portal.com