1
$\begingroup$

Thinking about validation methods for guaranteeing a proper key is used. Will keeping a dummy plaintext value and its corresponding ciphertext in plaintext code expose any risk?

$\endgroup$
2
  • 1
    $\begingroup$ Key-recovery resistance is a basic requirement in all modern ciphers under the assumption that any practical number of plaintext-ciphertext pair are known by the adversary. $\endgroup$ – DannyNiu May 27 at 5:14
  • $\begingroup$ The title a bit confusing, are you simply asking is there a secure way to see that the key is correct before decryption and validation of the whole file? $\endgroup$ – kelalaka May 27 at 6:50
1
$\begingroup$

Good thinking!

The good news is that, when you use authenticated encryption, there's no need to keep such "dummy" plaintext-ciphertext pair.

In a typical authenticated encryption, a tag is computed based on the key, the plaintext, and possibly additional data (e.g. AAD, Initialization Vector), so that upon decryption, the tag is verified for correctness. Typically, the tag is 128-bit as is the case with GCM-AES and ChaCha20-Poly1305.

Successful decryption of an authenticated ciphertext indicates that if the correct key had been used then the ciphertext along with other inputs to the encryption algorithm are correct and had not be modified by any man-in-the-middle.

$\endgroup$
5
  • $\begingroup$ What if the file is too long to see that? The proper way is to use the first block as identification and this is still secure since we need at least Ind-CPA secure ciphers. $\endgroup$ – kelalaka May 27 at 6:48
  • $\begingroup$ @kelalaka You make a good point. For large files, reserving an initial segment of data for key verification using some kind of key derivation function can speed it up a bit. We'll see what OP's use case is and then determine if more details deserve to be added. $\endgroup$ – DannyNiu May 27 at 11:52
  • 2
    $\begingroup$ "Successful decryption of an authenticated ciphertext indicates that both the correct key had been used" is not correct for AES-GCM or ChaCha20-Poly1305. Neither is key-committing, so multiple keys may decrypt to different plaintexts but still have the same tag. If you need key committment, that's easy to add, just stick a hash of the key in the AAD and validate it during decryption. $\endgroup$ – SAI Peregrinus May 27 at 12:38
  • $\begingroup$ @SAIPeregrinus Updated for the fact. $\endgroup$ – DannyNiu May 28 at 1:06
  • $\begingroup$ FYI: eprint.iacr.org/2019/016.pdf is the paper that AFAIK first showed a case where the lack of key commitment caused undesired behavior. keymaterial.net/2020/09/07/invisible-salamanders-in-aes-gcm-siv is an easy-to-understand writeup (though if you are actually "Danny" Niu Jianfang you probably don't need the blog post). $\endgroup$ – SAI Peregrinus May 28 at 14:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.