Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Actually Gentoo stopped doing that. (Which imho is sane. It's useless overhead for a completely theoretical scenario that will never happen.)


I think perhaps portage simply stopped winking ;-) at you while validating package sources on a per-algorithm basis. Typical Manifest file:

DIST <filename> <size> SHA256 <sha256_checksum> SHA512 <sha512_checksum> WHIRLPOOL <whirlpool_checksum>

Looks like SHA256, SHA512 + Whirlpool to me. Apparently the SHA algorithms have FIPS (US) and NESSIE (EU) certification. Whirlpool has NESSIE (EU) certification. Streebog has GOST (Russian) certification.

Added https://bugs.gentoo.org/show_bug.cgi?id=597736 for discussion.


You're right, I thought this was deprecated with thin manifests. Still I don't see a point in this. We should discuss cryptographic algorithms based on technical arguments, not on algorithm origin.


Seems a fairly small computational price to pay for protection against government crypto weakening.

Yes, that's paranoid, but if the price of being safe from paranoid outcomes is dropping $0.02 in a change jar, I'm willing to pay.


The price is not mainly computationally, but in complexity. You need to have a library implementing that alg, maintain that, make sure it has no security flaws...

And by the way, these Gentoo manifests, if you're worried about their cryptographic security there's something much bigger to worry about: For most users they're transmitted unprotected and unsigned via rsync. There are non-default ways to improve that, but the default is insecure. (It pains me to say this, because I'm a long time Gentoo dev, but it's a nasty truth about Gentoo's lack of security.)

If you want to improve Gentoo's cryptographic integrity this is the first thing that should be worked on (either through a working signing system that would be acceptable by default or by switching to an authenticated transmission mechanism like git over https). This would be much more helpful than adding an obscure hash algorithm.


The current sync recommendation is emerge-webrsync:

  # emerge-webrsync
  Fetching most recent snapshot ...
  Trying to retrieve 20161021 snapshot from http://mirror.com/gentoo ...
  Fetching file portage-20161021.tar.xz.md5sum ...
  Fetching file portage-20161021.tar.xz.gpgsig ...
  Fetching file portage-20161021.tar.xz ...
GPG is enough cryptographic assurance for me.

(Edit: WTF! Either past-midnight has zapped my brain, or this is a total community pants down moment. emerge-webrsync doesn't actually verify the GPG signature by default, despite downloading it, and no warning is issued! One must follow the obtuse, well-buried instructions @ https://wiki.gentoo.org/wiki/Handbook:AMD64/Working/Features... to get it to actually verify ... I've added another bug @ https://bugs.gentoo.org/show_bug.cgi?id=597800 about this... serious misfeature! Looks like for all intents and purposes if you want to own the average Gentoo box, having MITM on sync + emerge is enough! NSA must have been using that...)


It was very sane in the 1990s, when hash combiners were invented and designed by Paul Kocher into SSL 3.0. The hashes we had to work with then were basically first generation designs, preceding the first wave of major cryptanalytic results against hashes. An MD5/SHA1 hash combiner made sense.

It is less sane now, I agree. With the possible exception of PQ schemes, cascades of all kinds are a silly idea.


Well, I'd say we can pretty clearly pinpoint when cascading schemes makes sense: When we have different algs with different security properties and we can't have them all in one algorithm then cascading makes sense.

This is the case for newhope + x25519, because one is based on well known crypto, but not quantum safe, the other is based on not so well known crypto, but (maybe) quantum safe. You could make similar arguments in the past about hash functions when the analysis around their safety was much more fuzzy. (Which is why I can also understand why Gentoo decided way back to combine sha2+whirlpool.)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: