<listitem>

<para>

This key is always present on the last line of the backup manifest file.

The associated value is aSHA256 checksum of all the preceding lines.

The associated value is aSHA-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 aSHA256 checksum

is significantly more expensive than aCRC32C checksum, the manifest

to do incremental parsing of the manifest. While aSHA-256 checksum

is significantly more expensive than aCRC-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 orSHA1 hashing algorithms in the following respects:

MD5 orSHA-1 hashing algorithms in the following respects:

</para>

<orderedlist>

</listitem>

<listitem>

<para>

ASHA1 hash of the random prefix and data is appended.

ASHA-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 theCRC32C algorithm provides a checksum that is

tampered with, while theCRC-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