Re: dpkg-sig support wanted?

2005-12-01 Thread Henning Makholm
Scripsit Florian Weimer [EMAIL PROTECTED]

 This means that it's dangerous to commit yourself to the contents of a
 document, using a digital signature, unless you fully understand the
 meaning of each byte in the document.

So how do the MD5 sums of .debs end up in a Packages file signed with
the archive key? Do the ftpmasters go over each file with a
disassembler, fully understanding the meaning of each byte in the .deb?

 (Note the rub.de part of the URL.  A clear warning sign.)

 The nice thing about ad hominem arguments is that you can make them
 without ever having to argue the merits of your case.

 *shrug* The computer security folks at that university started
 spreading FUD about various security systems, mainly rehashing the
 work of others.  They seem to be in it mostly for the publicity.

More ad hominem arguing.

-- 
Henning Makholm   Jeg mener, at der eksisterer et hemmeligt
 selskab med forgreninger i hele verden, som
 arbejder i det skjulte for at udsprede det rygte at
  der eksisterer en verdensomspændende sammensværgelse.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Re: dpkg-sig support wanted?

2005-12-01 Thread Mike Paul
 A cryptographer friend of mine recently attended the NIST Hallowe'en
 Hash Bash (http://www.csrc.nist.gov/pki/HashWorkshop/index.html), and
 made a few notes in his blog:
 
   http://www.livejournal.com/users/sevenstring/7326.html
 
 His suggestion there was stick to SHA2 (or maybe Whirlpool) for now.
 Did anyone else here attend this workshop?

I attended, and the message I got was:  use SHA-256 (or SHA-512 if you
want to be cautious) for new applications, but consider it to be an
interim solution for the 5-10 year timeframe until something better is
devised, and have the agility to switch to that something better when
it comes; most importantly, stop using MD5 ASAP.

Regarding your friend's suggestion to stick with SHA2 (or maybe
Whirlpool) for now, what I wrote in my notes was:

  * Asked about which two functions would be best to use in
parallel, suggestions were SHA-256+(Whirlpool/Tiger).

One of the panelists explained, though, that using two different hash
functions and concatenating the output yields a result which is not
significantly more secure than either of the functions by itself.  And
the SHA family of functions were the predominant topic of the workshop;
others, such as Whirlpool, were mentioned only occasionally.

Some choice quotes from Niels Ferguson:

SHA-1 is a wounded fish in shark-infested waters.
Switch away from SHA-1 as soon as you can, but switch away from
MD5 first.

It's true that MD5 and SHA-1 are still acceptable for certain uses where
the current attacks aren't a threat, but Ferguson argued that it's much
easier and safer to replace them entirely than to try to analyze which
uses are still OK.

Also from my notes:  SHA-1 is OK for ephemeral uses, but not for
non-repudiation and certification -- essentially, if it matters that the
signature be verified by a third party, not just the recipient, avoid
SHA-1.

Some people wanted NIST to specify an approximate target year for a hash
standard to be issued, like they did for AES.  Bruce Schneier said we
don't know hashing well enough, like we knew about block ciphers for
AES, and recommended that we wait ten years.

Several people requested that NIST publish the design criteria with
which SHA-1 was designed, but I don't remember hearing a definitive
answer to that.

(Note that I'm not a cryptographer; I attended simply as an interested
individual.)
-- 
Mike Paul [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part


Re: dpkg-sig support wanted?

2005-11-30 Thread Florian Weimer
* Henning Makholm:

 Scripsit Florian Weimer [EMAIL PROTECTED]
 * Jochen Voss:

 I found the example at http://www.cits.rub.de/MD5Collisions/ quite
 impressive.  They have two different valid PostScript files with
 identical MD5 sums.  I don't know how much computing time they used,
 though.

 They claim a few hours:

 | Based on [WY05] and the analysis described in [Da], we implemented
 | an attack to find random collisions for the MD5 compression
 | function. It took just a few hours on a customary PC.

I can no longer recall if this paragraph was present in the original
version of the page; I didn't notice it when I read it for the first
time.

 None, many of these examples were created before the collision
 generation tools were generally available.

 They did create or use a collision, as anyone can verify simply by
 downloading the files.

One collision was published by Wang et al. as a zero-knowledge proof
of their discovery.  I thought they had reused this one, like many
others did.

 The exploit uses some properties of Postscript files which make
 them not very desirable for storing electronic documents which
 cannot be altered.

 There is absolutely no reason to put the word exploit in scare quotes
 here.

Strictly speaking, you cannot exploit MD5 itself, you can only exploit
security systems that rely on some property of the MD5 function.

Let's look what happens in the attack published by the RUB
researchers:

  1. The attacker creates two Postscript files with the same MD5 hash.
  2. The attacker submits one of the file to the victim.
  3. The victim views the file in his Postscript viewer, doesn't notice
 anything strange, and signs it.
  4. The attacker obtains the signature, and uses it together with the
 second file he has created.

A successful attack is possible if the following conditions are met:
(a) the attacker can create a suitable collision, (b) the victim uses
the document supplied by the attacker, (c) the victim only checks one
presentation form of the document, and (d) the document is used in a
way which does not lead to the victim disputing the signature, and
into investigation (which would immediately reveal the attack).

It turns out that we can actually do without (a).  Have a look at the
attached Postscript with your favorite Postscript viewer, and sign it
if you agree with its message. 8-)

In my opinion, this modified attack strongly suggest that the process
described above is already substantially broken.  MD5 is just a weak
part among others.  As a result, the attack doesn't show what people
claim.

Just be clear: I don't claim everything is alright with MD5.  For most
applications, you should definitely migrate to something else (what is
a different question).  But most organization's resources are limited,
you can't afford to migrate too often, and you deal with many issues
at once.  Correctly analyzing the relevance of security issues is very
important.  Misleading claims about the impact of new attacks are not
helpful, may lead to wrong allocation of resources, and prevent more
important vulnerabilities from being addressed.

 You might want to notice that the properties you apparently think
 invalidate the example are also shared by many common formats for
 software. An ELF binary can easily be crafted to contain a blob of
 initialized data whose contents are only used for checking whether to
 enable some malicious machine code that is always present - and this
 would not be easily detectable at all.

In general, any form of malicious code is not easy to detect.  But the
malicious code must be present in the first place.  You can use a MD5
collision to make it dormant, but it has to be there.

This means that it's dangerous to commit yourself to the contents of a
document, using a digital signature, unless you fully understand the
meaning of each byte in the document.

 (Note the rub.de part of the URL.  A clear warning sign.)

 The nice thing about ad hominem arguments is that you can make them
 without ever having to argue the merits of your case.

*shrug* The computer security folks at that university started
spreading FUD about various security systems, mainly rehashing the
work of others.  They seem to be in it mostly for the publicity.



psTcrNiJNRKU.ps
Description: PostScript document


Re: dpkg-sig support wanted?

2005-11-30 Thread Colin Watson
On Mon, Nov 28, 2005 at 07:07:22PM +1000, Anthony Towns wrote:
 (Note that dsum would probably need to become Priority:required,
 and possibly Essential:yes, with the complications that entails)

Stick it in dpkg.deb. There's plenty of precedent for that (some
not-so-good, but I think mostly good).

