Symmetrical encryption with hashing algorithm

Question

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.

Answer 1

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

Answer 2

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.