Presently, we inconsistently use dashes in references to these
algorithms (e.g., CRC32C versus CRC-32C). Some popular web sources
appear to prefer dashes, and with this commit, we will, too.
Reviewed-by: Robert Haas
Discussion: https://postgr.es/m/ZrUFpLP-w2zTAHqq%40nathan
<listitem>
<para>
This key is always present on the last line of the backup manifest file.
- The associated value is a SHA256 checksum of all the preceding lines.
+ The associated value is a SHA-256 checksum of all the preceding lines.
We use a fixed checksum method here to make it possible for clients
- to do incremental parsing of the manifest. While a SHA256 checksum
- is significantly more expensive than a CRC32C checksum, the manifest
+ to do incremental parsing of the manifest. While a SHA-256 checksum
+ is significantly more expensive than a CRC-32C checksum, the manifest
should normally be small enough that the extra computation won't matter
very much.
</para>
<para>
The algorithms in <function>crypt()</function> differ from the usual
- MD5 or SHA1 hashing algorithms in the following respects:
+ MD5 or SHA-1 hashing algorithms in the following respects:
</para>
<orderedlist>
</listitem>
<listitem>
<para>
- A SHA1 hash of the random prefix and data is appended.
+ A SHA-1 hash of the random prefix and data is appended.
</para>
</listitem>
<listitem>
<para>
Using a SHA hash function provides a cryptographically secure digest
of each file for users who wish to verify that the backup has not been
- tampered with, while the CRC32C algorithm provides a checksum that is
+ tampered with, while the CRC-32C algorithm provides a checksum that is
much faster to calculate; it is good at catching errors due to accidental
changes but is not resistant to malicious modifications. Note that, to
be useful against an adversary who has access to the backup, the backup