-- 
Colin Watson   [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: dpkg-sig support wanted?

2005-11-30 Thread Colin Watson
On Tue, Nov 29, 2005 at 02:20:55PM +0100, Florian Weimer wrote:
 * Anthony Towns:
  On Sat, Nov 26, 2005 at 10:59:57AM +0100, Florian Weimer wrote:
  In terms of security, there are some better hash functions.  
 
  My understanding was that there aren't other hash functions that've had
  remotely similar levels of cryptographic analysis to md5 and sha.
 
 Neither MD5 nor SHA1 have received much public scrutiny.  Dobertin's
 work on MD5 has never been fully published.  I've already joked that
 the difference between Wang et al. and European or U.S. cryptographers
 is that the Chinese government doesn't tell their researchers not to
 publish their results. 8-P
 
  IIRC, the elliptic curve cryptography stuff was supposed to be
  similarly neat, until people started analysing it seriously, at
  which point it broke.
 
 The NSA has recently licensed ECC patents from Certicom.
 
 There are weak elliptic curves as far as cryptography is concerned,
 but there are also others: inefficient ones and those which have been
 patented by Certicom.

A cryptographer friend of mine recently attended the NIST Hallowe'en
Hash Bash (http://www.csrc.nist.gov/pki/HashWorkshop/index.html), and
made a few notes in his blog:

  http://www.livejournal.com/users/sevenstring/7326.html

His suggestion there was stick to SHA2 (or maybe Whirlpool) for now.
Did anyone else here attend this workshop?

That said, I suspect that any my favourite algorithm argument is going
to get horribly bogged down in bikeshedding. As long as we don't fall
into the multicollisions trap of spending more and more CPU time
generating and checking more and more iterative hash functions that
don't actually add significant collision-resistance when you check them
all together, a generalised checksumming tool as proposed seems an
obviously sensible and desirable thing to have.

-- 
Colin Watson   [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: dpkg-sig support wanted?

2005-11-30 Thread Anthony Towns
On Tue, Nov 29, 2005 at 02:20:55PM +0100, Florian Weimer wrote:
  not even be out of the question to find someone who'll sponsor an upload
  without rebuilding the .deb. I think it's safe to imagine that there are
  developers right now who've done some shady things in the past; is it
  that far fetched to imagine it's worth protecting against developers
  who try to abuse their priveleges?
 No, but they can directly upload a bad package.  No need to create an
 MD5 collision and sneak the evil twin package into some mirror
 archive.

Sure; someday, maybe some of the test suite stuff will allow us to avoid
that, but at the moment we can't. What we can do now is limit the chances
that people will get away with that.

 Have we already done that?  Have we expelled people becaue they put
 vulnerable code into Debian?

We've expelled people for violating the DMUP in other ways; and we've
stopped distributing micq because it included upstream code that could
reasonably be called an exploit.

 You can embed code that checks for characteristics of the victim
 system and activate the attack only if there's a match.

Sure, these things aren't perfect; but they're a help.

Anyway, I'm not going to waste my time further arguing why we shouldn't
continue using a hash that's had a practical exploit published on
slashdot.

Cheers,
aj



signature.asc
Description: Digital signature


Re: dpkg-sig support wanted?

2005-11-29 Thread Goswin von Brederlow
Thomas Bushnell BSG [EMAIL PROTECTED] writes:

 Goswin von Brederlow [EMAIL PROTECTED] writes:

 The archive signing key gives absolutely no integrity ensurance on the
 deb package. The only thing it insures is that the file was not
 altered _after_ leaving ftp.de.debian.org for the mirrors and/or
 user. In no way does it prevent altering the deb on ftp-master.

 Isn't that a useful assurance?  Perhaps I trust the maintenance of
 ftp-master, but not the maintenance of Joe Random Mirror.

It sure is usefull as it removes a lot of untrusted steps from being a
vulnerability. But that doesn't help if the attack happens at
ftp-master.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: dpkg-sig support wanted?

2005-11-29 Thread Goswin von Brederlow
Steinar H. Gunderson [EMAIL PROTECTED] writes:

 On Sat, Nov 26, 2005 at 09:13:02AM +1000, Anthony Towns wrote:
 Moving away from MD5 is certainly not a bad idea, but it's not clear
 whether the alternatives are any better.  Sure, everyone recommends
 SHA-256 at this stage, but nobody can give a rationale.
 MD5 is broken; SHA-1 is where MD5 was a couple of years ago, SHA256 (or
 higher) are significantly harder to break in practice, and there's
 nothing better yet.

 Just a comment here for those who are not used to hash functions: Broken
 here means that you can generate collisions faster than using the birthday
 attack (2^64 for MD5, 2^80 for SHA-1). It does not have to mean that you
 can do _really_ evil stuff, like generate a second file with the same MD5
 hash as a given file (so-called second preimage, IIRC) and to the best of
 my knowledge, nobody has done so yet).

According to slashdot articles you can generate human readable files
(like the Packages file) with md5sum collision in ~45minutes on a
modern cpu now.

I think that counts as broken. Luckily for us we also have the size of
the file.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: dpkg-sig support wanted?

2005-11-29 Thread Goswin von Brederlow
Anthony Towns aj@azure.humbug.org.au writes:

 On Fri, Nov 25, 2005 at 12:49:11PM -0800, Thomas Bushnell BSG wrote:
 Anthony Towns aj@azure.humbug.org.au writes:
  .deb signatures are aimed at giving users some sort of assurance the
  package is valid; but when you actually look into it -- at least in
  Debian's circumstances -- those signatures can't actually give any
  meaningful assurance for any specific validity.
 Don't they give the user the assurance that a Debian developer was
 responsible for building and providing the package?

 Not really, they give the assurance that it was built by someone who at
 some point possessed a key that at some point was considered sufficient
 to identify a Debian developer or a buildd.

 What assurance would you take from a package signed by Chip's old key?

 (And why do you think it's actually helpful? Debian developers build
 *lots* of crap, especially if you can't differentiate stuff uploaded to
 Debian and not)

 Cheers,
 aj

They also upload *lots* of crap. Should we stop using Release.gpg now?

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: dpkg-sig support wanted?

2005-11-29 Thread Florian Weimer
* Anthony Towns:

 On Sat, Nov 26, 2005 at 10:59:57AM +0100, Florian Weimer wrote:
 For the exploits we have seen so far to work, the malicious party
 needs upload access to the archive and has to plant a specially
 crafted package there, for which they have created an evil twin
 package.  (Same for attacking one of the text files listing hashes.)
 Looks a bit far-fatched to me.

 Not really. Joining Debian isn't particularly difficult, and it might
 not even be out of the question to find someone who'll sponsor an upload
 without rebuilding the .deb. I think it's safe to imagine that there are
 developers right now who've done some shady things in the past; is it
 that far fetched to imagine it's worth protecting against developers
 who try to abuse their priveleges?

No, but they can directly upload a bad package.  No need to create an
MD5 collision and sneak the evil twin package into some mirror
archive.

 The way we do that has to be mostly after the fact, of course: someone
 uploads a bad package, people find out it's bad, we trace it back to
 whoever uploaded it, then we kick them out of the project.

Have we already done that?  Have we expelled people becaue they put
vulnerable code into Debian?

 But that only works if the bad package is actually discovered. If the
 .deb's distributed across hundreds of mirrors and to thousands of users,
 it's reasonably likely that it will be discovered; but if it's possible
 to target the attack against an individual user, and leave the rest of
 the Debian universe untouched, you've got a much better chance of
 not getting caught. Hence: distribute an iced .deb in the archive, that
 does no harm ever and thus needn't arouse any suspicion; and sneak a
 fire .deb that has the exploit activated onto the mirror of your target.

You can embed code that checks for characteristics of the victim
system and activate the attack only if there's a match.  The advantage
is that you need only to compromise a DD account (or become a DD
yourself), and not both a DD account and part of the mirror cascade
which is used by the victim.

 Looks a bit far-fetched comes under the famous last words heading
 for security analysis.

One part of security analysis is figuring out which potential attacks
are relevant.  Keep in mind that most attacks never happen.  There's
no point in wasting resources on irrelevant attacks.  It's
embarrassing to be wrong on such matters, in both directions.  Money
thrown at a problem that turns out to be a non-issue is money lost.
But you hardly ever read about those failures.

There is one attack on MD5 which is a significant threat to many
companies: the PR attack.  There are many, many security experts who
are all too willing to label your system as broken just because it
uses MD5 internally.  With the right media spin, such claims of
insecurity can become a PR nightmare and very costly.

 Worse, the existance of a practical md5(A+B+C)=md5(A+D+C) attack means
 that it's not out of the question that there're md5(A+B)=md5(C+D)
 attacks in the hands of particularly well resourced groups (which is
 worse, since the version uploaded to the archive could then be entirely
 innocent looking). Personally, I don't have any interest in making the
 NSA's job any easier, or that of other signals intelligence groups.

Oh, many Debian packages happily leak so much data over the network
that I often wonder if it is feasible to create user profiles using
this information. 8-)

 SHA256 is better than SHA1 in the same way 2048 bit RSA keys are better
 than 512 bit RSA keys.

No, the algorithms are somewhat different.  It's easy to build a 256
bit hash which is less secure than a 160 bit hash, so it's not really
comparable to the RSA situation.

 MD5 is broken, and isn't extensible. SHA1 is fragile, but not
 broken, and is extensible.

What do you mean with extensible?  Both MD5 and SHA1 are based on
MD4, and SHA256 is based on SHA1, but AFAIK, no rationale for the
changes from MD4 - SHA1 and SHA1 - SHA256 has been published.  (Ron
Rivest explained his changes from MD4 to MD5.)

 In terms of security, there are some better hash functions.  

 My understanding was that there aren't other hash functions that've had
 remotely similar levels of cryptographic analysis to md5 and sha.

Neither MD5 nor SHA1 have received much public scrutiny.  Dobertin's
work on MD5 has never been fully published.  I've already joked that
the difference between Wang et al. and European or U.S. cryptographers
is that the Chinese government doesn't tell their researchers not to
publish their results. 8-P

 IIRC, the elliptic curve cryptography stuff was supposed to be
 similarly neat, until people started analysing it seriously, at
 which point it broke.

The NSA has recently licensed ECC patents from Certicom.

There are weak elliptic curves as far as cryptography is concerned,
but there are also others: inefficient ones and those which have been
patented by Certicom.


-- 
To UNSUBSCRIBE, email 

Re: dpkg-sig support wanted?

2005-11-29 Thread Goswin von Brederlow
Steve Langasek [EMAIL PROTECTED] writes:

 On Fri, Nov 25, 2005 at 02:57:36PM +0100, Goswin von Brederlow wrote:
 Steve Langasek [EMAIL PROTECTED] writes:

  On Thu, Nov 24, 2005 at 07:17:06PM +0100, Goswin von Brederlow wrote:

   That's easy: you trust the Packages file to be correct when using apt,
   and it's not verified at all by per-package signatures.

  In what way trust and how does that change anything?

  At best you can prevent a newer version of a package to appear in the
  Packages file by compromising it. You can't subvert a package itself.
  But you can already ship yesterdays Release.gpg, Release and Packages
  file to a user and thereby prevent any updates.

  On the other hand, without package signatures ftp-master adds a
  vulnerability. You can hack into it, replace debs, recreate the
  Packages, Release and Release.gpg file and thereby infect users. With
  signed debs that could still be detected by every user in apt-get.

  Only if every user is in a position to verify signatures from each Debian
  developer individually, which is completely unrealistic.

 Up to a point you can trust the keyring. As much as you can trust any
 DD signature. You try to argue that signatures are not absolutely
 trustworthy but that is nothing new.

 I'm arguing that a 5-hop-long signature chain to establish the validity of a
 Debian package is as good as useless, and worse if the user doesn't
 understand this.

 And a 5-hop-long signature chain does *not* mean that anyone in that chain
 trusts the person holding the key on the end to upload packages to Debian.

They aren't ment to. The in-deb signature by the DD is only ment to
say I did build this.

 The only thing we have that establishes *that* is the presence of the user's
 key in the Debian keyring, so then you have the logistical problem of how
 arbitrary users are supposed to verify whether a given key is in the

They aren't supposed to. They just should have the possibility.

 keyring.  The debian-keyring package doesn't get updated every time there's
 a key added or removed, and the web interface to keyring.debian.org doesn't
 provide any cryptographic assurances.  Oh, and BTW, check the IPs of
 ftp-master.debian.org and keyring.debian.org...

The amount of package that fall through the cracks due to the keyring
not being fully updates is marginal. You can also ask keyservers for
keys and verify them through your trust path. That is enough to
establish who build the deb (not to be confused with for whom did he
build it).

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: dpkg-sig support wanted?

2005-11-29 Thread Goswin von Brederlow
Steinar H. Gunderson [EMAIL PROTECTED] writes:

 On Sat, Nov 26, 2005 at 10:47:57AM +1100, Brian May wrote:
 Well, even if I know naught about it, it looks to me that having
 something signed is better than having the same something not signed.
 Sorry, but that's a snake oil rationale.
 A: Why do you lock your car up[1]?

 Because it makes it harder to steal the car.

 I think the point was that signing a .deb did not automatically make it
 harder to do whatever the scenario asked for.

 /* Steinar */

Why do you put a serial number on the car?

So you can trace it back to the true owner when you find a car that
was repainted.

MfG
Goswin



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: dpkg-sig support wanted?

2005-11-29 Thread Goswin von Brederlow
Anthony Towns aj@azure.humbug.org.au writes:

 On Fri, Nov 25, 2005 at 03:13:58PM +0100, Goswin von Brederlow wrote:
  You're correct.
 And he is also wrong.
 That would result in debs with the same name and version but different
 md5sums. Something that easily confuses apt-get and people.

 And yet, somehow people manage partial cross-grades between Debian and
 Ubuntu...

 Regards,
 aj

I said confuse. Doesn't mean it won't work at all. But apart from
stuff not getting cross-graded (as you put it) you can also end up in
loops that will re-cross-grade a package every time you apt-get
upgrade and the like.

Having apt-get say there is a new version of foo available every day
is damn anoying.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: dpkg-sig support wanted?

2005-11-29 Thread Jochen Voss
Hi!

On Tue, Nov 29, 2005 at 02:08:45PM +0100, Goswin von Brederlow wrote:
 According to slashdot articles you can generate human readable files
 (like the Packages file) with md5sum collision in ~45minutes on a
 modern cpu now.
I found the example at http://www.cits.rub.de/MD5Collisions/ quite
impressive.  They have two different valid PostScript files with
identical MD5 sums.  I don't know how much computing time they used,
though.

All the best,
Jochen
--
http://seehuhn.de/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: dpkg-sig support wanted?

2005-11-29 Thread Florian Weimer
* Jochen Voss:

 On Tue, Nov 29, 2005 at 02:08:45PM +0100, Goswin von Brederlow wrote:
 According to slashdot articles you can generate human readable files
 (like the Packages file) with md5sum collision in ~45minutes on a
 modern cpu now.

 I found the example at http://www.cits.rub.de/MD5Collisions/ quite
 impressive.  They have two different valid PostScript files with
 identical MD5 sums.  I don't know how much computing time they used,
 though.

None, many of these examples were created before the collision
generation tools were generally available.  The exploit uses some
properties of Postscript files which make them not very desirable for
storing electronic documents which cannot be altered.  For example, it
is possible to create a Postscript file whose output, when printed,
varies from printer to printer.

(Note the rub.de part of the URL.  A clear warning sign.)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: dpkg-sig support wanted?

2005-11-29 Thread Henning Makholm
Scripsit Anthony Towns aj@azure.humbug.org.au
 On Mon, Nov 28, 2005 at 10:15:34PM +0100, Henning Makholm wrote:

 I would expect something like
 $ dsum -a sha1 COPYING; sha1sum COPYING
 s.w4runjyMTV1ZT_VIob4FRTAjAW1ihpMfZRLbIV7B_UI  COPYING

 sha1sum already exists; and isn't that long. Do you mean sha256?

Feh. Yes, I meant SHA-256. Sorry for the confusion.

-- 
Henning Makholm  What has it got in its pocketses?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: dpkg-sig support wanted?

2005-11-29 Thread Henning Makholm
Scripsit Florian Weimer [EMAIL PROTECTED]
 * Jochen Voss:

 I found the example at http://www.cits.rub.de/MD5Collisions/ quite
 impressive.  They have two different valid PostScript files with
 identical MD5 sums.  I don't know how much computing time they used,
 though.

They claim a few hours:

| Based on [WY05] and the analysis described in [Da], we implemented
| an attack to find random collisions for the MD5 compression
| function. It took just a few hours on a customary PC.

 None, many of these examples were created before the collision
 generation tools were generally available.

They did create or use a collision, as anyone can verify simply by
downloading the files. Whether or not they used a generally available
tool is not important to the fact that a collision was actually
generated.

 The exploit uses some properties of Postscript files which make
 them not very desirable for storing electronic documents which
 cannot be altered.

There is absolutely no reason to put the word exploit in scare quotes
here.

You might want to notice that the properties you apparently think
invalidate the example are also shared by many common formats for
software. An ELF binary can easily be crafted to contain a blob of
initialized data whose contents are only used for checking whether to
enable some malicious machine code that is always present - and this
would not be easily detectable at all.

The only thing that would seem to make it less than straightforward to
craft a similar attack consisting of two different .deb files with the
same MD5 sum of which one behaves maliciously, is the need to trick
the CRC-32 in the gzip trailer for data.tar.gz simultaneously with
tricking MD5.

But a CRC-32 is, to put it mildly, not much of a defense against a
determined attacker! All it takes to beat *that* is finding at most 33
different MD5 single-block collisions in sequence; it is then a matter
of extremely simple linear algebra find a nontrivial combination of
them that cancel out each other's effect on the CRC.

Note that the gzip compression format allows blocks of compressed data
to specify use of the no compression algorithm, so injecting your
collisions in a gzipped data stream is trivial, too.

 (Note the rub.de part of the URL.  A clear warning sign.)

The nice thing about ad hominem arguments is that you can make them
without ever having to argue the merits of your case.

-- 
Henning Makholm   I always thought being *real* sad
would be *cooler* than acting *fake*
 sad, but it's not. It's not cool at *all*.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: dpkg-sig support wanted?

2005-11-29 Thread Jochen Voss
Hi Florian,

On Tue, Nov 29, 2005 at 03:24:54PM +0100, Florian Weimer wrote:
 None, many of these examples were created before the collision
 generation tools were generally available.  The exploit uses some
 properties of Postscript files which make them not very desirable for
 storing electronic documents which cannot be altered.
Do you mean the ability to embed comments into the file?
Several other formats allow this, too.

 For example, it is possible to create a Postscript file whose
 output, when printed, varies from printer to printer.
How is this related to their examples?

 (Note the rub.de part of the URL.  A clear warning sign.)
This is the university of Bochum, Germany, isn't it?
Should I be afraid of them?

All the best,
Jochen
-- 
http://seehuhn.de/


signature.asc
Description: Digital signature


Re: dpkg-sig support wanted?

2005-11-28 Thread Anthony Towns
On Sat, Nov 26, 2005 at 11:10:27PM -0600, Peter Samuelson wrote:
   sha256sum () {
 (Implementation of -c left as an exercise, etc.)

Hrm, if we're writing our own thing, maybe we should do it properly:
have a single program that can do multiple hash algorithms, have the
default hash be secure, and update it in future, and so on.

gnupg comes close to being this, except for two things: it's got too
many dependencies, and it's command line arguments are overly complex. A
gpgh variant (like gpgv but for hashing) might work, though. It
doesn't support --check, and gpg --print-md md5 /etc/motd has a
different format to md5sum /etc/motd though.

Of course, if we're doing it right, we probably want to have some way
of telling what hash was used, so we don't have to wonder whether a
given 160bit hash is sha1 or ripemd160 or something else that gets
cooked up in future. OpenBSD's cksum apparently does this, by having its
output be:

  MD5 (filename) = hash

That strikes me as pretty inconvenient, but cksum does do most of what we
want.

OTOH, it would be far more convenient for *us* if it supported the
.changes style we use, ie:

  MD5Sum:
hash size filename

Then there are the encoding questions; both the one above (do we switch
from hexadeximal to something more compact for longer hashes?) and also
the question of what happens if there's a ) or a \n in the filename
-- is it worth doing some sort of http-style % encoding that apt uses
in that case?

Something like this might work well:

  $ dsum -a sha1 foo; sha1sum foo
  f572d396fae9206628714fb2ce00f72e94f2258f  foo
  f572d396fae9206628714fb2ce00f72e94f2258f  foo

  $ dsum -d foo
  SHA1Sum:
   f572d396fae9206628714fb2ce00f72e94f2258f 6 foo

  $ dsum -b foo
  SHA1 (foo) = f572d396fae9206628714fb2ce00f72e94f2258f

  $ dsum -d foo | dsum --check; echo $?
  0

  $ dsum -b foo | dsum --check; echo $?
  0

Though what dsum foo should do is a trickier question (particularly
whether it's better to be compatible with current md5sum/sha1sum
output, or if dsumA foo  foo.sum and dsumB --check  foo.sum will
work if dsumA's default cypher is sha1 and dsumB's is ripemd160).

(Note that dsum would probably need to become Priority:required,
and possibly Essential:yes, with the complications that entails)

Cheers,
aj



signature.asc
Description: Digital signature


Re: dpkg-sig support wanted?

2005-11-28 Thread Peter Samuelson

[Anthony Towns]
 gnupg comes close to being this, except for two things: it's got too
 many dependencies, and it's command line arguments are overly
 complex.  A gpgh variant (like gpgv but for hashing) might work,
 though. It doesn't support --check, and gpg --print-md md5
 /etc/motd has a different format to md5sum /etc/motd though.

I think it's important to support md5sum/sha1sum format, in cases where
md5 or sha1 are used, so people can conveniently use --check with their
existing binaries.  That might be just me, though.

 Of course, if we're doing it right, we probably want to have some
 way of telling what hash was used, so we don't have to wonder whether
 a given 160bit hash is sha1 or ripemd160 or something else that gets
 cooked up in future.

For large files, getting a cryptographic checksum is more about reading
blocks off the disk than about CPU time.  So it wouldn't be completely
ridiculous to allow sha-1 to remain ambiguous with competing 160-bit
hashes, and have --check check for all of them (reading the file only
once).

I still think two-byte prefixes for non-md5-non-sha1 hashes makes some
sense, like s- for sha-256.  Avoids the filename encoding issue you
mentioned later (unless we want to encode newlines).

 OTOH, it would be far more convenient for *us* if it supported the
 .changes style we use, ie:
 
   MD5Sum:
 hash size filename

This might be generally reasonable, but we do want our dsum tool to
work with arbitrary MD5SUMS style files.  And if such files require a
hash-type header, dsum will have to produce one, at least optionally.
I really like the default behavior of our existing md5sum outputting
just a single line per file, and nothing more.

   $ dsum -a sha1 foo; sha1sum foo
   f572d396fae9206628714fb2ce00f72e94f2258f  foo
   f572d396fae9206628714fb2ce00f72e94f2258f  foo
 
   $ dsum -d foo
   SHA1Sum:
f572d396fae9206628714fb2ce00f72e94f2258f 6 foo
 
   $ dsum -b foo
   SHA1 (foo) = f572d396fae9206628714fb2ce00f72e94f2258f

What's the  6  above?  Surely not a hollerith-like string.  Other
than that, I like your proposed command line quite a lot.

 (Note that dsum would probably need to become Priority:required,
 and possibly Essential:yes, with the complications that entails)

Hmmm, promoting libgcrypt11 + libgpg-error0 to Required adds 516 kB on
i386, plus a trivial amount for dsum itself.  I wonder if it'd be
better to just copy / paste the algorithm code into dsum.


signature.asc
Description: Digital signature


Re: dpkg-sig support wanted?

2005-11-28 Thread Henning Makholm
Scripsit Peter Samuelson [EMAIL PROTECTED]

 For large files, getting a cryptographic checksum is more about reading
 blocks off the disk than about CPU time.  So it wouldn't be completely
 ridiculous to allow sha-1 to remain ambiguous with competing 160-bit
 hashes, and have --check check for all of them (reading the file only
 once).

That sounds cryptographically unsafe. It would mean that a practical
preimage attack against _any_ of the supported hashes would break the
entire system. That's not the kind of algorithm agility we need.

 I still think two-byte prefixes for non-md5-non-sha1 hashes makes some
 sense, like s- for sha-256.

That is much better. But let's use s. as a prefix and do a
[/+] - [_-] substitution on the following base64 data. The dot
in the prefix will prevent the prefix from being mistaken as part of a
slightly larger non-tagged hash value.

   $ dsum -a sha1 foo; sha1sum foo
   f572d396fae9206628714fb2ce00f72e94f2258f  foo
   f572d396fae9206628714fb2ce00f72e94f2258f  foo

There appears to be to few characters of hash there, at least unless
it is a cosmically weird coincidence that it base64 encodes to all hex
digits. :-)

I would expect something like

$ dsum -a sha1 COPYING; sha1sum COPYING
s.w4runjyMTV1ZT_VIob4FRTAjAW1ihpMfZRLbIV7B_UI  COPYING
s.w4runjyMTV1ZT_VIob4FRTAjAW1ihpMfZRLbIV7B_UI  COPYING
$ dsum -a sha1 -a md5 COPYING
s.w4runjyMTV1ZT_VIob4FRTAjAW1ihpMfZRLbIV7B_UI  COPYING
4325afd396febcb659c36b49533135d4  COPYING
$ echo m | sha1sum -
s.-tUTs04N4IxBOtWpdoIXt1b0qgHIgNm9IC_OgYjm-mU  -

-- 
Henning MakholmBut I am a Sunni Muslim, the bemused Arab said.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: dpkg-sig support wanted?

2005-11-28 Thread Anthony Towns
On Mon, Nov 28, 2005 at 10:15:34PM +0100, Henning Makholm wrote:
 I would expect something like
 $ dsum -a sha1 COPYING; sha1sum COPYING
 s.w4runjyMTV1ZT_VIob4FRTAjAW1ihpMfZRLbIV7B_UI  COPYING
 
sha1sum already exists; and isn't that long. Do you mean sha256?

Cheers,
aj



signature.asc
Description: Digital signature


Re: dpkg-sig support wanted?

2005-11-28 Thread Anthony Towns
On Mon, Nov 28, 2005 at 12:09:33PM -0600, Peter Samuelson wrote:
 I still think two-byte prefixes for non-md5-non-sha1 hashes makes some
 sense, like s- for sha-256.  Avoids the filename encoding issue you
 mentioned later (unless we want to encode newlines).

The encoding issues are only for doing base64 (or similar compression)
or filename encoding, so you can't avoid them :)

  OTOH, it would be far more convenient for *us* if it supported the
  .changes style we use, ie:
MD5Sum:
  hash size filename
 This might be generally reasonable, 

Doesn't matter if it's generally reasonable, it's needed by *us*. That's
the format we use in .changes, in .dscs and Sources, and in Release.
It's silly to have a useful format, then not have tools that
conveniently check it, particularly if we're writing our own.

$ dsum -a sha1 foo; sha1sum foo
f572d396fae9206628714fb2ce00f72e94f2258f  foo
f572d396fae9206628714fb2ce00f72e94f2258f  foo
  
$ dsum -d foo
SHA1Sum:
 f572d396fae9206628714fb2ce00f72e94f2258f 6 foo
  
$ dsum -b foo
SHA1 (foo) = f572d396fae9206628714fb2ce00f72e94f2258f
 What's the  6  above?  

wc -c foo. foo was hello\n for reference. (And it probably should've
been SHA1: not SHA1Sum: too)

  (Note that dsum would probably need to become Priority:required,
  and possibly Essential:yes, with the complications that entails)
 Hmmm, promoting libgcrypt11 + libgpg-error0 to Required adds 516 kB on
 i386, plus a trivial amount for dsum itself.  I wonder if it'd be
 better to just copy / paste the algorithm code into dsum.

libssl0.9.8 is 860kB of .deb, 2MB installed. It's possible that libssl
would be too much of a nuisance wrt transitions to use, at least
dynamically.

Cheers,
aj



signature.asc
Description: Digital signature


Re: dpkg-sig support wanted?

2005-11-27 Thread Marc Haber
On Sat, 26 Nov 2005 14:14:38 +0100, Henning Makholm
[EMAIL PROTECTED] wrote:
Scripsit Florian Weimer [EMAIL PROTECTED]
 I wouldn't use real base64, though, because it would mean that you can
 use its hashed output as a file name.

Good point. One might replace / with _ and omit the final =.
Having a + in the hash should be safe in most contexts.

Isn't base62, which for example exim uses to create its message-ids, a
standard? I have never seen it outside exim.

Greetins
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber |Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom  | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834



Re: dpkg-sig support wanted?

2005-11-27 Thread Steinar H. Gunderson
On Sun, Nov 27, 2005 at 02:18:00PM +1000, Anthony Towns wrote:
 My understanding was that there aren't other hash functions that've had
 remotely similar levels of cryptographic analysis to md5 and sha. IIRC,
 the elliptic curve cryptography stuff was supposed to be similarly neat,
 until people started analysing it seriously, at which point it broke.

To the best of my knowledge, elliptic curve cryptography isn't any more
broken than RSA or ElGamal is.

/* Steinar */
-- 
Homepage: http://www.sesse.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: dpkg-sig support wanted?

2005-11-27 Thread Moritz Muehlenhoff
In linux.debian.devel, you wrote:
 Worse, the existance of a practical md5(A+B+C)=3Dmd5(A+D+C) attack means
 that it's not out of the question that there're md5(A+B)=3Dmd5(C+D)
 attacks in the hands of particularly well resourced groups (which is
 worse, since the version uploaded to the archive could then be entirely
 innocent looking). Personally, I don't have any interest in making the
 NSA's job any easier, or that of other signals intelligence groups.

While this is arguably true (the NSA claims to have developed asymmetric
cryptography ten years ahead of Diffie/Hellman), it seems that nowadays
the end of the cold war and improved corporate interest have shifted
things, so I'm personally not _too_ worried about that.

  Moving away from MD5 is certainly not a bad idea, but it's not clear
  whether the alternatives are any better.  Sure, everyone recommends
  SHA-256 at this stage, but nobody can give a rationale.
  MD5 is broken; SHA-1 is where MD5 was a couple of years ago, SHA256 (or
  higher) are significantly harder to break in practice,
 So?  If SHA256 is so much better, why is that nobody can prove it, or
 at least can provide some evidence which supports that claim?  The
 numbers are bigger is the main argument at this point, which is
 awfully similar to the usual snake-oil arguments (although there is a
 slight difference, of course).

 SHA256 is better than SHA1 in the same way 2048 bit RSA keys are better
 than 512 bit RSA keys. MD5 is broken, and isn't extensible. SHA1 is
 fragile, but not broken, and is extensible. Do you have other
 suggestions?

I'd suggest the combination of several hash systems, e.g. RIPEMD-160, a
SHA-based algorithm and possibly Tiger.

  and there's nothing better yet.
 In terms of security, there are some better hash functions. =20

 My understanding was that there aren't other hash functions that've had
 remotely similar levels of cryptographic analysis to md5 and sha. IIRC,
 the elliptic curve cryptography stuff was supposed to be similarly neat,
 until people started analysing it seriously, at which point it broke.

I'm not aware of any attacks beyond birthday attacks, which are still
infeasible for the recommended key sizes of = 160 bits.

ECC has several patent problems, though.

Cheers,
Moritz


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: dpkg-sig support wanted?

2005-11-27 Thread Anthony Towns
On Sun, Nov 27, 2005 at 12:42:42PM +0100, Steinar H. Gunderson wrote:
 On Sun, Nov 27, 2005 at 02:18:00PM +1000, Anthony Towns wrote:
  My understanding was that there aren't other hash functions that've had
  remotely similar levels of cryptographic analysis to md5 and sha. IIRC,
  the elliptic curve cryptography stuff was supposed to be similarly neat,
  until people started analysing it seriously, at which point it broke.
 To the best of my knowledge, elliptic curve cryptography isn't any more
 broken than RSA or ElGamal is.

Oh god, how embarassing. I'm confusing elliptic curves and knapsacks,
my bad. Knapsack cryptograph's provably secure (in that a general
solution is NP), and practically insecure (in that it's hard to find
instances that are reliably hard enough, at least without obscene key
sizes).

