# Is this a provably secure scheme to encrypt a private key?

I got this idea to use the features of the one-time pad, an encryption technique that provably cannot be cracked, but this time applied to encrypt a private key. A possible application could be to encrypt the private keys of a bitcoin wallet, or any other random private-key data. It fills a similar market as the familiar AES encryption but with the following features:

• (as a con) it is restricted to random data such as private-keys
• (as a pro) it is provably secure.

The algorithm is subject to the same limitations as a one-time pad algorithm and has the same benefits, but it can be used to encrypt sensitive data such as a bitcoin wallet in a provably secure manner. This is an improvement on the current art, which generally consists of using AES.

The algorithm would work as follows. I'll use 256 bit as an example, but any size should be fine for the algo to work (of course, the more bits, the more secure it is).

1. Generate a 256-bit random number. This is the private key.
2. Prompt the user for a password that is at least 256-bit long.
3. Produce an encrypted file using XOR over the private key and the password.
4. Delete the private key, saving only the encrypted file.

A user, aware of the password and the encrypted file, can produce the cleartext private key. Whereas an attacker, only aware of the encrypted file, provably cannot improve the brute force attack - the encrypted file, as it acts as the key component to a one-time pad, thus acquires its benefits.

Note: If 256-bit is considered too long for some user to remember their passwords, one can use a hashing algorithm such as Argon2 to produce a hash of 256-bits, possibly using a shorter password. In this case, the encrypted file will be produced as a result of using XOR between the hash and the private key. In this case, the security of the scheme is potentially less than if the user had used a 256-bit long password, but this nonetheless allows the user to tradeoff between password-length and security, which might be desirable in some circumstances.

This scheme guarantees that there are -provably- no possible algorithmic weaknesses with the encryption scheme: any and all possible weaknesses are exclusively offset to the domain of password selection by the end-user.

Unless I am missing something major here, this seems 100% the way to go to truly secure my private-keys... way way way better than AES. Am I missing something?

• Comments are not for extended discussion; this conversation has been moved to chat. Dec 16 '20 at 11:50
• I've rolled back the last two edits as it removed all the information required for the answers to make sense. Please do not vandalize your own posts and respect the effort of the commenters / answerers. Dec 16 '20 at 11:53

The security proof for a one-time pad only guarantees one specific type of security ( "perfect secrecy" -- that the ciphertext provides no information about the plaintext) when it is used correctly (the key is completely random, as long as the plaintext, never reused, and kept secret). But you're not using it in a way that this proof applies.

If you treat the user password as the key, the problem is obvious: the key is not truly random, and might not even be as long as the plaintext. And (knowing users) has probably been reused.

You appear to be treating it differently, thinking of the bitcoin private key (or other similar key) as the encryption key, and the user password as the plaintext. If you think of it this way, there are (at least) two problems:

1. You're reusing the key for bitcoin (or whatever). Even though you're not reusing it for this same type of encryption, it's a reuse, and it violates the assumptions of the proof.

2. Worse, if you think of it this way, perfect secrecy of the plaintext is not relevant; what you want is resistance to key recovery, which is not a type of security that OTP provides. At all.

As a result, the security proof for OTP simply doesn't apply to your proposed system. And in fact, it's pretty easy to attack:

Generate password guesses (use your favorite password guesser).
For each guess:
XOR with the encrypted key
Test to see if the result is the private key that matches the target's BTC public key (or whatever).


How quickly this attack can recover the private key depends entirely on how hard it is to guess the password, meaning it doesn't have any advantage over any other password-based encryption system.

Perhaps worse, some information about the private key can be recovered without even needing to guess the user password, just by guessing what types of characters are in the password. For instance, if the user speaks English, it's a safe bet the user password is all printable ASCII characters. That means the eighth bit of each byte in the password is 0, and the sixth and seventh are not both 0. That means just from looking at the encrypted key, you can immediately guess the eighth bit of the corresponding byte of the private key, and also narrow the possibilities for the sixth and seventh.

