[Dev] Cleaning up the repos

The Mighty Gravi themightygravi at inventati.org
Sun Nov 30 13:34:59 GMT 2014


laigualdad <laigualdad at riseup.net> writes:

> TL;DR: You're right, and I was just being paranoid, sorry.
There are some true reason to be paranoid when it's about browsing the
net, using remote calling services and even using the most minimal
software that connects to a network, but really not in this situation.

> Yes, authenticity was the wrong word... What I meant is an SFV file,
> or actually CRC32 checksum, does not protect from intentional
> manipulation; it is trivial for CRC32 to be forged.[1] I'm not a
> cryptography expert, but my rationale for suggesting more powerful
> hashes is that CRC32 and other checksums prior to SHA-2 are vulnerable
> to collision attacks.

Well, there's no thing called collision attack on file integrity
literature, and even if it existed, it would be little useful in order
to replace a file with the same checksum. Some consistency
and similarities in size and functionality with the original is very
remote.

Checksum collision, in the other hand is a real concern when we don't
know from beginning some parameters that increase the rate of
coincidence, for example size, date, type of file (headers)

When it's about a file with likely the same size, format, uploaded the
same day it is generated and being accompanied by both an SFV (or other)
and a trusted GPG signature, possibilities of collision are just 0!

Another thing I would add is server is protected by SSH keypair access,
so the possibilities goes even more remote. Makes that sense?

> After some hours of researching, I think I understand now why a CRC32
> checksum was still chosen as opposed to other hashes, if the aim is
> only to detect random errors in transmission.

Indeed, CRC32 is the one always prefered for data transmission on
transient error-checking communications, such as IP protocol without
going any further.

> I used the simple mnemonic of, "a hash verifies *what*, while a PGP
> sig verifies *who*." I did more research and realized that a PGP
> signature actually can serve the same function as a hash in addition
> to checking who made it, so a file hash and a signature are redundant.

Not only PGP signatures can make and verify checksums, but it's
absolutely mandatory for its correct behaviour, be aware that each one
has its "signing date" as well, so yup.

> In fact, it would be more of a concern to decide how to trust
> Parabola's master PGP keys. In the absence of a web of trust, one has
> to test the hashes of multiple downloads of the key, as demonstrated
> on the website[4] of the TAILS distro, or by comparing fingerprints to
> a public key page[5][6]. Hmm... I might add that to the wiki.

GPG/PGP signatures already serves for us to build a trust-chain which is
propagated through signing others keys on keyservers.

This keys don't cover the problem with identities, who one is and why
he's able to do this and that. What they do is, having been proved some
contributions are made and signed by an user, whoever he is, gets some
privilege for future ones. 

> So, I guess no action needs to be taken... I'll just submit bugs for each of the other issues. :o)

As you see, all new ideas are welcome, and we're no reluctant to consider any of them.
Hope I made the point!



More information about the Dev mailing list