But hey, SHA-something, Tiger, or whatever; it's well past time to choose
one, get a /usr/bin/... binary we can use, and replace md5 with it.

Cheers,
aj


signature.asc
Description: Digital signature


Re: dpkg-sig support wanted?

2005-11-27 Thread Lionel Elie Mamane
On Sun, Nov 27, 2005 at 12:42:42PM +0100, Steinar H. Gunderson wrote:
 On Sun, Nov 27, 2005 at 02:18:00PM +1000, Anthony Towns wrote:

 My understanding was that there aren't other hash functions that've
 had remotely similar levels of cryptographic analysis to md5 and
 sha. IIRC, the elliptic curve cryptography stuff was supposed to be
 similarly neat, until people started analysing it seriously, at
 which point it broke.

 To the best of my knowledge, elliptic curve cryptography isn't any
 more broken than RSA or ElGamal is.

It isn't really broken, but the recommended key sizes have grown
significantly. I mean, the factor to divide RSA/DH/ElGamal key sizes
by to get equivalent security in ECC has shrunk. At least, I've heard
so, I don't remember what keys sizes were advertised in the beginnings
of ECC.

-- 
Lionel


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: dpkg-sig support wanted?

2005-11-27 Thread Lionel Elie Mamane
On Mon, Nov 28, 2005 at 03:32:21PM +1000, Anthony Towns wrote:

 Knapsack cryptograph's provably secure (in that a general solution
 is NP),

You mean NP-_complete_. (Sorting is also NP, but not NP-complete. NP
is can be done in polynomial time by a non-deterministic Turing
machine, so anything polynomial by a normal machine is also
NP. Foo is NP-complete is any NP problem can be polynomially
reduced to foo, or in other words, if there is a normal machine that
does foo in polynomial time, all NP problems can be done in polynomial
time.)

-- 
Lionel


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: dpkg-sig support wanted?

2005-11-27 Thread Lionel Elie Mamane
On Sat, Nov 26, 2005 at 10:59:57AM +0100, Florian Weimer wrote:
 * Anthony Towns:
 On Fri, Nov 25, 2005 at 07:59:40PM +0100, Florian Weimer wrote:
 * Anthony Towns:

 Moving away from MD5 is certainly not a bad idea, but it's not
 clear whether the alternatives are any better.  Sure, everyone
 recommends SHA-256 at this stage, but nobody can give a rationale.

 MD5 is broken; SHA-1 is where MD5 was a couple of years ago, SHA256
 (or higher) are significantly harder to break in practice,

 So?  If SHA256 is so much better, why is that nobody can prove it,
 or at least can provide some evidence which supports that claim?

The idea behind using SHA256 (or SHA512) is that we have more
_margin_. If we are targeting MD5's design security (2^64 against
collisions), even if SHA512 is broken significantly - say an attack
four times better than birthday - we still have our expected strength.

It is also the best we can get to *right* *now*, unless we escape to
humongous hash sizes (arithmetic-based designs).

 and there's nothing better yet.

 In terms of security, there are some better hash functions.  But
 those are academic designs, most of them based on big integer
 arithmetic instead of bit fiddling.  Currently, nobody seems to be
 willing to pay the price that comes with them.

What this means is that your hashes will be as big as your asymmetric
keys, and hashing as slow as asymmetric cryptography. That's
significant.

They also seem to have deeply different security properties as far as
the user is concerned: the one I know, at least
(http://diswww.mit.edu/bloom-picayune/crypto/13190) relies (as
asymmetric crypto) on n a hard to factor product of two primes p and
q. The security proof under assumption that factoring is hard is
that if you generate a collision, you have factored n (roughly).

Now, what I don't get is who generates n and thus knows p and q and
thus _can_ generate collisions? Does everyone use his own n (and thus
everyone can generate collisions for the hash _he_ uses, but not for
the hash others use), do we use a trusted third party (that's a
_significantly_ different security model!) that publishes n?

(When I write n above, I obviously mean the pair (n,g), g element of
maximal order in Z/nZ.)

-- 
Lionel


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: dpkg-sig support wanted?

2005-11-26 Thread George Danchev
On Saturday 26 November 2005 01:13, Anthony Towns wrote:
 On Fri, Nov 25, 2005 at 07:59:40PM +0100, Florian Weimer wrote:
  * Anthony Towns:
   (I'm amazed the security crisis we're having is about deb sigs
   *again*, when we're still relying on md5sum which has a public exploit
   available now...)
 
  These exploits are irrelevant as far as the Debian archive is
  concerned.  (And that's not because hardly any sarge user verifies the
  MD5 hashes, by the way. 8-)

 Uh. You're seriously putting your reputation on that claim?

 And md5 hashes have been verified since either slink or potato depending
 on when you started using apt; possibly earlier if dselect methods used
 them like they should have. debootstrap certainly verified them for
 woody. And heck, they've been used in .changes since day 0.

  Moving away from MD5 is certainly not a bad idea, but it's not clear
  whether the alternatives are any better.  Sure, everyone recommends
  SHA-256 at this stage, but nobody can give a rationale.

 MD5 is broken; SHA-1 is where MD5 was a couple of years ago, SHA256 (or
 higher) are significantly harder to break in practice, and there's
 nothing better yet.

Even using weak hash sum algorythms you can easily make the hash collider life 
tremendously difficult by simply having more than one (ok two should be 
enough) hash sums generated with _different_ (weak?) algorythms on the same 
entity. Searching for parallel meaningful collisions is despairing job. For 
example the Release file stores two hash sums for the same entities.

-- 
pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: dpkg-sig support wanted?

2005-11-26 Thread Florian Weimer
* Anthony Towns:

 On Fri, Nov 25, 2005 at 07:59:40PM +0100, Florian Weimer wrote:
 * Anthony Towns:
  (I'm amazed the security crisis we're having is about deb sigs
  *again*, when we're still relying on md5sum which has a public exploit
  available now...)
 These exploits are irrelevant as far as the Debian archive is
 concerned.  (And that's not because hardly any sarge user verifies the
 MD5 hashes, by the way. 8-)

(I meant that the signature on a hash of those hashes is not
verified.)

 Uh. You're seriously putting your reputation on that claim?

Yes.  To attack the Debian archive, you need to carry out a preimage
attack.  Nothing in that direction has been published so far.

For the exploits we have seen so far to work, the malicious party
needs upload access to the archive and has to plant a specially
crafted package there, for which they have created an evil twin
package.  (Same for attacking one of the text files listing hashes.)
Looks a bit far-fatched to me.

 Moving away from MD5 is certainly not a bad idea, but it's not clear
 whether the alternatives are any better.  Sure, everyone recommends
 SHA-256 at this stage, but nobody can give a rationale.

 MD5 is broken; SHA-1 is where MD5 was a couple of years ago, SHA256 (or
 higher) are significantly harder to break in practice,

So?  If SHA256 is so much better, why is that nobody can prove it, or
at least can provide some evidence which supports that claim?  The
numbers are bigger is the main argument at this point, which is
awfully similar to the usual snake-oil arguments (although there is a
slight difference, of course).

On the other hand, the cost of adding another hash function is not
that high for Debian, compared to other deployments.  Adding SHA256
and RSHA a few months (hopefully, years) later doesn't really hurt
that much, I guess.

 and there's nothing better yet.

In terms of security, there are some better hash functions.  But those
are academic designs, most of them based on big integer arithmetic
instead of bit fiddling.  Currently, nobody seems to be willing to pay
the price that comes with them.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: dpkg-sig support wanted?

2005-11-26 Thread Florian Weimer
* Thiemo Seufer:

 A: Why do you lock your car up[1]?
 
 B: Because it looks like having it locked is better then not having it
 locked.
 
 A: Sorry, but that's a snake oil rationale. Anybody can pick the lock
 and break in. Anybody can smash a window and break in. etc.

 Wrong, it makes break-ins harder. OTOH we don't put stickers with
 this car is locked on our cars.

Uhm, we do.  There are those blinking LEDs which serve exactly that
purpose.  And yes, those electronic locks have been broken; the only
thing that protects them is that it's a crime to tell anyone how they
work.

At this stage, car locks (especially those of the electronic kind)
serve only to show intent.  You can't claim that you erroneously drove
away in someone else's car.  Besides that, they don't really help.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: dpkg-sig support wanted?

2005-11-26 Thread Marc Haber
On Fri, 25 Nov 2005 12:50:41 -0800, Thomas Bushnell BSG
[EMAIL PROTECTED] wrote:
Goswin von Brederlow [EMAIL PROTECTED] writes:
 The archive signing key gives absolutely no integrity ensurance on the
 deb package. The only thing it insures is that the file was not
 altered _after_ leaving ftp.de.debian.org for the mirrors and/or
 user. In no way does it prevent altering the deb on ftp-master.

Isn't that a useful assurance?  Perhaps I trust the maintenance of
ftp-master, but not the maintenance of Joe Random Mirror.

So the natural reaction would be having _both_ signatures so that the
individual user can choose whom to trust.

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber |Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom  | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834



Re: dpkg-sig support wanted?

