Hi Branden,
"G. Branden Robinson" <[email protected]> writes:
> At 2025-11-23T12:59:41-0800, Collin Funk wrote:
>> In the documentation of md5sum and sha1sum we have a paragraph
>> mentioning that there are known collisions that make these algorithms
>> insecure.
>>
>> How about listing algorithms currently considered secure for the
>> documentation of 'cksum -a'? I have attached a proposed patch.
>>
>> I don't think there is any problems with SM3, but I can't find much
>> written in English about it. I have excluded it since my understanding
>> is that you would only use it if you were selling an enterprise
>> application in Chinese markets, for example. Python's cryptography
>> module says something along those lines too [1]:
>>
>> This hash should be used for compatibility purposes where required
>> and is not otherwise recommended for use.
>
> Just a drive-by suggested recast...
>
> -The following algorithms are considered secure against malicious
> -tampering, i.e., there is no known way to modify a file to produce the
> -same checksum:
> +As of this writing, the coreutils developers consider the following
> +algorithms secure against tampering; that is, they know of no way to
> +modify a file to produce same checksum.
> @example
> @samp{sha2} equivalent to @command{sha@{224,256,384,512@}sum}
> @samp{sha3} only available through @command{cksum}
> @samp{blake2b} equivalent to @command{b2sum}
> @end example
>
>
> I have come to favor active voice over passive in documentation
> generally, but I think it's especially important when making a
> representation of expert knowledge or best practice to users.
Assuming that I am reading your proposal with no prior knowledge, I
think your proposed phrasing would raise the question "Do others, not
coreutils developers, know how to modify a file to produce the same
checksum?"
Also, I'm not sure if the coreutils developers count as expert knowledge
in cryptographic hash functions. I certainly don't have the
qualifications for it. My understanding is that there is no debate on
whether the listed algorithms can be used for secure checksums.
SHA-2 has some issues you have to be careful about for other uses [1],
but NIST isn't exactly trying to hide them [2].
> On a minor grammatical note, in groff's documentation I've come to
> articulate the principle that a colon does not relieve the writer of
> their responsibility to complete a sentence.
>
> Programmers for some reason love to use the colon as just such an escape
> hatch so they can, I guess, hurry up and dump a list and move on to
> other things.
Interesting. I like lists because I can skim through the preceding
sentence and see the items it applies to. Maybe that is an issue with me
being lazy, though.
> Lastly, "as of this writing" warns the reader of potentially stale
> information, reminding them to check the date on the document and/or
> conduct their own research regarding the state of the art.
I pushed the patch adding "currently" as Pádraig suggested to help with
that [3]. That was before I saw your message, otherwise I would have
waited a bit. Sorry about that.
Thanks,
Collin
[1] https://en.wikipedia.org/wiki/Length_extension_attack
[2]
https://csrc.nist.gov/csrc/media/Projects/crypto-publication-review-project/documents/initial-comments/fips180-4-initial-public-comments-2022.pdf
[3]
https://github.com/coreutils/coreutils/commit/b1ccb268b12f66eae6c09d833d68dd9ed40ad7b7
