Can OTP be made practical by using stretched hash algorithms? [duplicate]

Question

One of the main reasons for not using OTP in everydays life is that it is highly impractical - for encrypting 4GB of files we need a 4GB key that needs to be exchanged secure.

I've had an idea on how to get past this problem and want the opinions of experts (thats you!) about it. The main goal is to maintain the advantages of a OTP: Having perfect secrecy as the encrypted data can be decrypted to anything of the same length.

The main idea is to use a stretched hashing algorithm for deriving the OTP from a given password. This stretched hash iterates and adds the hash of the previous data to its content to create a new hash for the next data chunk making it unique.

This is my designed implementation in pseudo code.

Method createOTP ( CLEARDATA, PASSWORD, ALGORITHM )
    set OTP to empty
    set LASTSALT to derivation of given parameters
    While length of OTP smaller than length of CLEARDATA
        set LASTSALT to stretched hash of PASSWORD and LASTSALT using ALGORITHM
        set OTP to OTP and LASTSALT
    End While
    set OTP to OTP with length of CLEARDATA
    Return OTP
End Method

I do understand that the amount of possibilities is drastically reduced by using a hash algorithm. It should be impossible to verify that a given password is correct though as all passwords create an OTP with a different outcome producing possible legit words. The amount of computing power is also an advantage as the creation of such a big key can take a lot of time and is memory expensive.

Answer 1

You are creating a key stream using a hash function. This is often called a stream mode of operation (although it doesn't seem to be a well defined term). This is a known method of creating a key stream.

An OTP requires the key stream to be completely random. This is because it would otherwise be possible to brute force the key. If you can brute force the key then the scheme obviously does not provide perfect secrecy; meaning the scheme is not an OTP.

Problem is that it is extremely unlikely that there are two passwords that would provide a stream for which the resulting plaintext makes sense. So if you find the password you're pretty certain that you've hit gold. The longer the decrypted plaintext is, the more sure you are that the password is correct.

---

It should be impossible to verify that a given password is correct though as all passwords create an OTP with a different outcome producing possible legit words.

Seems contradictory to the last paragraph. It's not correct.

The amount of computing power is also an advantage as the creation of such a big key can take a lot of time and is memory expensive.

Perfect secrecy is the notion that the scheme cannot be broken regardless of the amount of resources.

---

Instead of using a hash function we normally use a block cipher such as AES. If you combine that with a counter then you have AES-CTR. CTR is an extremely common way of building a stream cipher.