2005-11-26 Thread Henning Makholm
Scripsit Peter Samuelson [EMAIL PROTECTED]

 You may laugh if you wish, but I think it's annoying to have to move to
 a hash function whose hexadecimal representation takes 64 bytes, which
 doesn't leave much room on an 80-column line to describe what the hash
 is hashing.  Maybe by the time coreutils ships a sha256sum program, the
 world will have settled upon BASE64, which requires only 43 bytes.

Why wait for the world to settle? Would there be anything wrong with
writing a sha256sum program that outputs base64 right now?

-- 
Henning Makholm Lad min høne være.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: dpkg-sig support wanted?

2005-11-26 Thread Florian Weimer
* Henning Makholm:

 Scripsit Peter Samuelson [EMAIL PROTECTED]

 You may laugh if you wish, but I think it's annoying to have to move to
 a hash function whose hexadecimal representation takes 64 bytes, which
 doesn't leave much room on an 80-column line to describe what the hash
 is hashing.  Maybe by the time coreutils ships a sha256sum program, the
 world will have settled upon BASE64, which requires only 43 bytes.

 Why wait for the world to settle? Would there be anything wrong with
 writing a sha256sum program that outputs base64 right now?

I wouldn't use real base64, though, because it would mean that you can
use its hashed output as a file name.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: dpkg-sig support wanted?

2005-11-26 Thread Steinar H. Gunderson
On Sat, Nov 26, 2005 at 10:59:57AM +0100, Florian Weimer wrote:
 So?  If SHA256 is so much better, why is that nobody can prove it, or
 at least can provide some evidence which supports that claim?  The
 numbers are bigger is the main argument at this point, which is
 awfully similar to the usual snake-oil arguments (although there is a
 slight difference, of course).

In the world of cryptography, _proving_ security is rather difficult. All you
can say is well, nobody have made any real progress towards this yet, and
then estimate approximately how much work has actually been done with regard
to breaking it.

 In terms of security, there are some better hash functions.  But those
 are academic designs, most of them based on big integer arithmetic
 instead of bit fiddling.  Currently, nobody seems to be willing to pay
 the price that comes with them.

Well, the number theory-based hashes are interesting, but they haven't been
around for a very long time (and aren't widely used yet), so nobody really
knows how well they will fare in the long run. The other part of the price is
of course speed.

/* Steinar */
-- 
Homepage: http://www.sesse.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: dpkg-sig support wanted?

2005-11-26 Thread Florian Weimer
* Steinar H. Gunderson:

 On Sat, Nov 26, 2005 at 10:59:57AM +0100, Florian Weimer wrote:
 So?  If SHA256 is so much better, why is that nobody can prove it, or
 at least can provide some evidence which supports that claim?  The
 numbers are bigger is the main argument at this point, which is
 awfully similar to the usual snake-oil arguments (although there is a
 slight difference, of course).

 In the world of cryptography, _proving_ security is rather difficult.

That's why I wrote some evidence.  Things like nobody managed so
far to extend attacks A, B, C beyond k rounds are pretty weak.

 All you can say is well, nobody have made any real progress towards
 this yet, and then estimate approximately how much work has
 actually been done with regard to breaking it.

There are cryptosystems where attacks (in some well-defined sense, of
course) are provably equivalent to some other problem which is
believed to be hard (factoring, RSA).

However, there are also cryptosystems which were shown to have such
properties, but where the proof was wrong.  General OAEP was such a
case, IIRC.

 In terms of security, there are some better hash functions.  But those
 are academic designs, most of them based on big integer arithmetic
 instead of bit fiddling.  Currently, nobody seems to be willing to pay
 the price that comes with them.

 Well, the number theory-based hashes are interesting, but they
 haven't been around for a very long time (and aren't widely used
 yet), so nobody really knows how well they will fare in the long
 run.

Some of these systems have provable security properties, which might
increase confidence despite their lack of age.

 The other part of the price is of course speed.

Yes, this is the primary problem, it seems.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: dpkg-sig support wanted?

2005-11-26 Thread Henning Makholm
Scripsit Florian Weimer [EMAIL PROTECTED]
 * Henning Makholm:

 Why wait for the world to settle? Would there be anything wrong with
 writing a sha256sum program that outputs base64 right now?

 I wouldn't use real base64, though, because it would mean that you can
 use its hashed output as a file name.

Good point. One might replace / with _ and omit the final =.
Having a + in the hash should be safe in most contexts.

-- 
Henning Makholm   We will discuss your youth another time.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: dpkg-sig support wanted?

2005-11-26 Thread Florian Weimer
* Henning Makholm:

 I wouldn't use real base64, though, because it would mean that you can
 use its hashed output as a file name.

 Good point. One might replace / with _ and omit the final =.
 Having a + in the hash should be safe in most contexts.

It should be replaced with -.  Beyond alphanumerics, only ., _,
- are in the POSIX portable filename character set[1], and some
systems do not allow the character + in file names.

[1] 
http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap03.html#tag_03_276


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: dpkg-sig support wanted?

2005-11-26 Thread Florian Weimer
* Adeodato Simó:

 * Florian Weimer [Thu, 24 Nov 2005 18:28:04 +0100]:

 Hi,

 AFAIK, binary NMus aren't announced on debian-devel-changes.

   Binary-only uploads are announced in the appropriate
   debian-devel-$ARCH-changes list.

According to

http://murphy.debian.org/lists/debian-devel-i386-changes/details.html

these lists are dead.  Or am I missing something?



Re: dpkg-sig support wanted?

2005-11-26 Thread Henning Makholm
Scripsit Florian Weimer [EMAIL PROTECTED]
 * Henning Makholm:

 I wouldn't use real base64, though, because it would mean that you can
 use its hashed output as a file name.

 Good point. One might replace / with _ and omit the final =.
 Having a + in the hash should be safe in most contexts.

 It should be replaced with -.  Beyond alphanumerics, only ., _,
 - are in the POSIX portable filename character set[1], and some
 systems do not allow the character + in file names.

However there are already plenty of files with + in their names
involved in Debian (e.g. /usr/lib/libstdc++.so.6).

Having every 64th hash-based filename start with - or . would lead
to failure modes for shell scripts (mistaking the filename for a
command line option, resp. missing it in globs) that are just
infrequent enough that they might not be observed before a
quick-and-dirty script is deployed.

I think the conclusion is that no simple substitution is at the same
time Posix friendly and friendly towards quick-and-dirty scripting.

(Yes: substitute /+ with _-, and then move the last character of the
base64 encoding to the front. Due to zero padding it must come from
the set [AEIMQUYcgkosw048].)

-- 
Henning Makholm You want to know where my brain is,
spetsnaz girl? Do you? Look behind you.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: dpkg-sig support wanted?

2005-11-26 Thread Peter Samuelson

[George Danchev]
 Even using weak hash sum algorythms you can easily make the hash
 collider life tremendously difficult by simply having more than one
 (ok two should be enough) hash sums generated with _different_
 (weak?) algorythms on the same entity.

What you have just defined is a new hash algorithm of M+N bits.  Why
not instead use an existing hash algorithm with M+N bits?  If nothing
else, the attack is likely to be less parallelizable.


signature.asc
Description: Digital signature


Re: dpkg-sig support wanted?

2005-11-26 Thread Anthony Towns
On Fri, Nov 25, 2005 at 11:08:32PM -0600, Peter Samuelson wrote:
 You may laugh if you wish, but I think it's annoying to have to move to
 a hash function whose hexadecimal representation takes 64 bytes, which
 doesn't leave much room on an 80-column line to describe what the hash
 is hashing.  Maybe by the time coreutils ships a sha256sum program, the
 world will have settled upon BASE64, which requires only 43 bytes.

Why should we wait for the rest of the world to settle on a standard?

Cheers,
aj


signature.asc
Description: Digital signature


Re: dpkg-sig support wanted?

2005-11-26 Thread Anthony Towns
On Sat, Nov 26, 2005 at 10:59:57AM +0100, Florian Weimer wrote:
 For the exploits we have seen so far to work, the malicious party
 needs upload access to the archive and has to plant a specially
 crafted package there, for which they have created an evil twin
 package.  (Same for attacking one of the text files listing hashes.)
 Looks a bit far-fatched to me.

Not really. Joining Debian isn't particularly difficult, and it might
not even be out of the question to find someone who'll sponsor an upload
without rebuilding the .deb. I think it's safe to imagine that there are
developers right now who've done some shady things in the past; is it
that far fetched to imagine it's worth protecting against developers
who try to abuse their priveleges?

The way we do that has to be mostly after the fact, of course: someone
uploads a bad package, people find out it's bad, we trace it back to
whoever uploaded it, then we kick them out of the project.

But that only works if the bad package is actually discovered. If the
.deb's distributed across hundreds of mirrors and to thousands of users,
it's reasonably likely that it will be discovered; but if it's possible
to target the attack against an individual user, and leave the rest of
the Debian universe untouched, you've got a much better chance of
not getting caught. Hence: distribute an iced .deb in the archive, that
does no harm ever and thus needn't arouse any suspicion; and sneak a
fire .deb that has the exploit activated onto the mirror of your target.

Looks a bit far-fetched comes under the famous last words heading
for security analysis.

Worse, the existance of a practical md5(A+B+C)=md5(A+D+C) attack means
that it's not out of the question that there're md5(A+B)=md5(C+D)
attacks in the hands of particularly well resourced groups (which is
worse, since the version uploaded to the archive could then be entirely
innocent looking). Personally, I don't have any interest in making the
NSA's job any easier, or that of other signals intelligence groups.

  Moving away from MD5 is certainly not a bad idea, but it's not clear
  whether the alternatives are any better.  Sure, everyone recommends
  SHA-256 at this stage, but nobody can give a rationale.
  MD5 is broken; SHA-1 is where MD5 was a couple of years ago, SHA256 (or
  higher) are significantly harder to break in practice,
 So?  If SHA256 is so much better, why is that nobody can prove it, or
 at least can provide some evidence which supports that claim?  The
 numbers are bigger is the main argument at this point, which is
 awfully similar to the usual snake-oil arguments (although there is a
 slight difference, of course).

SHA256 is better than SHA1 in the same way 2048 bit RSA keys are better
than 512 bit RSA keys. MD5 is broken, and isn't extensible. SHA1 is
fragile, but not broken, and is extensible. Do you have other
suggestions?

  and there's nothing better yet.
 In terms of security, there are some better hash functions.  

My understanding was that there aren't other hash functions that've had
remotely similar levels of cryptographic analysis to md5 and sha. IIRC,
the elliptic curve cryptography stuff was supposed to be similarly neat,
until people started analysing it seriously, at which point it broke.

Cheers,
aj


signature.asc
Description: Digital signature


Re: dpkg-sig support wanted?

2005-11-26 Thread Peter Samuelson

  [Florian Weimer]
  It should be replaced with -.  Beyond alphanumerics, only .,
  _, - are in the POSIX portable filename character set[1], and
  some systems do not allow the character + in file names.

[Henning Makholm]
 However there are already plenty of files with + in their names
 involved in Debian (e.g. /usr/lib/libstdc++.so.6).

Well, if we're trying to drive a standard representation, there will be
people outside Debian who will care about POSIX filename characters.

 Having every 64th hash-based filename start with - or . would
 lead to failure modes for shell scripts

True.

 (Yes: substitute /+ with _-, and then move the last character of the
 base64 encoding to the front. Due to zero padding it must come from
 the set [AEIMQUYcgkosw048].)

Or: substitute /+ with _- and then add a short prefix like s- to
denote the hash type, in case other 256-bit hashes become popular.  I
guess we didn't really have that problem with 128-bit and 160-bit
checksums, but we could've.

  sha256sum () {
local f;
if [ $# = 0 ]; then
  openssl dgst -sha256 -binary | base64-encode |
  sed 'y|/+|_-|;  s|^|s-|;  s|=|\t-|'
else for f; do
  echo s-$(openssl dgst -sha256 -binary $f | base64-encode |
sed 'y|/+|_-|;  s|=|\t|')$f
done; fi
  }

(Implementation of -c left as an exercise, etc.)


signature.asc
Description: Digital signature


Re: dpkg-sig support wanted?

2005-11-25 Thread Steve Langasek
On Thu, Nov 24, 2005 at 07:17:06PM +0100, Goswin von Brederlow wrote:

  That's easy: you trust the Packages file to be correct when using apt,
  and it's not verified at all by per-package signatures.

 In what way trust and how does that change anything?

 At best you can prevent a newer version of a package to appear in the
 Packages file by compromising it. You can't subvert a package itself.
 But you can already ship yesterdays Release.gpg, Release and Packages
 file to a user and thereby prevent any updates.

 On the other hand, without package signatures ftp-master adds a
 vulnerability. You can hack into it, replace debs, recreate the
 Packages, Release and Release.gpg file and thereby infect users. With
 signed debs that could still be detected by every user in apt-get.

Only if every user is in a position to verify signatures from each Debian
developer individually, which is completely unrealistic.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature


Re: dpkg-sig support wanted?

2005-11-25 Thread Hamish Moffatt
On Wed, Nov 23, 2005 at 05:34:41PM +0100, Jeroen van Wolffelaar wrote:
 In the archive, 525 out of 283283 .deb's are dpkg-sig'd (0.19%). There
 are 8 distinct keys used for those 525 .deb's, seven of which correspond
 to DD's[1].

Slightly off the topic, but does this mean the archive contains .debs
not build by Debian developers? Shouldn't sponsors be recompiling
packages from non-DDs before upload?


Hamish
-- 
Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: dpkg-sig support wanted?

2005-11-25 Thread Adeodato Simó
* Hamish Moffatt [Fri, 25 Nov 2005 20:34:02 +1100]:

 On Wed, Nov 23, 2005 at 05:34:41PM +0100, Jeroen van Wolffelaar wrote:
  In the archive, 525 out of 283283 .deb's are dpkg-sig'd (0.19%). There
  are 8 distinct keys used for those 525 .deb's, seven of which correspond
  to DD's[1].

 Slightly off the topic, but does this mean the archive contains .debs
 not build by Debian developers? Shouldn't sponsors be recompiling
 packages from non-DDs before upload?

  I was suspicious too, but it was later checked on irc that all keys
  actually belonged to a DD. (One of them was not in public keyservers,
  AIUI, and Jeroen assumed it was not a DD, or something similar.)

  Cheers,

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
A lie can go round the world before the truth has got its boots on.
-- Terry Pratchett


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: dpkg-sig support wanted?

2005-11-25 Thread Simon Richter

Hi,

Anthony Towns wrote:


The problem is that using gzip and ar is complicated, which adds
possibilities for errors. You might find yourself not putting the deb
together again and getting false signature mismatches, or worse, you
might find yourself only verifying part of the .deb, and having dpkg
actually use parts of the .deb that haven't been authenticated under the
false conviction that you're actually safe. With md5sum foo.deb you
know you've authenticated everything.


Which is also a disadvantage in some cases. I could see a case for 
extending .deb files (say, with additional translations for the 
description and templates, thus removing the need for the maintainer to 
reupload new packages when new translations are ready).


I think that it should be fairly easy to implement something that can 
verify parts of .deb files and check whether the authenticated parts 
together form a complete and consistent package on their own.


This thread, however, is not about a technical problem, so I would 
propose a sauna meeting.



IF this means we can switch the effort to a detached signature that is more
powerful than a .changes file (or we are allowed to have multiple signatures
in a .changes file), 


That is already possible with gnupg, just not well-documented; I'm not 
entirely sure what interesting breakage would occur if one were to 
upload a changes file with multiple signatures.



and also that the .changes file will be stored in the
archives along with the .debs, 



As it turns out, that's probably not feasible per se -- it likely implies
too much inode usage, and slack space.


And is probably pointless. If you don't trust the Debian infrastructure, 
you are free to get the source (which is signed by the maintainer) and 
build the package yourself.



where dpkg would simply refuse
per user-set policy any non-signed deb or any deb without a specific
signature...



I'm sorry, but you're back to the snakeoil use for deb sigs. Expecting
a signature by a random Debian developer to mean something is not
reasonable.


That's why there can be multiple signatures. There would be one from the 
maintainer/buildd, a few from the Debian archive (for example, you could 
add one sig for officially in Debian unstable, one for migrated to 
testing and one for in a stable release) and if the idea of adding 
description/template translations later on catches on, also some from 
the translators/translation system.


   Simon


signature.asc
Description: OpenPGP digital signature


Re: dpkg-sig support wanted?

2005-11-25 Thread Goswin von Brederlow
Anthony Towns aj@azure.humbug.org.au writes:

 On Thu, Nov 24, 2005 at 06:28:04PM +0100, Florian Weimer wrote:
 If you just want to check hashes, you should just use changes files. If
 you _actually_ want to check hashes, and this isn't just a thought
 experiment, working out a usable way to deliver .changes for whatever
 purpose you've got in mind would be a good idea. (Again though, I don't
 see a point to them, beyond reverification of the archive in the event
 of an exploit. Of course, maybe that's what you want to do...)

We have a perfectly useable and trivial way to deliver the hashes,
which is the intresting part of the changes file for security. It is
the signature in the deb.


For comparison: Why do we have a signature in dsc files? From your
arguments that signature is completly useless since changes files
already provide all that is needed.

We still sign dsc files because it is just that much easier to apt-get
source foo and verify it. And that is a good thing. Why are you so set
in stone against allowing the same for debs?

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: dpkg-sig support wanted?

2005-11-25 Thread Goswin von Brederlow
Steve Langasek [EMAIL PROTECTED] writes:

 On Thu, Nov 24, 2005 at 07:17:06PM +0100, Goswin von Brederlow wrote:

  That's easy: you trust the Packages file to be correct when using apt,
  and it's not verified at all by per-package signatures.

 In what way trust and how does that change anything?

 At best you can prevent a newer version of a package to appear in the
 Packages file by compromising it. You can't subvert a package itself.
 But you can already ship yesterdays Release.gpg, Release and Packages
 file to a user and thereby prevent any updates.

 On the other hand, without package signatures ftp-master adds a
 vulnerability. You can hack into it, replace debs, recreate the
 Packages, Release and Release.gpg file and thereby infect users. With
 signed debs that could still be detected by every user in apt-get.

 Only if every user is in a position to verify signatures from each Debian
 developer individually, which is completely unrealistic.

Up to a point you can trust the keyring. As much as you can trust any
DD signature. You try to argue that signatures are not absolutely
trustworthy but that is nothing new. Nothing you can do will change
that. What you fail to see (or say) is that all the security Debian
already has is weak in exactly the same way. The difference to signed
debs is the transparency and triviality to check. Even if that check
has to use a 5 hop trust path to some DD you never met.

Also for !i386 !ppc basicaly all packages are autobuild and will be
signed by a handfull of people. You can go and meet them easily
enough.

Further, with signed debs, you could only allow installation of debs
from people you trust and recompile all the rest after a source
audit. If you are that paranoid.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: dpkg-sig support wanted?

2005-11-25 Thread Goswin von Brederlow
Anthony Towns aj@azure.humbug.org.au writes:

 On Thu, Nov 24, 2005 at 07:47:58PM +0100, Goswin von Brederlow wrote:
 Anthony Towns aj@azure.humbug.org.au writes:
  On Wed, Nov 23, 2005 at 09:18:40PM +0100, Goswin von Brederlow wrote:
  Use 1: I have this deb in my apt-move mirror and I want to know if it
 was compromised on yesterdays breakin
Boot a clean system with debian keyring and check all deb
signatures.
  Find some don't pass because they were signed with keys that have been
  removed from the keyring.
 Those I remove and refetch from a clean source again. False negatives
 are no big deal. 99% of the debs will verify leaving only a
 managable amount of wokr behind.

 The clean source that's signed by the same key that you can't verify?

If I can't find any verifiable source then the package can't be
trusted and can be removed till that is changed. Still much better
than having 100% untrustworthy packages.

 Ah, I see the light.
 Signatures are useless because packages have no signatures.

 That's a transitional problem, yes. In this case it's a severe one;
 since there are up to 150GBs worth of .debs. It's a problem that could be
 solved if it were worthwhile, but it's not worthwhile since .changes
 already do everything deb sigs could do without any transition issues,
 and it's not something that can be simply ignored.

 Cheers,
 aj

By the way, this is trivial to work around:
1) archive the Release.gpg, Release and Packages file from today
2) only allow signed debs from now on
From then on all debs can be verified.


