Re: concrete steps for improving apt downloading security and privacy

2014-07-13 Thread Joel Rees
On Sun, Jul 13, 2014 at 1:28 PM, Noah Meyerhans  wrote:
> On Sun, Jul 13, 2014 at 08:35:56AM +0900, Joel Rees wrote:
>> MD5 has been broken for a small number of applications. Its status is
>> questionable for the rest, but if we want to help break it completely,
>> let's get all the distros that insist on still using MD5 to use it,
>> not just for signing, but for encrypting their distribution images.
>
> The point that you miss is that a chosen plaintext attack is not
> dependent on the secret key in use.

If I stand on my head does that make more sense?

Nope. Doesn't.

> It's an attack against the algorithm
> itself.

Looking at it sideways doesn't help, either.

> If we sign publically available data (be it Debian packages, CD
> images, or this email) with a given key, we really aren't giving our
> adversaries anything that they can't create for themselves.

Sure we are. We are providing them instances of a different experiment
set than any they are likely do generate themselves. Unless we use
keys generated by some algorithm they might use to generate data.

And we are also giving them the use of our servers.

> Keys are
> cheap to generate.

Keys that are cheap to generate should not be used on live data.

> If an adversary wants to perform chosen plaintext
> analysis, they can do so today with their own keys and with all the
> common public datasets they want.

And generating/managing their own data is a time cost. Moreover, if
they fail to use some arbitrary algorithm, their choice of key is
hit-and-miss, mostly miss. But if they use some algorithm, they are
subject to the problems of brute-forcing against a large attack
domain.

> Getting "all the distros that insist
> on still using MD5 to use it, not just for signing, but for encrypting
> their distribution images" won't change anything.

So, when you want to do a survey of most popular TV shows, you just
generate your own survey results and don't bother to define and canvas
an audience?

You do understand that the most effective attacks against the
algorithms are statistical in nature?

> (Not to mention that
> it shows a fundamental misunderstanding of what a digest algorithm like
> md5 actually is.)

You like to work backwards, trying to generate data from a hash, I suppose?

> noah

-- 
Joel Rees

Be careful where you see conspiracy.
Look first in your own heart.


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caar43iobz5utdg2zdaglm6yszkhnjeo+1fw-whjzpp5smj2...@mail.gmail.com



Re: could we maybe serve checksums TLS on some mirrors? (was Re: concrete steps for improving apt downloading security and privacy)

2014-07-13 Thread Elmar Stellnberger
Yes, I also think it is a pretty shame that we can not download the 
sha256/512sums
from a sever secured by https + DNSSEC/DANE. At least the master mirror 
cdimage.debian.org needs to provide a secure connection for downloading 
checksums and the *.jigdo and *.template files. Moreover I would appreciate the 
jigdo program to work with https + evtl. dnssec as well because http is 
inherently
untrusted and thus insecure. Finally jigdo itself would need to be uploaded to 
the 
master mirror as we should not execute any program without inspection from a 
source which is not secured (would imply that the source is also trusted).

If we have https + DNSSEC for lists.debian.org and debian.org why not also for
cdimage.debian.org?

Elmar


Am 10.07.2014 um 18:52 schrieb Joel Rees:

> When I download a new install image, I pretty much always go to random
> mirrors, some largish/mainish and some smalish/obscure and download
> the copies of the checksum files. If all the checksum files compare, I
> can be pretty confident that one of the following conditions exists:
> 
> (1) The image is good if the checksum command reports the correct checksum.
> 
> (2) Some attacker has compromised every mirror I have accessed.
> 
> (3) Some attacker is doing deep inspections on my traffic and
> redirecting traffic every time I go looking for a debian mirror.
> 
> I check a minimum of three mirrors, but when I'm feeling especially
> paranoid I'll check five or six.
> 
> It occurs to me that I might cede some usefulness to having the
> checksums (not images) served TLS transport on at least one of the
> mirrors, if and only if I remember to set the SSL_CERT_FILE before I
> fire up lynx to go get the checksums. It won't help me if my
> randomness in choosing the servers isn't good enough in case (2), but
> it should help in case (3).