add a check block to the front of the plaintext, to verify the correct key

[warner]

A cheap way to verify that the decoding process is using the correct AES key would be to add a block of well-known contents at the beginning of the plaintext during encryption, and to verify that it is still present during decryption.

This might also detect certain failures in FEC, although there are probably a number that would go undetected. It would also not catch bugs like the AES-CTR-mode bug we had (which was only triggered by non-blocksize reads).

But it would be cheap, and would detect the most common case (somebody mis-typing their URI).

[zooko]

This is part of the "long-term data reliability" task. I would like to see it done for v0.6.

[zooko]

Brian points out that nowadays we use the secure hash of the symmetric key as the storage index. Therefore, if someone has mistyped their symmetric key, then they'll never download anything at all.

In theory, someone in the future might want to use the Tahoe crypto format without using the Tahoe data storage. (For example, a future version of Tahoe might be able to download the ciphertext of a file even if the secret key of a file is corrupted.) So I'm moving this ticket to the "milestone: undecided" bucket.

[zooko]

I'm resolving this as wontfix. If in the future we or someone else uses our storage in such a way that you can end up with the wrong decryption key for your ciphertext then we should return to this idea.

[davidsarah]

#453 [safely add plaintext_hash to immutable UEB] would address the same integrity issue, for immutable files and possibly also for mutable files depending on the implementation.