[linux-elitists] GPG luser rant
Karsten M. Self
Fri Apr 13 12:47:34 PDT 2001
on Fri, Apr 13, 2001 at 11:50:11AM -0700, Rick Moen (email@example.com) wrote:
> begin Karsten M. Self quotation:
> > Better yet, if folks actually *do* get GPG installed on their systems,
> > when there comes a need to send private mail, the option to go encrypted
> > exists. We're shooting for a baseline state in which a presumption of
> > the presence of cryptographic infrastructure is valid, and the ability
> > to originate, receive, and validate such communications exists.
> Yes, I certainly see the point.
> I wish it were not the case, but there are not yet very workable
> real-world systems for distributing, managing, and revoking keys --
> PKI/certificate authority or web-of-trust models are both problematic
> in those areas if you aim for both day-to-day practicality and
> meaningful authentication. Much as I would like to hope that these
> are early implementation issues that will be ironed out, the worst of
> them appear essential to the authentication models concerned.
There is a distributed public keyserver network. This seems to work
reasonably well from a data distribution standpoint. I'd be interested
in knowing what specific problems exist with it.
Revocation seems to be the real nit. There isn't an analog, AFAIK, in
the PGP model to a "revokation signature". That is, signing a key to
say "I know this key and it is false, invalid, or revoked".
Updating key to aquire new signatures is a slightly different story.
It's possible to roll through your keyring and re-request the keys from
public servers. This takes some time for me, but is doable, and could
be packaged as a scheduled system task.
> (I know I'm being repetitive about this, but the best analysis I know of
> is Bruce Schneier's in _Secrets and Lies_. I wish he had the crypto
> chapter on-line, since I keep wanting to quote from it, and never have
> it handy.)
Maybe peg Bruce to add a CryptoGram letter on the topic, he's got the
material prepared. S&L is by my side right now, as is AC. That would
be Chapter 15, "Certificates and Credentials"?
> The real-world authentication that tends to work best is... context.
> Which, as it turns out, is the main issue professional document
> examiners scrutinise to detect forgeries (or, in the alternative,
> certify documents as believed to be genuine). A credible document is
> one that not only passes surface examination but also has a believable
> context and history.
> Your e-mails are believed to be from you to the extent they not only
> purport to come from you but also sound like you, sound like something
> you'd say, and aren't credibly repudiated. A fallible system, to be
> sure, but it works well enough most of the time -- and people have
> fallbacks in the case of controversy.
> Which point you're, of course, fully aware of, and have addressed:
> > There's far less context carried in ASCII than the modulations of a
> > human voice, and far less opportunity for realtime challenge-response,
> > even of an informal (and possibly undetectable) manner as would be
> > possible in a phone conversation.
> Now, as far as public key handling is concerned: Distribution and
> revocation are going to remain problems: PKI/CAs and web-of-trust
> aren't magic pixie dust for that. But I can think of something thta
> might help the key-management problem.
Not magic pixie dust, but a level of assurance, _appropriately used_.
See the LSec Wiki node: SecurityIsAProcess
http://lsec.kanga.nu/ (currently offline for a server move, try in a
> Imagine an electronic appliance the size of a keyfob (or credit card)
> that you carry on your person. It holds your private keys, and is just
> smart/flexible enough to sign some set amount of text and spit it back.
> It's not smart/flexible enough to be probed or compromised
> electronically. What's the point? The point is that, ideally, you'd
> never have your private keys on-line except during usage, and you would
> do that only in highly secure circumstances including single-user mode.
> But nobody does this; it's not practical.
Actually, I suspect such security devices may become de rigur as current
trusted systems such as credit cards and authentication cards are found
to be wanting. My Palm Pilot already acts somewhat as such a device, in
that it holds my access keys to numerous systems -- in an encrypted,
password-protected database. While the Palm isn't the perfect
standalone system, it's (again) a pretty reasonable proxy.
The vision that we'll all going to be carrying around a little security
fob (or at least a significant number of us) is probably a reasonable
approximation of a future truth.
> Obstacles include RFI monitoring (but maybe not much of one, given a
> lack of CRTs working directly on the protected device).
Exporting the display of a protected device exports the security threat.
You're speaking of the display of the fob?
Karsten M. Self <firstname.lastname@example.org> http://kmself.home.netcom.com/
What part of "Gestalt" don't you understand? There is no K5 cabal
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 232 bytes
Desc: not available
Url : http://allium.zgp.org/pipermail/linux-elitists/attachments/20010413/b6429148/attachment.pgp
More information about the linux-elitists