Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 26 Apr 2013 07:24:24 +0200
From: Alistair Crooks <>
Subject: Re: upstream source code authenticity checking

On Thu, Apr 25, 2013 at 08:55:00AM -0400, Josh Bressers wrote:
> > 
> > So, all in all, what you have is a digest, signed by someone who knows
> > the key, or who has access to the creds (if any) for the key, or who
> > has found out the key creds, albeit with timestamp info for when the
> > signature took place.
> > 
> > I'm not sure what using PGP gains us?
> > 
> I'm going to take a hard stance against this statement and use it as my
> soapbox for a bit here.
> This attitude is really dangerous in the world of security (but it has
> infected our universe). Security is hard, we all know that, but I think we
> like to draw a line at 100% and say "it's this or nothing". No, PGP isn't
> perfect, but it gains us a ton. It's a way we can say "this was signed by
> someone with the key". Did the bad guy have they key? Maybe, the goal isn't
> to get to 100%, it's to make the job of an attacker harder, which this
> would do.
> There is no system that exists in this instance that is 100% safe. What we
> need to do isn't talk about how useless PGP is (which it isn't), we need to
> talk about what's right about it and give advice so people understand how
> to avoid silly mistakes.

I think you misunderstand me. The mail I sent out was to warn against the
magic "it's signed, so it's gospel" myth by pointing out the problems of
key management. I have written my own pgp/rfc4880 implementation, and talked
about it at EuroBSDcons in 2009, 2010, 2011. I would hardly do that if i
thought PGP was "useless". It's a bit disappointing that my advice (in pointing
out ways that PGP can be worked around in order to diminish integrity and
security) was categorised as an attack on PGP itself - I shall take that as
a reminder that I should be more clear in what I write.
> A great example is to use a smart card. If a project is using a smart card,
> and tells us they're using a smart card, that would be helpful in letting
> us know their signatures are probably trustworthy. We would certainly know
> their signatures are more trustworthy than a project who uses a private key
> shared between 10 people. Is the smart card a perfect solution? Certainly
> not, but it's better than not using a smart card. How many non security
> people really understand this? How many of us have tried to explain it in a
> calm and understanding manner?

I fail to see how "using a smartcard" automatically leads to
signatures "probably being trustworthy".  Lest I'm misunderstood again
- 2 factor authentication is good, yes, but you need to look at the
set up holistically. If an unauthorised third party has root on the server
being used to control the 2 factor auth, then you are in a worse
position than not using 2 factor auth.  Consider the SSL business
model where the CAs have considerable motivation not to disclose
intrusions, mis-issued certs and other such items.  In the case of
Diginotar, they were put out of business.

And before people start telling me to get real, I'll point out that
most enterprises these days have a basic assumption that they have
been hacked, and are building "more secure" islands to try to fence
intrusions in.
> This is Red Hat's goal here. We want to help folks understand what some
> easy wins are. Security is hard, it will never be 100%. I'd rather see us
> all working together to improve what we can.

I'm all for rasing the bar. My previous mail was intended to make people
think about the processes and procedures behind key management - I'm sorry
it failed so dismally. I shall attempt to do better next time.

If Red Hat document their key management procedures, that would be
great.  Having these procedures audited would be superb (albeit a very
brave step), and I would be very impressed if they did.  I'm not sure
security is as hard as you're making out, although I'm aware that
there's no silver bullet.

Onwards and upwards...


Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.