🚀 go-pugleaf

 In <66622@cup.portal.com> gregb@cup.portal.com (Greg - Byrd) writes:

>OK Terry, your main point seems to be the same as mine.  Use of a public key
>received via email (for example) opens you to interception and the like.
>The single-point-failure (email channel) is too easy to spoof.

 As I pointed out to you politely by email, I am ready to get
 out of this discussion which seems to be sucking up my time
 endlessly without positive result.  It is time for others to
 jump in, should they feel the need.

 However, no, your comment is not really my point; it is *one*
 of my points.  Email itself is *not* the only problem.  Widely-
 distributed keys are also a problem because keys must change,
 and this leaves the old keys out there for people to use.  If
 the secret part of an old public key was actually revealed, then
 everyone using the widely-published old key is inherently at risk.
 Users who do not insist on a "new" key get what the deserve, just
 like the users who do not validate a public key.

 Yet another problem with widely-distributed keys is somehow
 equating wide distribution with security.  I see no reason why
 the Opponent could not distribute lots of keys very widely
 indeed; all they have to do now is to convince you to use one
 of those.  ("My new key is this: ....., and is also listed under
 codename XYZ in the NYT for Feb. 10, and will be coming out
 as a trademark under my *real* name UVW.")


>Your solution is to use a secure channel (such as in the flesh) to exchange
>keys.  This is ideal when practical.

 Actually, my "solution" (had you bothered to read and understand
 the last dozen or so of my postings, or my email response), is
 to use one or more *insecure* but separate channels to *validate*
 keys.  Open phone lines are hardly secure, and this is not a minor
 point.  And I have said repeatedly that, while separate channel
 validation should be a great improvement over using unvalidated
 keys, it is not and cannot be perfect.


>My solution is to widely dessiminate my public key.  And for you to widely
>dessiminate your public key.  Same for everyone else.

 Your "solution" inherently carries the risk (indeed, the
 expectation) that people will rely upon the old keys, even when
 we know that some of them may have been revealed.

 How is this a "solution"?  What problem does it solve?  Do you
 mean the problem of secure key distribution being harder than you
 would like?  Anybody can "solve" that problem just by ignoring
 the security requirement.  The point is to solve the problem
 while yet *retaining* security.


>Now - the single-point-failure is eliminated.  All that is needed is for
>anyone suspecting spoofing to verify that the public postings of his key and
>of his correspondents keys are unaltered.  As an example, go to a payphone
>and call a dozen people around the world who post to the net.  Total strangers
>whom you have never communicated with.  Have them fetch the keys from their
>handiest local source.  Do they all match?  And do they match *your* copies
>of the keys?  Yes?  Then your public keys are good.  No?  Then your node or
>path is being spoofed.  Grab the shotgun and go hunting.

 First of all, calling people who read the net hardly changes the
 single-point problem if we are talking about a .sig key.  The
 node of the sender, or nodes around him, may have changed that
 key.  Everyone knows the wrong key.  How does that help?

 Moreover, if you got the phone numbers from the net, they are
 suspicious as well.  Calling lots of suspicious numbers is hardly
 different then calling one.  And calling one is useless.  We're
 talking about security here, not games.

 Next, even if separate channel publications match, to the extent
 that they are not *current* publications they may be out of date
 and penetrated.  Those who use old keys risk using a revealed
 key *even if the owner does not know this*.

 Last, not only are you unlikely to find a person associated with
 the spoofing, you may find that your local node has "willingly"
 set this up for "national security" or "law enforcement" reasons.
 Few nodes could or would give a direct "No" to a serious approach
 by their government.  If the node owner approves, I expect that
 "monitoring" data flowing through that node is legal.  Even
 changing the messages may be legal.  You really have nothing
 to complain about.  Even if these things were made illegal, you
 still could not prevent them from happening surreptitiously.

 I believe our goal should be that, by ciphering on our home
 machines, we may send ciphertext on the network and *nothing* on
 the network can do anything about it (except gobble it up).  Real
 data security means that we don't have to *worry* about "them" or
 what "might" be happening on the network, because it really
 doesn't affect our security at all.


>The only time this check could fail is if your correspondent didn't bother
>to also perform the above procedure.  But the mere fact that he *might*
>do this should deter any prospective spoofer who values his hide...

 I have already discussed various failures which are immediately
 evident.  There may well be others.


>If you do change your public key, just allow enough time for all of the public
>key archives to be updated, perform the check again, and keep on chugging alon
>g.

 How much time is sufficient for published keys to change?

 I wish you would confine yourself to under 70-character lines.

 ---
 Terry Ritter   ritter@cactus.org