I say the transition can be simply ignored (for now). The problem will
fix itself in due time when signed debs become more popular and
debsign automatically adds them. At some point in the future the
majority of debs will be signed and then a transition can be force by
scheduling a binNMU for any remaining deb.

But first there must be an official debs may be signed before anyone
can think about a debs MUST be signed.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: dpkg-sig support wanted?

2005-11-25 Thread Goswin von Brederlow
Henrique de Moraes Holschuh [EMAIL PROTECTED] writes:

 On Thu, 24 Nov 2005, Anthony Towns wrote:
 On Thu, Nov 24, 2005 at 07:39:57AM +0100, Marc Haber wrote:
  Uh, packages not uploaded to the official Debian archive can do whatever
  they want.
  It would, however, be convenient to be able to upload a package to
  Debian and to be able to use the same package for different things.
 
 As far as dpkg-sign's concerned, can't you already do that by building
 the package, uploading it to debian, then running dpkg-sign? At worst
 you'd have to run dpkg-genchanges again before uploading to your other
 suite, afaics.

 You're correct.

And he is also wrong.

That would result in debs with the same name and version but different
md5sums. Something that easily confuses apt-get and people.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: dpkg-sig support wanted?

2005-11-25 Thread Goswin von Brederlow
Simon Richter [EMAIL PROTECTED] writes:

IF this means we can switch the effort to a detached signature that is more
powerful than a .changes file (or we are allowed to have multiple signatures
 in a .changes file),

 That is already possible with gnupg, just not well-documented; I'm not
 entirely sure what interesting breakage would occur if one were to
 upload a changes file with multiple signatures.

It gives a parse error and the DAK rejects the file.

where dpkg would simply refuse
per user-set policy any non-signed deb or any deb without a specific
signature...

 I'm sorry, but you're back to the snakeoil use for deb sigs. Expecting
 a signature by a random Debian developer to mean something is not
 reasonable.

A signature in the deb by a random developer is as trustworthy as the
changes file and you already trust that. So we are going from snakeoil
to snakoil. No harm done.

 That's why there can be multiple signatures. There would be one from
 the maintainer/buildd, a few from the Debian archive (for example, you
 could add one sig for officially in Debian unstable, one for
 migrated to testing and one for in a stable release) and if the
 idea of adding description/template translations later on catches on,
 also some from the translators/translation system.

Although that would alter the packages md5sum and even alter a package
while still being in a distribution (the unstable deb would suddenly
gain a signature). It would be a big change to allow this.

 Simon


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: dpkg-sig support wanted?

2005-11-25 Thread Matthew Palmer
On Fri, Nov 25, 2005 at 03:22:37PM +0100, Goswin von Brederlow wrote:
 A signature in the deb by a random developer is as trustworthy as the
 changes file and you already trust that. So we are going from snakeoil
 to snakoil. No harm done.

It's not the same, actually.  A signature in a .deb needs to be made by a
key which is still trustworthy at the time of verification, which could be
quite some time in the future.  The key which makes a .changes signature, in
contrast, only *needs* to be valid at the time the upload is made -- if it
is later compromised, it's not important, because by that time the archive
signing key hsa taken over the role of integrity verification.

Of course, using the signature on the .changes to verify the .debs
independent from the archive at some later date is a nice side-benefit, but
one which suffers from the same key-lifetime issues as in-deb signatures,
and since the .changes from autobuilt uploads aren't publically available
(apparently d-d-$arch-changes isn't archived, from info previously posted in
this thread) that method of package authentication isn't going to be 100%
reliable anyway.

- Matt


signature.asc
Description: Digital signature


Re: dpkg-sig support wanted?

2005-11-25 Thread Olaf van der Spek
On 11/25/05, Matthew Palmer [EMAIL PROTECTED] wrote:
 Of course, using the signature on the .changes to verify the .debs
 independent from the archive at some later date is a nice side-benefit, but
 one which suffers from the same key-lifetime issues as in-deb signatures,

What exactly is this key lifetime issue?
Is it a cryptographic issue?

 and since the .changes from autobuilt uploads aren't publically available
 (apparently d-d-$arch-changes isn't archived, from info previously posted in
 this thread) that method of package authentication isn't going to be 100%
 reliable anyway.


Re: dpkg-sig support wanted?

2005-11-25 Thread Goswin von Brederlow
Matthew Palmer [EMAIL PROTECTED] writes:

 On Fri, Nov 25, 2005 at 03:22:37PM +0100, Goswin von Brederlow wrote:
 A signature in the deb by a random developer is as trustworthy as the
 changes file and you already trust that. So we are going from snakeoil
 to snakoil. No harm done.

 It's not the same, actually.  A signature in a .deb needs to be made by a
 key which is still trustworthy at the time of verification, which could be
 quite some time in the future.  The key which makes a .changes signature, in
 contrast, only *needs* to be valid at the time the upload is made -- if it
 is later compromised, it's not important, because by that time the archive
 signing key hsa taken over the role of integrity verification.

And there you have the big misconception.

The archive signing key gives absolutely no integrity ensurance on the
deb package. The only thing it insures is that the file was not
altered _after_ leaving ftp.de.debian.org for the mirrors and/or
user. In no way does it prevent altering the deb on ftp-master.

The chain of trust from the DD to the enduser is broken at that point
when the chnages file disapears into a non public place and the
Release.gpg takes over. Even worse the Release.gpg is signed with an
automatic key which I trust way less than a DDs key.

 Of course, using the signature on the .changes to verify the .debs
 independent from the archive at some later date is a nice side-benefit, but
 one which suffers from the same key-lifetime issues as in-deb signatures,
 and since the .changes from autobuilt uploads aren't publically available
 (apparently d-d-$arch-changes isn't archived, from info previously posted in
 this thread) that method of package authentication isn't going to be 100%
 reliable anyway.

 - Matt

The key-lifetime issue, as you say, is already there for the changes
files. It also already there for the dsc files. The deb signatures
don't change a thing there.

What they change is the availability of the signature. And that they
change to 100% for every signed deb (and we hope all debs gets igned
at some point).

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: dpkg-sig support wanted?

2005-11-25 Thread Goswin von Brederlow
Olaf van der Spek [EMAIL PROTECTED] writes:

 On 11/25/05, Matthew Palmer [EMAIL PROTECTED] wrote:
 Of course, using the signature on the .changes to verify the .debs
 independent from the archive at some later date is a nice side-benefit, but
 one which suffers from the same key-lifetime issues as in-deb signatures,

 What exactly is this key lifetime issue?
 Is it a cryptographic issue?

A key can expire, get stolen / lost or get compromised and
revoced. Once that happens you can't trust any signature made by that
key.

Although one can probably argue that an expired key still has enough
trust to verify old debs. Many people don't set an expiry date anyway.


While this sounds like a big problem lets have some numbers:

Shortly before the sarge release we imported all source packages into
the debian-amd64 DAK and actualy did have the problem with dsc file
signatures. But that was a problem of maybe 20 packages (out of
over 8000).

Overall a miniscule problem. If I can verify all but 20 packages that
realy is a great bonus.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: dpkg-sig support wanted?

2005-11-25 Thread Henrique de Moraes Holschuh
On Fri, 25 Nov 2005, Anthony Towns wrote:
 (I'm amazed the security crisis we're having is about deb sigs
 *again*, when we're still relying on md5sum which has a public exploit
 available now...)

Do you really want a thread about how we should switch everything to SHA-512
or something like that?

 Huh? Why do you want multiple signatures of a .changes file?

If I am to do with a .changes file everything I can do with the in-deb
signatures, it needs to support at least nested signatures.

  and also that the .changes file will be stored in the
  archives along with the .debs, 
 
 As it turns out, that's probably not feasible per se -- it likely implies
 too much inode usage, and slack space.

That speaks for in-deb signatures in the usability department.

  and that .debs with wrong/incomplete/missing
  Source: fields will be rejected (such as all automated bin-NMUed .debs made
  until about a week ago, or any made by a maintainer right now),
 
 Huh? I don't think #62529 is fixed yet. If you think you'll have better
 luck at doing so, be my guest. That's not a prerequisite for verifying
 packages from changes files though.

Well, the email about the new bin-NMU structure implied that it was fixed
for *NMUs done through that structure*.  I very much doubt we can produce
bin NMUs in our systems with the proper Source header without taking very
special steps.

   My objection is that it's *useless* for *Debian*. Debian has too many
   sources for packages for key management to be plausible, and keeps
  This applies to .changes files too, with the aggravating addition that those
  are a bitch to find right now.
 
 Uh, no, .changes files are not remotely useless for Debian right now.
 Where would you get that idea?

I was refering to Debian has too many sources for packages for key
management to be plausible.  Duh, obviously .change files are useful for
Debian, DAK needs them.

 The tools are the least concern; what's a few dozen lines of code here
 and there matter? If you insist every package only be uploaded once, and
 do the maximum packages per day, and stop all other development just to
 get deb sigs done, it's roughly half a year before that's finished. New
 packages, bug fixes, new upstream versions will make it take longer.

Who said anything about adding in-deb sigs to the entire archive?

  where dpkg would simply refuse
  per user-set policy any non-signed deb or any deb without a specific
  signature...
 
 I'm sorry, but you're back to the snakeoil use for deb sigs. Expecting

I see I have to spell it out completely all the time, for you will always
assume you are talking to clueless people who either doesn't know anything
about the issue at hand, or who will be impressed by your over-use of
snake-oil.

If I want dpkg to always check a signature, it is because it is a signature
I know must be there.  Like an hypothetical signature added by
DAK/dinstall/whatever, or a signature I add to all debs in a specific
repository under my control (and in this case, with a timestamp under my own
control too, which means I can use it).  Doing so with signed release files
is possible, but not always in the same way and under the same conditions,
and it requires a lot of fragile infrastructure which would be less fragile
using in-deb signatures.

 a signature by a random Debian developer to mean something is not
 reasonable.

YOU are the one who is bringing in signatures from j.random developer.
Which, I should add, is all we have in .changes files.  Release files are
something else, though.

 I'm tempted to do something like that anyway to see if the md5sum
 exploit can be used to create fire and ice .debs. Without signed debs,

Make that an exploit that says kaboom, you're it but still runs dpkg, and
I will help you with it.

 you'll have no reason to trust it, which is exactly right; with signed
 debs, you'll have reason to know I built it, but you won't have reason
 to know I was never going to upload it to Debian because I was just
 experimenting with some possible security vectors. The question is, will
 you make the unwarranted assumption that because it's been built by me,
 that it's usable my you?

I won't, that's for sure.  I might trust such a deb because it was in a
archive where you place debs for general use or something else like that,
but not because you signed it.

 The explanation you need is ...which is useful because _. Again, I
 can't see any need for multiple signatures for Debian; for non-Debian,
 if deb sigs are convenient, use them.

deb sigs get a lot less convenient if Debian doesn't allow them in debs
uploaded to the archive.  I don't really care if Debian will ever use the
in-deb signatures somehow or not, but I'd like to see them allowed into the
archive.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To 

Re: dpkg-sig support wanted?

2005-11-25 Thread Florian Weimer
* Anthony Towns:

 (I'm amazed the security crisis we're having is about deb sigs
 *again*, when we're still relying on md5sum which has a public exploit
 available now...)

These exploits are irrelevant as far as the Debian archive is
concerned.  (And that's not because hardly any sarge user verifies the
MD5 hashes, by the way. 8-)

Moving away from MD5 is certainly not a bad idea, but it's not clear
whether the alternatives are any better.  Sure, everyone recommends
SHA-256 at this stage, but nobody can give a rationale.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: dpkg-sig support wanted?

2005-11-25 Thread Thomas Bushnell BSG
Anthony Towns aj@azure.humbug.org.au writes:

 .deb signatures are aimed at giving users some sort of assurance the
 package is valid; but when you actually look into it -- at least in
 Debian's circumstances -- those signatures can't actually give any
 meaningful assurance for any specific validity.

Don't they give the user the assurance that a Debian developer was
responsible for building and providing the package?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: dpkg-sig support wanted?

