SHA-1 vs SHA256 + public key

SHA-1 vs SHA256 + public key

[Mark Rijckenberg]

[-- Attachment #1: Type: text/plain, Size: 3949 bytes --]

Hi,

I noticed that your team still distributes SHA-1 checksums for the .iso
images for guix at – for example – the following URL:

https://lists.gnu.org/archive/html/guix-devel/2017-05/msg00379.html
<https://sourceforge.net/projects/rescatux/files/rescatux_0_41_b1/>

May I kindly ask you to take a look at the following links?

https://en.wikipedia.org/wiki/Secure_Hash_Algorithms

gobolinux/LiveCD#8 <https://github.com/gobolinux/LiveCD/issues/8>

MD5, SHA-0 and SHA1 are all vulnerable to collision attacks.

SHA256 (or SHA512) is now the standard (for the moment).

I highly recommend dropping the use of MD5 (and dropping SHA-1) and
replacing it with only SHA256 (or SHA512).

I am simply using Qubes OS as an excellent point of reference, which uses
SHA256 and SHA512.

https://www.qubes-os.org/security/verifying-signatures/

https://www.qubes-os.org/downloads/

Concerning the use of Bittorrent, could you please read this?

https://www.ghacks.net/2016/02/21/linux-mint-hacked-iso-images-compromised/

If you put the .iso image and corresponding SHA256 checksum file, signature
and PGP/public key in a .zip file and distribute it immediately via
Bittorrent BEFORE hosting it on a website, hackers will probably not be
able to compromise the integrity of the .iso image, because the SHA256
checksum in the Bittorrent file is much harder to alter than one stored on
a website. Furthermore, you then have the option of comparing the SHA256
value in the .torrent file with the value on the website. This goes even
further than what most GNU/Linux distributions actually do….

“The reason is simple; popular torrents are distributed from several
seeders and peers, and once they are in circulation, it is not possible to
manipulate the data, say replace it with a hacked image.”

I also suggest putting all this information (iso image, SHA256 checksum
file, signature and PGP/public key) into a single location, for example
here to make it more visible to everybody:

https://www.gnu.org/software/guix/download/

Kind regards,

Mark Rijckenberg


===========================================================================================


IRC chat history this evening:


[19:56] == Ulysses_ [3eeb5324@gateway/web/freenode/ip.62.235.83.36] has
joined #guix

...
[20:00] <Ulysses_> Hi! Are any of the guix webadministrators who post the
iso image and signature file online, present?
[20:01] <mbakke> Ulysses_: Both maintainers seem to be afk at the moment.
Why do you ask?
[20:04] <Ulysses_> I would like to know if it would be possible to put the
SHA256 and SHA512 Checksums, a PGP key and signature file next to each
posted .iso image, the same way that Qubes OS does? Even better would be to
put it all in a zipped torrent file..... What do you think?
[20:04] == retard [3226785c@gateway/web/freenode/ip.50.38.120.92] has
joined #guix
[20:04] <retard> Anyone here?
[20:05] == retard [3226785c@gateway/web/freenode/ip.50.38.120.92] has quit
[Client Quit]
[20:06] == brendyyn [~brendyn@203-7-82-172.dyn.iinet.net.au] has quit [Ping
timeout: 268 seconds]
[20:07] <mbakke> Ulysses_: the signatures are already there on the download
page, and SHA1(!) checksums are posted in the release announcement
[20:07] <solene> Ulysses_: there is a mail with sig files links and the
checksums
[20:07] <mbakke> oh, you meant the actual public key
[20:08] <Ulysses_> MD5, SHA-0 and SHA1 are all vulnerable to collision
attacks...
[20:09] <Ulysses_> take a look at the Qubes OS website here (as an example)
: https://www.qubes-os.org/downloads/
[20:09] <Ulysses_> SHA256 and above are not (yet) vulnerable to collision
attacks....
[20:09] <mbakke> Ulysses_: the public keys can be downloaded from Savannah,
but I agree they could be more visible
[20:10] <mbakke> can you send a message to guix-devel@gnu.org about this?
[20:10] <Ulysses_> OK will do :-)

[-- Attachment #2: Type: text/html, Size: 19225 bytes --]

Re: SHA-1 vs SHA256 + public key

[Mark H Weaver]

Hi Mark,

Mark Rijckenberg <markrijckenberg@gmail.com> writes:
> I noticed that your team still distributes SHA-1 checksums for the
> .iso images for guix at – for example – the following URL:
>
> https://lists.gnu.org/archive/html/guix-devel/2017-05/msg00379.html

The same announcement also prominently lists the detached digital
signatures for every file, and includes instructions on how to use GnuPG
to perform the verification.  Those digital signatures are based on
SHA256 and 4096-bit RSA.

The hashes included in the announcement are not able to provide secure
authentication, regardless of what hash function is used, because the
announcement itself might have been modified before it reaches your
mailbox.  I think it's a mistake to give anyone the impression that this
method can be made secure.

I cannot speak for Ludovic, but I strongly suspect the purpose of those
SHA-1 hashes is merely to provide a convenient way to check for benign
file transfer errors.  It may be that we should include an explicit
warning that those hashes are not suitable for authentication.

> SHA256 (or SHA512) is now the standard (for the moment).

Yes, and SHA256 is the primary hash function used within Guix.  Most
notably, you'll find that every package definition in Guix includes a
SHA256 hash of the associated source tarball.

     Regards,
       Mark

Re: SHA-1 vs SHA256 + public key

[Mark H Weaver]

I wrote:
> The hashes included in the announcement are not able to provide secure
> authentication, regardless of what hash function is used, because the
> announcement itself might have been modified

I forgot that the announcement itself was signed, which invalidates much
of what I wrote earlier.  Sorry for the noise.

I agree that we should include stronger hashes in the announcement.

      Mark

Re: SHA-1 vs SHA256 + public key

[Ludovic Courtès]

Mark H Weaver <mhw@netris.org> skribis:

> I wrote:
>> The hashes included in the announcement are not able to provide secure
>> authentication, regardless of what hash function is used, because the
>> announcement itself might have been modified
>
> I forgot that the announcement itself was signed, which invalidates much
> of what I wrote earlier.  Sorry for the noise.
>
> I agree that we should include stronger hashes in the announcement.

Agreed, we should do that.

(Providing hashes in the message, which is archived, provides a way for
people to make sure we will not modify the uploaded file in place in the
future.)

Ludo’.