Score:1

Symmetrical encryption with hashing algorithm

hm flag

Can a file encrypted with a hashing algorithm (like SHA-256) be equally secure as a symmetrical algorithm (like AES)?

This is how it could be done using a password (this is the most simple example, please don't suggest optimizations, it's just the concept):

  • Generate random looking binary data of the same length as the file contents, using hash(password+counter+seed).
  • XOR the file contents with the data generated above
  • Store the result (the encrypted file) as the seed, followed by the XOR'ed data from above. The length of the encrypted file is (seed size + original file length).

The seed of course needs to be unique for every new file (like a GUID)

The question is not about how safe SHA-256 or AES is, or how safe a password is. Just assume we have a perfect hashing algorithm, a perfect symmetrical algorithm and a perfect password.

The question is why the encryption described above would be easier to break as the symmetrical algorithm.

Marc Ilunga avatar
tr flag
To encrypt in counter mode with a hash function consider using HMAC, it is assumed to be a pseudo-random function hence the security analysis of CTR mode apply.
Marc Ilunga avatar
tr flag
If you get specific about the primitive, sponge based constructions can be used to build aead schemes like' https://keccak.team/ketje.html
Maarten Bodewes avatar
in flag
Some nags: ciphers require a key, not a password. To create a key from a password (*only* when a password is the only option) you'd use a PBKDF, regardless of the type of cipher. You use `data + SHA256(...)` after explaining that `+` is concatenation, but it is unclear what `data` is supposed to be. As it currently stands, the encryption routine is not well defined.
samuel-lucas6 avatar
bs flag
scrypt has been used as a stream cipher. What you're talking about is very inefficient and non-standard though and thus shouldn't be used over a symmetric algorithm.
Maarten Bodewes avatar
in flag
If you make edits then please spell check. SHA-256 is the official name of the hash function. If such edits are made by high rep users, then please do not reverse them. On the content: a password that is completely secure is probably better called a *secret* (or, if it completely consists of randomized bits, a *key*).
Score:3
ng flag

Why would the encryption (in the question) be easier to break than a symmetrical algorithm ?

The question uses it's hash algorithm to generate the keystream of a stream cipher. It's a symmetric encryption algorithm, about as safe as a standard symmetric encryption algorithm if that's directly using the password as key. But it's much less safe than a competently specified and implemented symmetric encryption algorithm, which should use a memory-hard password-based key derivation function like Argon2 to turn the password into a key.

For an ideal† hash, the only way to break the question's cipher is to guess the password. Proving this is a mere technicality. But the use of "password" implies something low-entropy, and the use of SHA-256 makes it a dream for password cracking because it's well suited for GPUs, FPGAs, and ASICs. Passwords will be testable at extremely high speed except if the plaintext is essentially random.


† in the sense of being assimilable to a random oracle or to a public arbitrary member of a pseudo-random function family. The hash being collision-resistant or preimage-resistant is not enough for security. While SHA-256 is not designed for use as a random oracle or PRF, it's unbroken in these uses (when it's length extension property does not matter, which is the case at hand).

cn flag
The suggested scheme is also *much* less efficient than say AES in CTR mode.
fgrieu avatar
ng flag
With AES in hardware and SHA-256 in software, for sure. Otherwise that's going to be tight, and I even doubt it in software that must be resistant to timing/side channel attacks.
Score:1
cx flag

Issue is this: counter + seed are not secret, only password is, so your scheme is only as secure as your password is.

Let's say your password is random and it uses lowercase, uppercase letters and digits. (62 possible characters in total).

For 128-bit security (like AES-128) your random password would have to be around 22 letters long.

For 192-bit security (like AES-192), it would have to be around 33 random letters long.

For 256-bit security (like AES-256), it would have to be around 44 random letters long.

If you use shorter passwords, your scheme would be easier to break than standard symmetric ciphers.

Bigjim avatar
hm flag
That's why I've put "assume we have a perfect password" in the question. 1 million bits of entropy if you want. This question is not about password security.
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.