2005-11-25 Thread Thomas Bushnell BSG
Goswin von Brederlow [EMAIL PROTECTED] writes:

 The archive signing key gives absolutely no integrity ensurance on the
 deb package. The only thing it insures is that the file was not
 altered _after_ leaving ftp.de.debian.org for the mirrors and/or
 user. In no way does it prevent altering the deb on ftp-master.

Isn't that a useful assurance?  Perhaps I trust the maintenance of
ftp-master, but not the maintenance of Joe Random Mirror.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: dpkg-sig support wanted?

2005-11-25 Thread Anthony Towns
On Fri, Nov 25, 2005 at 03:13:58PM +0100, Goswin von Brederlow wrote:
  You're correct.
 And he is also wrong.
 That would result in debs with the same name and version but different
 md5sums. Something that easily confuses apt-get and people.

And yet, somehow people manage partial cross-grades between Debian and
Ubuntu...

Regards,
aj



signature.asc
Description: Digital signature


Re: dpkg-sig support wanted?

2005-11-25 Thread Anthony Towns
On Fri, Nov 25, 2005 at 12:49:11PM -0800, Thomas Bushnell BSG wrote:
 Anthony Towns aj@azure.humbug.org.au writes:
  .deb signatures are aimed at giving users some sort of assurance the
  package is valid; but when you actually look into it -- at least in
  Debian's circumstances -- those signatures can't actually give any
  meaningful assurance for any specific validity.
 Don't they give the user the assurance that a Debian developer was
 responsible for building and providing the package?

Not really, they give the assurance that it was built by someone who at
some point possessed a key that at some point was considered sufficient
to identify a Debian developer or a buildd.

What assurance would you take from a package signed by Chip's old key?

(And why do you think it's actually helpful? Debian developers build
*lots* of crap, especially if you can't differentiate stuff uploaded to
Debian and not)

Cheers,
aj



signature.asc
Description: Digital signature


Re: dpkg-sig support wanted?

2005-11-25 Thread Anthony Towns
On Fri, Nov 25, 2005 at 02:27:23PM -0200, Henrique de Moraes Holschuh wrote:
 Well, the email about the new bin-NMU structure implied that it was fixed
 for *NMUs done through that structure*.  

Then the email was wrong. *shrug*

My objection is that it's *useless* for *Debian*. Debian has too many
sources for packages for key management to be plausible, and keeps
   This applies to .changes files too, with the aggravating addition that 
   those
   are a bitch to find right now.
  Uh, no, .changes files are not remotely useless for Debian right now.
  Where would you get that idea?
 I was refering to Debian has too many sources for packages for key
 management to be plausible.  Duh, obviously .change files are useful for
 Debian, DAK needs them.

Then my comment doesn't appl[y] to .changes files too.

  The tools are the least concern; what's a few dozen lines of code here
  and there matter? If you insist every package only be uploaded once, and
  do the maximum packages per day, and stop all other development just to
  get deb sigs done, it's roughly half a year before that's finished. New
  packages, bug fixes, new upstream versions will make it take longer.
 Who said anything about adding in-deb sigs to the entire archive?

If they provide a useful service, then of course they should be
everywhere. If they don't provide a useful service, why should they be
anywhere?

The dak check, for reference, is the one that authenticates an ar's in
the correct form, it's not an explicit we had dpkg-sig check.

 If I want dpkg to always check a signature, it is because it is a signature
 I know must be there.  Like an hypothetical signature added by
 DAK/dinstall/whatever, or a signature I add to all debs in a specific
 repository under my control (and in this case, with a timestamp under my own
 control too, which means I can use it).

Again, what you do in your own repositories is _fine_. .deb signatures
are a completely useful thing to do in some circumstances; which I'm
inclined to classify as private development / public release. Debian
just happens not to be in that problem space.

  a signature by a random Debian developer to mean something is not
  reasonable.
 YOU are the one who is bringing in signatures from j.random developer.

Uh, no, it's what this thread's about. You know, random developers
uploading signed packages to the archive...?

  I'm tempted to do something like that anyway to see if the md5sum
  exploit can be used to create fire and ice .debs. Without signed debs,
 Make that an exploit that says kaboom, you're it but still runs dpkg, and
 I will help you with it.

ATM I've got better things to do. But xmas is coming up, with the
corresponding need for a pointless xmas project...

  The explanation you need is ...which is useful because _. Again, I
  can't see any need for multiple signatures for Debian; for non-Debian,
  if deb sigs are convenient, use them.
 deb sigs get a lot less convenient if Debian doesn't allow them in debs
 uploaded to the archive.  

How so? Seriously -- add the signature after uploading to Debian. At
worst, if you have a deb that's in both Debian and some other source,
you might end up installing the unsigned .deb from Debian instead of the
signed version -- but you've still verified it just like every other
Debian package, so... big deal?

If you set up apt's pinning correctly, that won't even happen.

Cheers,
aj



signature.asc
Description: Digital signature


Re: dpkg-sig support wanted?

2005-11-25 Thread Anthony Towns
On Fri, Nov 25, 2005 at 07:59:40PM +0100, Florian Weimer wrote:
 * Anthony Towns:
  (I'm amazed the security crisis we're having is about deb sigs
  *again*, when we're still relying on md5sum which has a public exploit
  available now...)
 These exploits are irrelevant as far as the Debian archive is
 concerned.  (And that's not because hardly any sarge user verifies the
 MD5 hashes, by the way. 8-)

Uh. You're seriously putting your reputation on that claim?

And md5 hashes have been verified since either slink or potato depending
on when you started using apt; possibly earlier if dselect methods used
them like they should have. debootstrap certainly verified them for
woody. And heck, they've been used in .changes since day 0.

 Moving away from MD5 is certainly not a bad idea, but it's not clear
 whether the alternatives are any better.  Sure, everyone recommends
 SHA-256 at this stage, but nobody can give a rationale.

MD5 is broken; SHA-1 is where MD5 was a couple of years ago, SHA256 (or
higher) are significantly harder to break in practice, and there's
nothing better yet.

Cheers,
aj



signature.asc
Description: Digital signature


Re: dpkg-sig support wanted?

2005-11-25 Thread Matt Zimmerman
On Sat, Nov 26, 2005 at 08:48:45AM +1000, Anthony Towns wrote:
 On Fri, Nov 25, 2005 at 03:13:58PM +0100, Goswin von Brederlow wrote:
   You're correct.
  And he is also wrong.
  That would result in debs with the same name and version but different
  md5sums. Something that easily confuses apt-get and people.
 
 And yet, somehow people manage partial cross-grades between Debian and
 Ubuntu...

People manage to do it, but it really isn't a good idea at all to mix
repositories which contain different builds of the same source packages.

-- 
 - mdz


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: dpkg-sig support wanted?

2005-11-25 Thread Steinar H. Gunderson
On Sat, Nov 26, 2005 at 09:13:02AM +1000, Anthony Towns wrote:
 Moving away from MD5 is certainly not a bad idea, but it's not clear
 whether the alternatives are any better.  Sure, everyone recommends
 SHA-256 at this stage, but nobody can give a rationale.
 MD5 is broken; SHA-1 is where MD5 was a couple of years ago, SHA256 (or
 higher) are significantly harder to break in practice, and there's
 nothing better yet.

Just a comment here for those who are not used to hash functions: Broken
here means that you can generate collisions faster than using the birthday
attack (2^64 for MD5, 2^80 for SHA-1). It does not have to mean that you
can do _really_ evil stuff, like generate a second file with the same MD5
hash as a given file (so-called second preimage, IIRC) and to the best of
my knowledge, nobody has done so yet).

However, there's a long way from you can't generate a valid .deb with a
given md5sum easily to SHA-256 is no better than MD5. You can generate
an MD5 collision in four hours on a standard desktop computer today; you're
nowhere near that for SHA-1, and SHA-256 is still AFAIK not broken (although
it relies on the same basic structure as MD5 and SHA-1). All three might
eventually be truly broken, but you can bet that MD5 will be the first to
go. If you use SHA-256 today instead of MD5, you probably buy yourself a
few extra years, which you can use to smooth out the transition to the next
hash function when the world advances.

/* Steinar */
-- 
Homepage: http://www.sesse.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: dpkg-sig support wanted?

2005-11-25 Thread Brian May
 Thiemo == Thiemo Seufer [EMAIL PROTECTED] writes:

 Well, even if I know naught about it, it looks to me that having
 something signed is better than having the same something not signed.

Thiemo Sorry, but that's a snake oil rationale.

A: Why do you lock your car up[1]?

B: Because it looks like having it locked is better then not having it
locked.

A: Sorry, but that's a snake oil rationale. Anybody can pick the lock
and break in. Anybody can smash a window and break in. etc.

However, we still lock our cars regardless.  We still lock our
houses. We still use signatures and ID cards (all of which can be
forged) as protection to keep our money safe.

The reason why? Because we have just made it more difficult (or so we
hope!) for somebody to break in. We still consider this a worth while
compared with the added inconvenience of having to maintain the
additional security (e.g. keep the key safe and not lost). Despite the
fact we all know it is not absolute security.

It is also feasible. Yes, you could hire a security guard to watch
your car 24 hours a day, but that is likely to cost more then the car
is worth. Most people don't consider their cars to be this important.

I think the same thing applies here - sure somebody could interfere
with the system and either steal the private key or get a package
signed that shouldn't be signed, but if you really want to argue along
these lines, I think we remove all signatures everywhere, because the
possibility exists any one of these could be forged (especially as
Debian cannot guarantee that every maintainer keeps their private key
secure, and that their build systems are secure, etc).

So just saying its snake oil isn't really saying anything IMHO,
because taken to an extreme all security we have in this world *is*
snake oil. Sometimes it works. Sometimes it doesn't work. That doesn't
mean we shouldn't try to improve it as much as possible.

The only exception I would make is when improvements mean extra
security for political/red tape reasons which do nothing to stop the
weaknesses they are meant to stop, but instead serve to make our
politicians looks good as well as giving them more income.

However, I think the ability to trace a Debian binary package to its
source, even if the original .changes file is no longer available, is
a definite advantage, and is not any less reliable or secure then
using the original .changes file for the same purpose. In fact, you
could argue it is more secure then the Received headers everyone
relies on to trace SPAM (which have no cryptographic signature).

I also believe that the threat of somebody being tricked into
installing a Trojan package is a very real possibility, and we should
do everything we can do to aid our users prevent this from happening.


Notes:

