Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Alistair Crooks <agc-Q8AzPd93frYdnm+yROfE0A <at> public.gmane.org>
Subject: Re: upstream source code authenticity checking
Newsgroups: gmane.comp.security.oss.general
Date: Friday 26th April 2013 05:41:47 UTC (over 4 years ago)
On Thu, Apr 25, 2013 at 03:40:46PM +0200, nicolas vigier wrote:
> On Thu, 25 Apr 2013, Alistair Crooks wrote:
> 
> > 
> > Q4. where's the public key for this?
> > 
> > A4. could be anywhere. If it's on one of the HKP servers, then cool.
> > Not, however, that it can be verified - I know of at least one person
> > who has had pubkey information uploaded to the key servers for a key
> > he had no knowledge about. Anyone can put whatever email address into
> > the userid that they want. If it came with the tarball, ho hum.
> 
> Even if the key comes with the tarball, if the tarball is always signed
> with the same key for all releases, then it's useful. You download the
> key the first time, keep it somewhere (for instance in the package
> source) and use it again to check next releases. And if a new release is
> signed with a different key you know you need to be more careful and
> can check if the key change is legitimate.

Possibly. You actually know very little about the key before and after the
signing took place; so you have no way of ascertaining whether the key has
been used to sign other things fraudulently. Where a role account is used
to sign packages, this is more worrying.

But, yes, I'm being alarmist here again. I do agree that signing things
is way better than not; but I am also well aware that just because
something
is signed does not mean that it should be treated as being without need of
security.
 
> > Q5. what was signed?
> > 
> > A5.  if it comes out as a text document, according to RFC 4880, it has
> > some weird properties; hopefully all tar files will be binary. 
> > Whatever, what was signed was something with the same digest as the
> > tarball.  Default algorithm is SHA1.  Second pre-image attacks on SHA1
> > are getting closer to being possible, and there are means to modify
> > entries in the tarball so that an attack is much easier.
> > 
> > Q6. Is this a DSA key?  (DSA keys rely on good entropy at signing
> > time) If so, how good was the entropy on the machine used to generate
> > the signature?
> > 
> > A6.  Again, unknown.
> > 
> > Q7. Has someone found the k value for Q6/A6 previously?
> > 
> > A7. They might have done. We'd only know if they told us.
> > 
> 
> Same could be said about ssh, tls or almost anything using cryptography
...

Absolutely, they share the same building blocks - see the Karlsruhe
2010 proceedings for how to interchange ssh and pgp keys for signing
and verification.  And the only difference between SSL and PGP is the
assurance model - whether a trusted third party should be used (FSVO
"trusted"), or whether that should be crowdsourced to the web of trust
model.

Regards,
Alistair
 
CD: 3ms