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

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.

• No. ​ ​ ​ ​ ​ ​
– user991
Feb 5 '16 at 9:58
• There are several other questions this could be marked duplicate of. E.g. 1, 2.
– otus
Feb 5 '16 at 10:10
• Although I've answered, mainly to directly answer some parts of the question of James, I don't mind if this gets closed or not. I do think there will be many dupes in the end. Feb 5 '16 at 10:16
• Otus your later sources mean the same as i do, the first one is taking a slightly different approach. If SO offers me the possibility to mark the duplicate for one of these ill accept them (at the moment it only offers the first one). Feb 5 '16 at 10:20
• @JamesCameron You should be able to just paste the link in the top text field (or maybe that only comes with more rep, I'm not 100% sure). A somewhat belated welcome to crypto, by the way :) Feb 5 '16 at 10:22

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.

• The idea is that it still is impossible to bruteforce - you would have an unlimited amount of decrypted plaintexts of the same length but are not able to verify the authenticity of it. As the algorithm can be chosen as well there is an added layer of security as it is unclear when a hash chunk ends and what the character set is. Feb 5 '16 at 10:09
• With an OTP an "added layer of security" doesn't make any sense. Either it is perfectly secure, or it is not. Feb 5 '16 at 10:13
• A MAC would be a very sensible "added layer of security" for an OTP. ​ ​
– user991
Feb 5 '16 at 10:33
• @RickyDemer True, not with regards to secrecy though :) Feb 5 '16 at 11:07
• "not with regards to secrecy" against eavesdroppers. ​ It would make a huge difference against chosen-ciphertext attacks. ​ ​ ​ ​
– user991
Feb 5 '16 at 13:11