# Symmetrical encryption with hashing algorithm

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.

• 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. Commented Nov 28, 2022 at 11:16
• If you get specific about the primitive, sponge based constructions can be used to build aead schemes like' keccak.team/ketje.html Commented Nov 28, 2022 at 11:22
• 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. Commented Nov 28, 2022 at 11:43
• 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. Commented Nov 28, 2022 at 13:02
• 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). Commented Nov 28, 2022 at 14:24

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

• The suggested scheme is also much less efficient than say AES in CTR mode. Commented Nov 28, 2022 at 15:52
• 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.
– fgrieu
Commented Nov 28, 2022 at 17:58

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.

• 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. Commented Nov 28, 2022 at 13:11