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

New Issue

warner · 2007-07-12T18:50:37Z

warner commented

2007-07-12 18:50:37 +00:00

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).

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).

warner added the

labels 2007-07-12 18:50:37 +00:00

warner added this to the undecided milestone 2007-07-12 18:50:37 +00:00

warner added

code-encoding

and removed

code

labels 2007-08-14 19:00:06 +00:00

zooko commented

2007-08-20 17:56:35 +00:00

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

zooko modified the milestone from undecided to 0.6.0

2007-08-20 17:56:35 +00:00

zooko self-assigned this 2007-08-20 17:56:35 +00:00

zooko commented

2007-09-17 21:29:48 +00:00

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.

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 modified the milestone from 0.6.0 to undecided

2007-09-17 21:29:48 +00:00

zooko commented

2007-09-25 04:36:03 +00:00

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.

zooko added the

wontfix

label 2007-09-25 04:36:03 +00:00

zooko closed this issue

2007-09-25 04:36:03 +00:00

zooko added

0.6.0

and removed

0.4.0

labels 2007-09-25 04:36:08 +00:00

davidsarah commented

2009-12-13 01:16:23 +00:00

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

Sign in to join this conversation.