• So you arguments are : 1) users are bad and are likely to violate the standard by re-using the key 2) You can guess the password by brute force 3) If you use secondary algorithms on the private key, such as public-private key message signing, it might count as a form of reuse. --- 1) and 2) are non-arguments for trivial reasons (cracking means improving upon brute force). 3) is slightly higher up the food chain, but in actuality, is also a non-starter because using the private key in a secondary algorithm does not leak any usable information beyond what the secondary algorithm leaks. Dec 5 '20 at 14:51
• Saying that being vulnerable to brute force attack is a weakness is equivalent to saying that a system is not secure because someone can randomly guess the right password. It makes no sense. One can always guess the right password to any encryption scheme. Dec 5 '20 at 16:03
• Many encryption schemes use keys, not passwords. A key of 128 bits or more can't be guessed even if you use all the computers in the world, with Moore's law continuing (2x as much power every 18 months), for over a billion years. With a 256 bit key you can make the same guarantee, but with all of the computers being quantum computers. That guarantee does not hold for passwords in general. Dec 6 '20 at 17:25
• @AlexandreH.Tremblay Perfect secrecy (such as a true OTP provides) implies that the system is secure even against brute force attack. Consider a minimal case: encrypting a single-bit message (e.g. the answer to a yes/no question). To encrypt with OTP, we'd XOR it with a single random bit. An attacker who intercepts it can trivially try both possible keys, but they'd just get both possible plaintexts as output, with no way to tell which is correct. The ciphertext leaks exactly zero information about the plaintext, even with a complete brute-force attack. This is not true of your system. Dec 7 '20 at 4:18
• Also, you've misstated my points. My actual arguments are 1) your system does not use OTP properly for the OTP security proof to apply to your usage, so your citation of OTP's security is irrelevant, and 2) your system isn't any more secure than any basic password-based encryption (and in at least one respect is significantly less secure). (Adding a proper password hash to your system would bring it up to a reasonable security standard, but the security would mostly be coming from the hash, not from any connection to OTP.) Dec 7 '20 at 4:26

This provides no benefit whatsoever. It only makes you store some useless extra data.

Either the "password" is 256 bits of random data, or it's not.
If it is, then you've got a one-time pad, but you have the same problem you originally had: how to securely store 256 bits of random data.
If it's not, you don't have a one-time pad.

So either way you go from storing a 256-bit secret to storing 256 bits of ciphertext + 256 bits of "password". The only thing you've done is waste your own time and space.

• You can use my scheme to encrypt any amount of random data (say 5 terabytes) by only using a 256bit password and the scheme would be provably secure nonetheless. Dec 5 '20 at 1:35
• No, it wouldn't. You lose provable security the instant the plaintext length exceeds the password length. Dec 5 '20 at 2:03
• Well no, because the provable security kicks in at the level of the encrypted file which is always the same size of the cleartext, and not at the level of the password. The password is the equivalent of the OTP message and can be shorter than the cleartext with no impact on provability. Dec 5 '20 at 2:57
• To be more precise, in standard OTP, one may have a 64bits one-time-pad (P) and a message (M) less than or equal to 64bits. One can then P xor M to produce an encrypted message (S) of size 64bits. In this scheme, S is provably secure. In my scheme, we switch the security focus to P instead of M, but the math is nearly the same. Since size(M)<=64bits, one uses a function mapping size(M) to a collision-free hash of 64bits. Then, P xor hash(M) = S. If S gets leaked, the adversary cannot guess which P out of 2^size(M) possibility, M encrypts. Dec 5 '20 at 22:18
• Our long chat, your question, and your comments all sum up why you shouldn't roll your own. I will list a few reasons as politely as possible. You - 1) aren't a cryptographer 2) don't understand what makes a OTP "provably secure", nor why your scheme isn't one. 3) don't understand the insignificance of attacks on AES in regards to your use case. 4) still don't realise that IF your scheme was a OTP, then it follows that AES used in the same way is also a OTP. 5) don't know how AES works, nor it's various modes of operation. 6) claimed your scheme is "way way way better" than AES. Dec 6 '20 at 9:46