This question already has an answer here:
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.