Re: spatial stuff detail

On Tue, Sep 23, 2003 at 11:21:05PM +0100, Mike Hearn wrote:
> If I was feeling inspired, maybe I'd make one. Unfortunately no matter
> how simple you make the UI, digital signatures are not a zero effort
> thing. You have to import the public key for starters. That's only one
> command for people who want to check my emails, but it's still something
> you've got to do, and *know* that you want to do it.

However, yet again it CAN be automated to a great degree.  For example a
mail program could automatically look up the sender's email addy on a
keyserver and automatically check the signature against that or offer
encryption with that key if sending.  The way it works now is so utterly
stupid no wonder no one uses cryptography much.

> > Just because nobody still hasn't done it right doesn't mean that we should
> > continue to do it crappily because 'that's the way it works'.
> There are tradeoffs, like most things. The web browser security UI is
> good (ie it's non-existant by default), but the tradeoff is that it's
> easier to spoof (because very few people actually check the writing on
> the certificate and they are so easy to get hold of).

However note that the web browser security provides quite a high level of
security with pretty much zero user action.  Any scheme still hinges on some
sort of human factor somewhere.  But you WILL notice if the webpage that
claims to be probably isn't if you get a warning that it has an
unknown certificate.

> > Thinking more about it, it is possible.  Suppose you get a package signed by
> > rather then  Well obviously to the installer this is a
> > new domain name for the installer.  
> How do you determine that something was signed by a domain? This isn't
> SSL, we don't want to centralise trust around VeriSign or link it to DNS
> (not everybody even owns a domain name), or require people to import
> certificates first. All we can know is that "here is a signature, here
> is a public key, do the math and does the answer match?". 
> We have to get both pieces of data from somewhere, both external to the
> package itself, and there's no way for us or the user to know that a key
> is "genuine" other than if it in turn has been signed. Then we get into
> the web of trust, keysigning parties and so on, but this adds a *lot* of
> overhead.

Not really.  If I'm going to check that something came from,
I may just check (I just made that up).  Now
someone that sends you something over email claiming it's from redhat would
have to compromise redhat's server or be in the path between you and

So the installer gets the key independently of the package and does the
check.  Package claims it's "foo", I'm going to go to (or
whatever the mechanism is).  If you are without a domain name or web presence
then you are lost in todays world.

Obviously you can have some web-of-trust, but unlike with email this only has
to be done by the developers.  Which is an obviously several orders of
magnitude smaller number.

> >   The email client should be very careful here about warning the users.
> > A nice signed package from someone we trust should pass without any dialog
> > here then (if security is done right).  You should just be able to click
> > on it or dnd it or whatnot.
> Everybody has to sign attachments now? But you said yourself, this is a
> lot of effort, even with the best UI in the world....

No, it's not a lot of effort with a good UI.  It is a lot of effort now with
a completely whacky and stupid UI.  Oh sorry, absolutely no UI at all.  I
just tried exporting my key and putting it on the web and sending it to a
keyserver.  I have a masters in math so I think I understand ecryption
somewhat, I couldn't figure it out.  This is because gpg is on total crack.

We could however still use GPG, we just need a good UI for it.  And for it to
be seamlessly supported by mailers and package software and whatnot.

> > If W32/Swen looks authentic then it would loose all authenticity if a dialog
> > came up that told you that "no this package was not distributed by
> >, but in fact by".  
> More likely no dialog would come up at all, because nobody non-geek ever
> signs their emails, so that's what they'd expect. And again, you can't
> tie them to domain names without certificate authorities, which are
> notoriously hard to get right (think Verisign)

But the mailer would give nefarious dialogs for non-signed executable

> Oh, well, it's not that hard. I was kind of surprised really:
> $ gpg --gen-key
> (give it the data it wants)
> (upload the public key somewhere....)
> (somebody else imports it)
> $ gpg --verify (to check something that's been digitally signed)
> Still too complex of course. And you have to grok the concept of signing
> stuff in the first place, which is really abstract and most people don't
> care enough about it to want to know.

But it doesn't have to be complex.  Most people know the concept of what
'signing' means since they do it to credit card bills and letters and
contracts and whatnot.  If you make it not so obfuscated and easier to do
(for one without any scary cryptography lingo) it would actually not be
any harder than signing with a pen.

> > But if it's easy to install packages, someone will start distributing virii
> > as such.  I'm not saying we're well prepared for the 'random binary'
> > execution scenario either.
> Remember that we've been using source tarballs for years, which are
> scarily easy to trojan (think 100,000 line configure scripts). It's only
> happened a few times, as far as I know, and in both cases I can think of
> the FTP server hosting it was cracked (which means you can fiddle the
> keyfiles/signatures etc)

Note that free software is still not THAT popular, and also note that
trojaning a tarball has minimal effect because of the number of people that
actually compile stuff from sources.

If you get packages from the original source, then obviously there's no real
need for signing.  However if you do get a package by mail (which might get
much more common if people send each other "check out this cool game" mails)

> .... so it's worthless. This stuff is much harder than it first appears,
> which is why we're making it optional for now. The cost/benefit analysis
> doesn't really look that great :(

So it will be much harder always because no one takes the step of figuring
out how to do it easily and safely.


George <jirka 5z com>
   Life is what happens to you when you're busy making other plans...
                       -- John Lennon

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]