Answer the question
In order to leave comments, you need to log in
Storing a strong hash value from the plaintext, next to the ciphertext?
Is it considered a security issue/bad taste to store a strong hash value from the plaintext next to the ciphertext.
For example, an encrypted file is stored, and SHA256 from unencrypted content lies nearby.
In theory, such a neighborhood can facilitate brute force.
On the other hand, for example, the winrar archiver stores the crc32 of unencrypted files in an encrypted archive. Maybe the fact is that
crc32 itself is also encrypted? Or is it that crc32 is obviously shorter than the encryption key and not resistant?
Are there any examples of software / services where subj is practiced?
UPD:
There is, for example, a topic on stackoverflow, including this problem. And two opposite opinions about the problem.
stackoverflow.com/questions/6112867/which-procedur...
part of the question:
A. Do I gain anything from storing encrypted Seed and CRC? Would it be less secure if I store them not encrypted?
You should never save the CRC unencrypted since a CRC gives information about the data within the encrypted container.
I recommend hashing the unencrypted data and storing the hash unencrypted,
Answer the question
In order to leave comments, you need to log in
It looks like a solution has been found - it's not secure.
First
stackoverflow.com/questions/2845986/does-having-an-unencrypted-sha-224-checksum-create-a-vulnerability
is vulnerable to rainbow table attack.
those. indeed, if we have a million of these encrypted files and terabytes of information, you can easily find a file with
some password in text form (such as the name of your favorite dog and a couple of numbers), even without reading / decrypting all these terabytes.
(as protection it is suggested to use hmac and salt)
Secondly
_http://www.cs.jhu.edu/~astubble/dss/winzip.pdf
the same thing in WinZip is considered a vulnerability:
"Due to a security flaw in AE-1 (CRC of plaintext is included in unencrypted format in the output), it was replaced by AE-2 in WinZip 9.0 Beta 3."
I think the only way out is to store a binary representation of the hash encrypted with the same or another key. Or store a hash from encrypted data, and not
from plain text.
In general, the presence of ciphertext can indicate the length of the plaintext, thereby facilitating guessing. For MD5, for example, this can greatly optimize the search. I think you can come up with reasons why ciphertexts should not be given away :-)
Didn't find what you were looking for?
Ask your questionAsk a Question
731 491 924 answers to any question