Ah, I understand, I missed that TRIM stores "0" unencrypted.
Then another threat model came to mind.
Imagine that the TRIM function is not enabled on the disk.
Imagine that some file "secret.txt" was saved on the disk, later it will be overwritten by the file "secret2.txt", but in time it will be overwritten again to "secret.txt"
This would create duplicate ciphertext data on disk, or am I wrong?
The attacker should be able to guess what plaintext it is, then try all the tweak values and then generate the disk decryption key from that. Am I getting it right?
Thx :-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In the documentation I found only the passage "Description of XTS mode"
From what is written there, I understood it as I wrote it in the previous post. I thought that the values "i" and "n" are the logical indexes ($Mft indexes), which can be used many times for multiple data on the ssd due to the wear-leveling. Thus from my assumptions some strings may be the same on the disk and may draw attention. Could someone explain it to me more in detail please, why this attack isnt possible?
Thank you
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
-Let's imagine that 0 are written in some parts of the encrypted disk as a result of secure wipe or TRIM.
-Let's imagine that the attacker correctly guesses that the 0s are hiding behind the ciphertext in these places on the disk.
Will it be enough to be able to decrypt the entire disk in a feasible time interval?
Thanks
I assume, the zeros are written to the volume and therefore become encrypted? This would then be very unlikely.
Greets
https://www.veracrypt.fr/en/Trim%20Operation.html
Ah, I understand, I missed that TRIM stores "0" unencrypted.
Then another threat model came to mind.
Imagine that the TRIM function is not enabled on the disk.
Imagine that some file "secret.txt" was saved on the disk, later it will be overwritten by the file "secret2.txt", but in time it will be overwritten again to "secret.txt"
This would create duplicate ciphertext data on disk, or am I wrong?
The attacker should be able to guess what plaintext it is, then try all the tweak values and then generate the disk decryption key from that. Am I getting it right?
Thx :-)
This isn't true either, as VeraCrypt uses cipher blocks. Please read VC's documentation about this.
Greets
In the documentation I found only the passage "Description of XTS mode"
From what is written there, I understood it as I wrote it in the previous post. I thought that the values "i" and "n" are the logical indexes ($Mft indexes), which can be used many times for multiple data on the ssd due to the wear-leveling. Thus from my assumptions some strings may be the same on the disk and may draw attention. Could someone explain it to me more in detail please, why this attack isnt possible?
Thank you