[1] Assuming you have a car, if not replace the words car and lock
with something more appropriate.
-- 
Brian May [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: dpkg-sig support wanted?

2005-11-25 Thread Steinar H. Gunderson
On Sat, Nov 26, 2005 at 10:47:57AM +1100, Brian May wrote:
 Well, even if I know naught about it, it looks to me that having
 something signed is better than having the same something not signed.
 Sorry, but that's a snake oil rationale.
 A: Why do you lock your car up[1]?

Because it makes it harder to steal the car.

I think the point was that signing a .deb did not automatically make it
harder to do whatever the scenario asked for.

/* Steinar */
-- 
Homepage: http://www.sesse.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: dpkg-sig support wanted?

2005-11-25 Thread Steve Langasek
On Fri, Nov 25, 2005 at 02:57:36PM +0100, Goswin von Brederlow wrote:
 Steve Langasek [EMAIL PROTECTED] writes:

  On Thu, Nov 24, 2005 at 07:17:06PM +0100, Goswin von Brederlow wrote:

   That's easy: you trust the Packages file to be correct when using apt,
   and it's not verified at all by per-package signatures.

  In what way trust and how does that change anything?

  At best you can prevent a newer version of a package to appear in the
  Packages file by compromising it. You can't subvert a package itself.
  But you can already ship yesterdays Release.gpg, Release and Packages
  file to a user and thereby prevent any updates.

  On the other hand, without package signatures ftp-master adds a
  vulnerability. You can hack into it, replace debs, recreate the
  Packages, Release and Release.gpg file and thereby infect users. With
  signed debs that could still be detected by every user in apt-get.

  Only if every user is in a position to verify signatures from each Debian
  developer individually, which is completely unrealistic.

 Up to a point you can trust the keyring. As much as you can trust any
 DD signature. You try to argue that signatures are not absolutely
 trustworthy but that is nothing new.

I'm arguing that a 5-hop-long signature chain to establish the validity of a
Debian package is as good as useless, and worse if the user doesn't
understand this.

And a 5-hop-long signature chain does *not* mean that anyone in that chain
trusts the person holding the key on the end to upload packages to Debian.
The only thing we have that establishes *that* is the presence of the user's
key in the Debian keyring, so then you have the logistical problem of how
arbitrary users are supposed to verify whether a given key is in the
keyring.  The debian-keyring package doesn't get updated every time there's
a key added or removed, and the web interface to keyring.debian.org doesn't
provide any cryptographic assurances.  Oh, and BTW, check the IPs of
ftp-master.debian.org and keyring.debian.org...

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature


up-to-date debian keyring with rsync (Re: dpkg-sig support wanted?)

2005-11-25 Thread Adeodato Simó
* Steve Langasek [Fri, 25 Nov 2005 17:19:01 -0800]:

 how arbitrary users are supposed to verify whether a given key is in the
 keyring.  The debian-keyring package doesn't get updated every time there's
 a key added or removed, and the web interface to keyring.debian.org doesn't
 provide any cryptographic assurances.

  Just as a side note other developers may be interested in knowing, the
  debian keyring can be synced via rsync. I personally like having a
  mostly-up-to-date copy of it in my computer.

% cat /etc/cron.weekly/LOCAL-update-keyring
#! /bin/sh -e

cd /var/local/keyring
rsync -rlptDq rsync://keyring.debian.org/keyrings/ .

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
   Listening to: Elton John - Too many tears


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: dpkg-sig support wanted?

2005-11-25 Thread Thiemo Seufer
Brian May wrote:
  Thiemo == Thiemo Seufer [EMAIL PROTECTED] writes:
 
  Well, even if I know naught about it, it looks to me that having
  something signed is better than having the same something not signed.
 
 Thiemo Sorry, but that's a snake oil rationale.
 
 A: Why do you lock your car up[1]?
 
 B: Because it looks like having it locked is better then not having it
 locked.
 
 A: Sorry, but that's a snake oil rationale. Anybody can pick the lock
 and break in. Anybody can smash a window and break in. etc.

Wrong, it makes break-ins harder. OTOH we don't put stickers with
this car is locked on our cars.

The quote above suggested a signed package is somehow better than an
unsigned one, even when no improvements can be shown. But the only
thing it reliably achieves in that case is to increase the exposure of
the signing key.


Thiemo


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: dpkg-sig support wanted?

2005-11-25 Thread Jeroen van Wolffelaar
On Fri, Nov 25, 2005 at 05:19:01PM -0800, Steve Langasek wrote:
 Oh, and BTW, check the IPs of ftp-master.debian.org and
 keyring.debian.org...

Well, at this moment those are distinct, because ftp-master is
temporarily hosted on spohr.debian.org, and not on raff.debian.org,
where keyring.d.o still is. But yes, they used to be the same and will
again become the same.

--Jeroen

-- 
Jeroen van Wolffelaar
[EMAIL PROTECTED] (also for Jabber  MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: dpkg-sig support wanted?

2005-11-25 Thread Peter Samuelson

[Steinar H. Gunderson]
 All three might eventually be truly broken, but you can bet that MD5
 will be the first to go. If you use SHA-256 today instead of MD5, you
 probably buy yourself a few extra years, which you can use to smooth
 out the transition to the next hash function when the world advances.

You may laugh if you wish, but I think it's annoying to have to move to
a hash function whose hexadecimal representation takes 64 bytes, which
doesn't leave much room on an 80-column line to describe what the hash
is hashing.  Maybe by the time coreutils ships a sha256sum program, the
world will have settled upon BASE64, which requires only 43 bytes.


signature.asc
Description: Digital signature


Re: dpkg-sig support wanted?

2005-11-24 Thread Stefano Zacchiroli
On Thu, Nov 24, 2005 at 12:56:15AM +0100, Marc 'HE' Brockschmidt wrote:
  I will fill a whishlist bugreport against debuild to support dpkg-sig
  side by side with debuild.
 There is already #247825. #247824 is the wishlist bug for
 dpkg-buildpackage support.

Indeed, I spotted them just after the post.

-- 
Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy
[EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/
If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. -!-


signature.asc
Description: Digital signature


Re: dpkg-sig support wanted?

2005-11-24 Thread Roger Leigh
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

John Hasler [EMAIL PROTECTED] writes:

 Marc Haber writes:
 So, most of the DD's do not care about security at all.

 I think that DD's do not use dpkg-sig and debsigs because they believe them
 to be hard to use and not supported by the infrastructure or by policy.

ACK.  I certainly care about security, and I'll sign my packages just
as soon as debsign supports it.


Regards,
Roger

- -- 
Roger Leigh
Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
Debian GNU/Linuxhttp://www.debian.org/
GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ http://mailcrypt.sourceforge.net/

iD8DBQFDhZtKVcFcaSW/uEgRAp4CAJ93sOae+cyRL9KsTgrIYkme1vHjOwCfXZ4N
zmom+bKRm2tMU16IklDxSNk=
=seoz
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: dpkg-sig support wanted?

2005-11-24 Thread Marc Haber
On Thu, 24 Nov 2005 10:51:55 +, Roger Leigh
[EMAIL PROTECTED] wrote:
John Hasler [EMAIL PROTECTED] writes:
 Marc Haber writes:
 So, most of the DD's do not care about security at all.

 I think that DD's do not use dpkg-sig and debsigs because they believe them
 to be hard to use and not supported by the infrastructure or by policy.

ACK.  I certainly care about security, and I'll sign my packages just
as soon as debsign supports it.

So you wouldn't use dpkg-sig even if it were still supported by the
archive?

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber |Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom  | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834



Re: dpkg-sig support wanted?

2005-11-24 Thread Frank Küster
Marc Haber [EMAIL PROTECTED] wrote:

 On Thu, 24 Nov 2005 10:51:55 +, Roger Leigh
 [EMAIL PROTECTED] wrote:
John Hasler [EMAIL PROTECTED] writes:
 Marc Haber writes:
 So, most of the DD's do not care about security at all.

 I think that DD's do not use dpkg-sig and debsigs because they believe them
 to be hard to use and not supported by the infrastructure or by policy.

ACK.  I certainly care about security, and I'll sign my packages just
as soon as debsign supports it.

 So you wouldn't use dpkg-sig even if it were still supported by the
 archive?

I think these are bogus questions.  I am a complete non-expert in these
security things.  I am sure that if the project comes to the conclusion
that signing debs is a good thing, more people will do it irrespective
of how convenient the procedure is in the beginning.  If it finds its
way into the Developer's Reference, even more will use it (and start
integrating it into debsign or whatever).  To me, it's not a question of
whether it's easy to use, but rather whether I can be convinced that it
is worth it.

So far, I could not draw any conclusion from this discussion - both the
counter and the pro arguments contain some truth, and uneducated as I am
I cannot judge at the moment.

However, if there was no technical reason to reject signed binary
packages, it seems to me as if making that change to DAK is an abuse of
ftpmaster's powers:  This is a design decision, and it should be made
after thorough public discussion, either by finding a consensus or by
using our constitutional means of making a decision.  Changes should not
be made in advance, except if there is an unrelated technical reason (I
don't know whether this is the case).

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer



Re: dpkg-sig support wanted?

2005-11-24 Thread Wouter Verhelst
On Thu, Nov 24, 2005 at 02:11:45PM +1100, Matthew Palmer wrote:
 On Thu, Nov 24, 2005 at 11:54:33AM +1000, Anthony Towns wrote:
  On Wed, Nov 23, 2005 at 04:37:05PM -0200, Henrique de Moraes Holschuh wrote:
   On Thu, 24 Nov 2005, Anthony Towns wrote:
Personally, I think it's cryptographic snake oil, at least in so far
   A signed deb has a seal of procedence and allows one to track the path it
   made through the system, and who changed it.  
  
  That's what the .changes file is for.
 
 Only possible if the .changes file is still accessable, and going through
 the d-d-c archives isn't exactly convenient.
 
 On that score, the description for d-d-c says that it includes buildd logs,

Then that description is wrong. It never did include buildd logs, and
AFAIK, there are no plans to that effect, either.

-- 
.../ -/ ---/ .--./ / .--/ .-/ .../ -/ ../ -./ --./ / -.--/ ---/ ..-/ .-./ / -/
../ --/ ./ / .--/ ../ -/ / / -../ ./ -.-./ ---/ -../ ../ -./ --./ / --/
-.--/ / .../ ../ --./ -./ .-/ -/ ..-/ .-./ ./ .-.-.-/ / --/ ---/ .-./ .../ ./ /
../ .../ / ---/ ..-/ -/ -../ .-/ -/ ./ -../ / -/ ./ -.-./ / -./ ---/ .-../
---/ --./ -.--/ / .-/ -./ -.--/ .--/ .-/ -.--/ .-.-.-/ / ...-.-/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: dpkg-sig support wanted?

2005-11-24 Thread Adam D. Barratt
On Thursday, November 24, 2005 11:17 AM, Wouter Verhelst [EMAIL PROTECTED]
wrote:

 On Thu, Nov 24, 2005 at 02:11:45PM +1100, Matthew Palmer wrote:
[...]
 On that score, the description for d-d-c says that it includes
 buildd logs,

 Then that description is wrong. It never did include buildd logs, and
 AFAIK, there are no plans to that effect, either.

It doesn't say that.

It says:

Notices about uploaded packages for the unstable distribution, from
developers, buildds and katie, the archive sentinel.

i.e. the only e-mails from buildds involved are notices about uploaded
packages, not logs.

Adam


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: dpkg-sig support wanted?

2005-11-24 Thread Matthew Palmer
On Thu, Nov 24, 2005 at 11:38:45AM -, Adam D. Barratt wrote:
 On Thursday, November 24, 2005 11:17 AM, Wouter Verhelst [EMAIL PROTECTED]
 wrote:
 
  On Thu, Nov 24, 2005 at 02:11:45PM +1100, Matthew Palmer wrote:
 [...]
  On that score, the description for d-d-c says that it includes
  buildd logs,
 
  Then that description is wrong. It never did include buildd logs, and
  AFAIK, there are no plans to that effect, either.
 
 It doesn't say that.
 
 It says:
 
 Notices about uploaded packages for the unstable distribution, from
 developers, buildds and katie, the archive sentinel.
 
 i.e. the only e-mails from buildds involved are notices about uploaded
 packages, not logs.

Sorry, that was a massive typo on my part.  I thought buildd output, and
wrote buildd logs when I meant buildd .changes files.  My question, as
amended, though, still holds -- are the .changes associated with the upload
of autobuilt packages supposed to go to d-d-c, and if so, are they there and
I'm just not seeing them in the list archive?

- Matt


signature.asc
Description: Digital signature


Re: dpkg-sig support wanted?

2005-11-24 Thread Adeodato Simó
* Matthew Palmer [Thu, 24 Nov 2005 22:54:58 +1100]:

 Sorry, that was a massive typo on my part.  I thought buildd output, and
 wrote buildd logs when I meant buildd .changes files.  My question, as
 amended, though, still holds -- are the .changes associated with the upload
 of autobuilt packages supposed to go to d-d-c, and if so, are they there and
 I'm just not seeing them in the list archive?

  They go to the respective debian-devel-$ARCH-changes list, none of
  which is archived AIUI.

  Cheers,

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
You cannot achieve the impossible without attempting the absurd.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: dpkg-sig support wanted?

2005-11-24 Thread Henrique de Moraes Holschuh
On Thu, 24 Nov 2005, Anthony Towns wrote:
 On Wed, Nov 23, 2005 at 04:37:05PM -0200, Henrique de Moraes Holschuh wrote:
  On Thu, 24 Nov 2005, Anthony Towns wrote:
   Personally, I think it's cryptographic snake oil, at least in so far
  A signed deb has a seal of procedence and allows one to track the path it
  made through the system, and who changed it.  
 
 That's what the .changes file is for.

Well, assuming .changes is not snake-oil, then why should in-deb sigs be
called snake-oil?  After all, according to you they essentially do the same
job.

Still, .changes file do not carry all the information in-deb sigs do
(although they could, if we sign the .changes files more than once -- but
changes are DAK will croak on that too).  They're not stored along with the
.debs anywhere (we could change that too, I suppose... but I doubt one extra
file per source in the archive will be welcome).  They are *far* from being
as simple to handle as in-deb signatures.  

Not to mention that doing the inverse path (from .deb to .changes) is far
more complicated than using in-deb sigs, and is only possible in fact if you
either always respect some sort of naming convention to go from source
package to .changes (and this *IS* a kludge), or if you read all .change
files hunting for the file you want in the MD5s.

 Uh, packages not uploaded to the official Debian archive can do whatever
 they want.

Sure. But I for one won't be building all debs twice, and many others won't
either.  And proper support for in-deb signatures means added functionality
in a lot of other utilities that won't happen if Debian doesn't use in-deb
signatures, etc.

So, it makes a damn big difference if the Debian archive accepts signed debs
or not.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: dpkg-sig support wanted?

2005-11-24 Thread Henrique de Moraes Holschuh
On Thu, 24 Nov 2005, Anthony Towns wrote:
 You can already use release signatures for this. Further, changing the
 deb after upload would make it much more difficult to check the deb was
 what was uploaded -- you can no longer just use md5sum, you've instead
 got to use special tools.

While the point about you can no longer just use md5sum is useless (you
need gpg, other special tools won't make it any more difficult, especially
since they are gzip and ar), the point about not changing the .deb after
upload is a very good one.  In fact, the only good point against in-deb
signatures I've seen so far.

 Sure; but why do that inside the .deb? You can verify a detached signature
 just as easily as an inline one (gpgv sig file // gpgv file), and you

IF this means we can switch the effort to a detached signature that is more
powerful than a .changes file (or we are allowed to have multiple signatures
in a .changes file), and also that the .changes file will be stored in the
archives along with the .debs, and that .debs with wrong/incomplete/missing
Source: fields will be rejected (such as all automated bin-NMUed .debs made
until about a week ago, or any made by a maintainer right now), and that the
path to go from the Source:-field to the .origin/.changes file name is set
in stone...  then yes, detached signatures would do it.

 My objection is that it's *useless* for *Debian*. Debian has too many
 sources for packages for key management to be plausible, and keeps

This applies to .changes files too, with the aggravating addition that those
are a bitch to find right now.

 authenticated both via Packages.gz files and .changes files, which
 already exist and are usable.

ONLY if we change the way .changes files are stored. It would be best to
have them stored in the archive itself along the .debs, really, if we're
going to use them for anything other than initial acceptance through DAK.

However, integrating this on the tools will be far more difficult than an
in-deb signature (still doable, of course), where dpkg would simply refuse
per user-set policy any non-signed deb or any deb without a specific
signature...

 This is what .changes files are for, and it's useful both for recovering
 from compromises and in a cvs blame sort of sense. Note that they also
 give more information than a simple signature on the .deb.

Only if we can sign it multiple times, which is one of the capabilities of
the simple signature on the .deb we are talking about.

 Hrm, I see queue/done (which contains .changes files going back to the
 dark ages) isn't even being mirrored to merkel properly at the moment.
 That's not so constructive.

Agreed.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: dpkg-sig support wanted?

2005-11-24 Thread Simon Richter

Hi,

Henrique de Moraes Holschuh wrote:


Well, assuming .changes is not snake-oil, then why should in-deb sigs be
called snake-oil?  After all, according to you they essentially do the same
job.


Not exactly. .changes files say that the archive should be changed. If 
the archive were to accept any signed .deb just because a developer 
signed it, that would be bad(tm).


   Simon


signature.asc
Description: OpenPGP digital signature


Re: dpkg-sig support wanted?

2005-11-24 Thread Florian Weimer
* Anthony Towns:

 Personally, I think it's cryptographic snake oil, at least in so far
 as it relates to Debian. I remain interested in seeing any realistic
 demonstration of how a Debian user could reasonably rely on them for
 any practical assurance.

The assurance doesn't come from the signature, but from the procedures
that create it and leave a cryptographically secured audit trail on
the binary package.  The approach chosen by dpkg-sig makes it possible
to add further signatures while the package is propagated through
Debian's infrastructure (unless there are some instances of
compare-by-hash hard-wired into it, but there aren't AFAIK).

Of course, with current state of technology, there can't be a digital
signature that directly says that installation of this package will
not cause any harm.  But this doesn't mean that we should give up
completely.

 since May 31.  The diff at
 http://cvs.debian.org/dak/jennifer?root=dakr1=1.56r2=1.57 shows
 that the additional check was *removed*, not *added* more than a week
 ago.

 Yes; CVS was corrupted in May and hadn't been updated 'til the other
 week. http://azure.humbug.org.au/~aj/blog/2005/11/16#2005-11-16-dak

So, just to be clear, revision 1.58 (which has been committed in the
meantime) is equivalent (if not identical) to the production version,
and adding metadata in the way dpkg-sig does is no longer possible?

 Since there is no way for Debian Developers to review the way Debian
 packages are created (and it's totally out of question for end users),

 buildd.debian.org gives full logs, to developers or users.

But what do you do if there is a discrepancy between the hash in those
logs and the package which is actually in the archive?  I don't know
how common this would be; the hashes on buildd.debian.org are not in a
readily extractable format, it seems.

Oh, and I looked again at the buildd stats after some time.  Good to
see that m68k is not lagging behind as dramatically as it used to.
Debian is not doomed after all. 8-)

 something that provides DD-to-user package signatures at least in some
 cases is very desirable indeed.

 debian-devel-changes provides this.

AFAIK, binary NMus aren't announced on debian-devel-changes.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: dpkg-sig support wanted?

2005-11-24 Thread Goswin von Brederlow
Anthony Towns aj@azure.humbug.org.au writes:

 On Thu, Nov 24, 2005 at 09:09:21AM +1100, Matthew Palmer wrote:
 2) A signature from dinstall saying this package was installed in the
 Debian archive would provide a means of automatic assurance of the source
 of a binary package, when I'm putting together custom CDs or package repos.

 You can already use release signatures for this. Further, changing the

Only if you have a release signature corresponding to every deb and
the Packages files where that deb was in. If you collect debs over any
amount of time that would become a huge archive.

 deb after upload would make it much more difficult to check the deb was
 what was uploaded -- you can no longer just use md5sum, you've instead
 got to use special tools.

So? Is that so bad?

Also so far nothing is changing debs after upload. The deb signatures
so far are all done prior to uploading and even changes file
generation. Only a dinstall signature would change that, making the
changes file less easy to verify while keeping everything else the
same.

 3) I can verify the provenance of a particular package in my own custom
 repos at any time (did that come from Debian?  Did someone build it
 internally?  What's going on?) I can kinda-sorta do that if I manually sign
 each binary package I download  verify against the Packages-Release chain
 with a special came from Debian key, and I can verify the source of the
 source (heh) package via the dsc signature, but having a complete chain of
 custody on a binary package seems like a nice thing to have.

 Sure; but why do that inside the .deb? You can verify a detached signature
 just as easily as an inline one (gpgv sig file // gpgv file), and you
 can verify a signature of a hash just as easily as a signature of a file.
 If you're worried you might lose the detached, signed information, either
 keep it with the data it's authenticating (pool/main/f/foo/foo.origin,
 eg), or keep good backups, or both.

I've requested that the changes files be kept along with the debs in
pool several times. It aparently isn't going to happen. Also a
detached signature needs more space since it uses another inode and a
full block on the filesystem instead of just the few bytes inside the
deb.

And yes, I am worried about loosing the detached signatures. Why risk
it if we have a perfect mechanism without it?

 At the very least, though, I can't find a hole which makes binary package
 signatures, done properly, any less secure than per-archive signing.

 That's easy: you trust the Packages file to be correct when using apt,
 and it's not verified at all by per-package signatures.

In what way trust and how does that change anything?

At best you can prevent a newer version of a package to appear in the
Packages file by compromising it. You can't subvert a package itself.
But you can already ship yesterdays Release.gpg, Release and Packages
file to a user and thereby prevent any updates.

On the other hand, without package signatures ftp-master adds a
vulnerability. You can hack into it, replace debs, recreate the
Packages, Release and Release.gpg file and thereby infect users. With
signed debs that could still be detected by every user in apt-get.

It is not that I don't trust ftp-master but that I don't even have to
trust it.

 Is your
 objection to binary-package signing that it is no better than archive
 signing, or that it is actively *worse* than per-archive signing (again, if
 both are done properly, whatever we may define that to mean).

 My objection is that it's *useless* for *Debian*. Debian has too many
 sources for packages for key management to be plausible, and keeps
 packages unchanged over too long a period for the keys to be guaranteed
 secure for the lifetime of a package. Additionally, packages can be
 authenticated both via Packages.gz files and .changes files, which
 already exist and are usable.

Changes files are not publicly accessible on demand so they are not
practical for any authentication. And even if you have a changes file
at hand by chance its signature has exactly the same security as
debsig has. It is as secure as the DDs key. The major difference is
the accessibility.

And Packages.gz has a 24h lifetime at worst. It is only a temporary
means to validate a deb.

So both methods are, to put it in your words, *useless* for *users*.
Please have a bit of an open mind and don't just think about what the
archive needs.

 One scenario, which initially seems compelling, but which I've since
 rejected, is that of offline signing of binary packages -- the idea that
 the archive can be authenticated via signatures applied to packages before
 they hit the archive.

 This is what .changes files are for, and it's useful both for recovering
 from compromises and in a cvs blame sort of sense. Note that they also
 give more information than a simple signature on the .deb.

 Hrm, I see queue/done (which contains .changes files going back to the
 dark ages) isn't even 

Re: dpkg-sig support wanted?

2005-11-24 Thread Goswin von Brederlow
Anthony Towns aj@azure.humbug.org.au writes:

 On Thu, Nov 24, 2005 at 02:31:22PM +1100, Matthew Palmer wrote:
 Then there's the opposite argument about why not do that inside the .deb?. 

 Simple answers: unnecessary bloat, unwarranted feeling of security
 leading to bad decisions. 

Where do you have an unwarranted feeling of security? You keep hinting
at debsig being insecure but nothing you have said makes it any
different (security wise) from changes files.

 Whenever anyone asks how do you manage the keys, the answer is usually
 automatically sign by dinstall which means the deb is modified after it
 leaves the builders system (invalidating existing authentication methods)
 and usually means changing the deb after its entered the archive (for
 signatures identifying packages released as part of sarge / etch, or in
 the case where an old key expires).

That is just plain wrong. The only existing debsig signatures are all
done by the builder and/or DD prior to creating the changes file. And
that is all what the initial post in this thread was about.

Having dinstall _also_ sign debs is an option that can be implemented
or not. And it would only invalidate one authentication method: using
a plain md5sum and the changes files. The Packages files md5sum would
naturaly be the md5sum after signing and still work.

Let me repeat this for you: An automatic dinstall signature is just an
option.

...
 That's a good point.  However, what damage can be done with a bodgy Packages
 file, if only well-signed .debs are actually accepted for installation on
 the system?  

 Add a Depends: some-random-package that you know has a security hole
 to dpkg's entry in the Packages and it'll be automatically installed by
 apt. Add a Conflicts: dpkg to some package's entry and it'll never be
 installed by apt or aptitude. You can possibly be trickier by pointing
 apt at a completely different file too, so that the user thinks they're
 installing foo, but end up with bar instead only noticing if they see
 dpkg say Unpacking bar (from .../foo_*.deb). IIRC, it's tricky to make
 that actually work.

All you do there is install a trusted package or sabotage installing a
package. An attacker still can't change any package. And all of that
you can do with or without package signatures. If the original package
is buggy too bad. That is what we have security.debian.org for.

Signed debs are not ment to protect the Packages file, we have the
Release file for that. Signed debs are ment to protect the deb itself.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: dpkg-sig support wanted?

2005-11-24 Thread Frank Küster
Goswin von Brederlow [EMAIL PROTECTED] wrote:

 Anthony Towns aj@azure.humbug.org.au writes:

 deb after upload would make it much more difficult to check the deb was
 what was uploaded -- you can no longer just use md5sum, you've instead
 got to use special tools.

 So? Is that so bad?

 Also so far nothing is changing debs after upload. The deb signatures
 so far are all done prior to uploading and even changes file
 generation. Only a dinstall signature would change that, making the
 changes file less easy to verify while keeping everything else the
 same.

If such a signature mechanism is implemented, dinstall could also append
a copy of the filelist, with updated md5sums.  I'm not familiar with the
ar format, but can one restore the old md5sum when you unpack the deb,
remove the additional signature, and re-ar it?

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer



Re: dpkg-sig support wanted?

2005-11-24 Thread Goswin von Brederlow
Simon Richter [EMAIL PROTECTED] writes:

 Hi,

 Henrique de Moraes Holschuh wrote:

 Well, assuming .changes is not snake-oil, then why should in-deb sigs be
 called snake-oil?  After all, according to you they essentially do the same
 job.

 Not exactly. .changes files say that the archive should be changed. If
 the archive were to accept any signed .deb just because a developer
 signed it, that would be bad(tm).

 Simon

The only differences between accepting signed debs and signed changes
files are that changes file have some additional infos (like who gets
the ACK mails) and what set of debs go together.

Both features are still needed with signed debs and nobody has any
intention of changing them. The only request so far is to not reject
debs that are also signed themself.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: dpkg-sig support wanted?

2005-11-24 Thread Goswin von Brederlow
Anthony Towns aj@azure.humbug.org.au writes:

 On Wed, Nov 23, 2005 at 09:18:40PM +0100, Goswin von Brederlow wrote:
 Use 1: I have this deb in my apt-move mirror and I want to know if it
was compromised on yesterdays breakin
   Boot a clean system with debian keyring and check all deb
   signatures.

 Find some don't pass because they were signed with keys that have been
 removed from the keyring.

Those I remove and refetch from a clean source again. False negatives
are no big deal. 99% of the debs will verify leaving only a
managable amount of wokr behind.

 Use 2: I have this Ubuntu CD and want to know which debs are from
debian and which got recompiled
   Look for all debs that have a deb signature of the debian archive
   (to be added to dinstall at some point).

 Never to be added, because it would change the .deb from that which was
 originally uploaded, for no benefit.

Fair enough.

 Use 3: The debian servers were compromised and the security team takes
too long to check the archive for my taste
   Being a normal user I obviously have no mail archive of all the
   old changes files laying around so that road is closed. But everyone
   has a Debian stable CD with keyring. See Use 1.

 And see why it doesn't work. Not to mention keys added since stable
 released, and packages uploaded by those maintainers.

 More than just keys removed from the keyring, there's the issue of keys
 being compromised -- it's not even unknown for developers to post secret
 keys to mailing lists -- the issue that a package that's once been in the

Compromised keys are compromised keys. No matter what you use for
authentification they don't change. One has to look for revocation
certificates and remove bad keys from the keyring prio to checking
signatures.

 archive may well by now have known security holes (which is why we have

As for known security holes in packages. They are known. The signature
of a deb only tells me that no new holes were added. And yes, that is
what we have security.debian.org for.

 security.debian.org after all), and that this is entirely moot anyway
 since the vast majority of packages can't be verified by dpkg-sig.

Ah, I see the light.

Signatures are useless because packages have no signatures.
Lightbulbs do not work because without lightbulbs it is dark.
You can't breath air because there is no oxygen in a vacuum.

  buildd.debian.org gives full logs, to developers or users.
 While the log contains the md5sum of each build deb it does not
 contain any signature against tampering. 

 No, that's what the signed .changes file is for.

Which aren't readily available to the public.

 Tampered debs can be uploaded by sending a fake mail to the admin and
 filtering out his responce.  A deb signature of the buildd and a
 subsequent dak check would prevent this.

 So would having the buildd sign the mails to the buildd admin, which would
 have the benefit of not giving a couple of dozen completely untrustworthy
 keys special access to the archive. (AIUI, signed mails to the admin are
 on the TODO list; at present buildds don't have keys of their own at all)

Nothing in signed debs gives any keys additional access to the
archive. Checking for a buildd signature would only restrict the
access further from what we have already, not weaken it.

  something that provides DD-to-user package signatures at least in some
  cases is very desirable indeed.
  debian-devel-changes provides this.
 That covers only the sourcefull uploads and the arch specific -changes
 lists are not archived and therefore useless for non constant
 monitoring.

 Far easier to fix that, than retrofit 150G of debs to a flawed and
 redundant scheme like this.

 Cheers,
 aj

Where is there any flaw? You still haven't shown any that changes
files don't also have.

As to redundant. Yes they are redundant to changes files, IF ONLY one
could get a changes file when needed and have multiple signatures in it.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: dpkg-sig support wanted?

2005-11-24 Thread Marc 'HE' Brockschmidt
Frank Küster [EMAIL PROTECTED] writes:
 If such a signature mechanism is implemented, dinstall could also append
 a copy of the filelist, with updated md5sums.  I'm not familiar with the
 ar format, but can one restore the old md5sum when you unpack the deb,
 remove the additional signature, and re-ar it?

You can simply strip off the parts that change the md5sum, without the
unpack/pack cycle. The problem is to know which parts need to be removed.

Marc
-- 
BOFH #335:
the AA battery in the wallclock sends magnetic interference


pgprsAWzGrlFl.pgp
Description: PGP signature


Re: dpkg-sig support wanted?

2005-11-24 Thread Adeodato Simó
* Florian Weimer [Thu, 24 Nov 2005 18:28:04 +0100]:

Hi,

 AFAIK, binary NMus aren't announced on debian-devel-changes.

  Binary-only uploads are announced in the appropriate
  debian-devel-$ARCH-changes list.

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
As scarce as truth is, the supply has always been in excess of the demand.
-- Josh Billings


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: dpkg-sig support wanted?

2005-11-24 Thread Anthony Towns
On Thu, Nov 24, 2005 at 07:39:57AM +0100, Marc Haber wrote:
 Uh, packages not uploaded to the official Debian archive can do whatever
 they want.
 It would, however, be convenient to be able to upload a package to
 Debian and to be able to use the same package for different things.

As far as dpkg-sign's concerned, can't you already do that by building
the package, uploading it to debian, then running dpkg-sign? At worst
you'd have to run dpkg-genchanges again before uploading to your other
suite, afaics.

 Allowing things like these is what makes it possible for some people
 to work for Debian during their paid time.

Cheers,
aj



signature.asc
Description: Digital signature


Re: dpkg-sig support wanted?

2005-11-24 Thread Henrique de Moraes Holschuh
On Thu, 24 Nov 2005, Anthony Towns wrote:
 On Thu, Nov 24, 2005 at 07:39:57AM +0100, Marc Haber wrote:
  Uh, packages not uploaded to the official Debian archive can do whatever
  they want.
  It would, however, be convenient to be able to upload a package to
  Debian and to be able to use the same package for different things.
 
 As far as dpkg-sign's concerned, can't you already do that by building
 the package, uploading it to debian, then running dpkg-sign? At worst
 you'd have to run dpkg-genchanges again before uploading to your other
 suite, afaics.

You're correct.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: dpkg-sig support wanted?

2005-11-24 Thread Anthony Towns
On Thu, Nov 24, 2005 at 06:44:37PM +1100, Matthew Palmer wrote:
 On Thu, Nov 24, 2005 at 03:48:15PM +1000, Anthony Towns wrote:
  On Thu, Nov 24, 2005 at 02:31:22PM +1100, Matthew Palmer wrote:
   I think the final judgment in this issue is going to come down to personal
   taste and needs more than anything else.
  That's fine for personal repositories, it's not sufficient for Debian's
  archive.
 Well, I think that personal taste is sufficient for Debian's archive, and it
 seems obvious that Those In The Know have decided that they prefer one taste
 over another.  grin

*sigh* Do you really think that comment was helpful?

  Add a Depends: some-random-package that you know has a security hole
  to dpkg's entry in the Packages and it'll be automatically installed by
  apt.
 You're a lot more devious than I am, AJ, as I'd never considered these
 possibilities.

I've had this same conversation a dozen times before...

  No, there isn't anything, apparently the mirroring to merkel got disabled
  due to the inode usage / rsync time. There's some 700k odd changes
  files.
 Ouch.  rsync must be *loving* those.

Well, it's loving them being excluded, yeah...

Developers who'd like to play with making a workable format for .changes
files can play around with changes files separated by month up 'til
2005/04 by poking around in /org/ftp.debian.org/queue/done on merkel;
changes up 'til August are also available unseparated, but you're better
off just ignoring those for experimenting.

Cheers,
aj


signature.asc
Description: Digital signature


Re: dpkg-sig support wanted?

2005-11-24 Thread Anthony Towns
On Thu, Nov 24, 2005 at 10:43:38AM -0200, Henrique de Moraes Holschuh wrote:
 On Thu, 24 Nov 2005, Anthony Towns wrote:
  On Wed, Nov 23, 2005 at 04:37:05PM -0200, Henrique de Moraes Holschuh wrote:
   On Thu, 24 Nov 2005, Anthony Towns wrote:
Personally, I think it's cryptographic snake oil, at least in so far
   A signed deb has a seal of procedence and allows one to track the path it
   made through the system, and who changed it.  
  That's what the .changes file is for.
 Well, assuming .changes is not snake-oil, then why should in-deb sigs be
 called snake-oil?  After all, according to you they essentially do the same
 job.

Sure, and sugar water is okay for quenching your thirst, but it's still
snake oil as far as, say, curing cancer is concerned.

.deb signatures are aimed at giving users some sort of assurance the
package is valid; but when you actually look into it -- at least in
Debian's circumstances -- those signatures can't actually give any
meaningful assurance for any specific validity.

.changes files aren't aimed at users, they're aimed at the archive --
the fact that they become more complicated to validate over time isn't a
problem, because they're not expected to be validated in the future on a
regular basis.

 Still, .changes file do not carry all the information in-deb sigs do
 (although they could, if we sign the .changes files more than once -- but
 changes are DAK will croak on that too).  

You can have multiple signatures on a .changes file easily -- you
strip the old signature, add a new one, and tar the two (or more) files
up together. Or you use detached signatures of an origianl signed or
unsigned changes file. That has nothing to do with dak or Debian though.

 Not to mention that doing the inverse path (from .deb to .changes) is far
 more complicated than using in-deb sigs, 

*shrug* Grepping through files isn't that difficult. You can use indices
to make it quicker if it matters, but it doesn't.

  Uh, packages not uploaded to the official Debian archive can do whatever
  they want.
 Sure. But I for one won't be building all debs twice,

Uh, you add a signature to a .deb after building it. Upload the .deb to
Debian before signing it if you want it both in Debian and in some local
repository that requires signed debs.

 So, it makes a damn big difference if the Debian archive accepts signed debs
 or not.

Cheers,
aj



signature.asc
Description: Digital signature


Re: dpkg-sig support wanted?

2005-11-24 Thread Anthony Towns
On Thu, Nov 24, 2005 at 07:47:58PM +0100, Goswin von Brederlow wrote:
 Anthony Towns aj@azure.humbug.org.au writes:
  On Wed, Nov 23, 2005 at 09:18:40PM +0100, Goswin von Brederlow wrote:
  Use 1: I have this deb in my apt-move mirror and I want to know if it
 was compromised on yesterdays breakin
Boot a clean system with debian keyring and check all deb
signatures.
  Find some don't pass because they were signed with keys that have been
  removed from the keyring.
 Those I remove and refetch from a clean source again. False negatives
 are no big deal. 99% of the debs will verify leaving only a
 managable amount of wokr behind.

The clean source that's signed by the same key that you can't verify?

  Use 3: The debian servers were compromised and the security team takes
 too long to check the archive for my taste
Being a normal user I obviously have no mail archive of all the
old changes files laying around so that road is closed. But everyone
has a Debian stable CD with keyring. See Use 1.
  And see why it doesn't work. Not to mention keys added since stable
  released, and packages uploaded by those maintainers.
  More than just keys removed from the keyring, there's the issue of keys
  being compromised -- it's not even unknown for developers to post secret
  keys to mailing lists -- the issue that a package that's once been in the
 Compromised keys are compromised keys. 

Compromised keys are not, however, compromised debs.

 Ah, I see the light.
 Signatures are useless because packages have no signatures.

That's a transitional problem, yes. In this case it's a severe one;
since there are up to 150GBs worth of .debs. It's a problem that could be
solved if it were worthwhile, but it's not worthwhile since .changes
already do everything deb sigs could do without any transition issues,
and it's not something that can be simply ignored.

Cheers,
aj



signature.asc
Description: Digital signature


  1   2   >