Cipher method to encrypt recovery seed words using a unique key: seed-otp

[Forsyth Jones]

Searching for ways to store my seed phrase safely, I found this method: seed-otp or one-time-pad, this cipher method is available in the Seed Tool, mnemonic creation tool similar to iancoleman, but with more features.

This tool allows you to create an authentication key (OTP key) that is used to encrypt your recovery seed, by combining the two a new 12-word phrase is created that is completely different from your seed phrase, this new 12-word phrase is your encrypted seed by one-time-pad.



In the example above, I clicked on New Key[1], which resulted in an output in the "One Time pad key" field [2] which is the OTP-key and when clicking on Encrypt (I forgot to mark this as an item 4 in the image), it generates the encrypted mnemonic which is only decrypted with the generated otp key[2] (Sorry for the continuity error when skipping the "Encrypt" item).



Having the two items: encrypted mnemonic words and OTP-key and clicking on Decrypt: will result in the original recovery words

This prevents anyone who has access to the encrypted seed from having access to your funds, as they would have to have the authentication key and you can store this key wherever you see fit, such as in a keepass (this is the idea suggested by the creator of this method of cipher).

You can check more details on the project's github. But what I want to know is: if someone has already used it, is it still considered safe, since it only had a single release on github in 2018 and was never updated again, it appears that the project was abandoned?

One of the cons is that the cipher phrase cannot be used as a valid BIP-39 seed, as it does not have a checksum, so it cannot be used as a decoy wallet as it can no longer be used as plausible deniability in case of a 5$ wrench attack, unless you use the argument that it's an invalid BIP-39 seed that you used in Electrum for N reasons, since Electrum allows you to restore seeds without  checksum (invalid).

Another detail to be noted is that this encryption method (one-time-pad) is already old, as it was used in the Second World War and the Cold War to exchange confidential information and is considered an encryption method as one of the impossible to use be broken by brute force.

[pooya87]

This looks like a cool attempt but it suffers from a common issue: lack of reviews.
That makes it less safe to use. For example you need to know at least two basic things before you use something like this; (1) whether it generates the encryption key using a strong random generator or does it have flaws (2) whether the implementation of the algorithm has any bugs that could lead to losses.

For (1) I can say that it is using secrets.randbelow to generate words to be used in the "padding" and the doc says this class is "cryptographically strong". I'm not commenting on its security but I'd say it is a weird implementation and I'll explain below:

it does not have a checksum

The dev suffers from a common "view" of BIP39
https://github.com/brndnmtthws/seed-otp/blob/70b51e05daf054355bd7691188ff7720afc7ca3c/seed_otp/crypto.py#L3

The seed phrase is viewed as a set of words instead of as an entropy. So when they want to encrypt 12 words they generate a key that is 12 words long [1] [2] and then it "pads" each word using the generated words.
The first weirdness here is that they could just generate another BIP39 seed with the same word count and use that as the encryption key (ie. generate a 128 bit entropy, append the checksum and encode it using the word list). Instead of generating multiple integers below 2048!

And if the seed phrase is viewed as entropy, all you had to do is to decode the 12 words, remove the checksum, get the 128 bit entropy.
Then generate a 128 bit key using a cryptographically strong RNG and then go through the One-time pad encryption technique with that (eg. 32 bit at a time using UInt32).
At the end you get another 128 bit entropy (encrypted) that you can encode using BIP39 method to get a valid BIP39 seed phrase.

This way not only the encrypted result will have a checksum and look like any other BIP39 mnemonic but also your encryption key isn't some Base64 string hard to read/write (AAwCnwGIAe0EWA......). The key would also be a valid BIP39 seed phrase that is easy to read/write.

[larry_vw_1955]

Another detail to be noted is that this encryption method (one-time-pad) is already old, as it was used in the Second World War and the Cold War to exchange confidential information and is considered an encryption method as one of the impossible to use be broken by brute force.

the whole thing seems reasonable on the surface kind of like a bip38 for mnemonic seed phrases. but with this thing, you don't get to choose your "passphrase", it's just auto generated so it has no meaning to the end user. completely unintelligible.

with that said who is going to trust some piece of software that isn't even being maintained anymore that hardly anyone has ever heard of unless they have some way of verifying it works correctly?

This looks like a cool attempt but it suffers from a common issue: lack of reviews.
That makes it less safe to use. For example you need to know at least two basic things before you use something like this; (1) whether it generates the encryption key using a strong random generator or does it have flaws (2) whether the implementation of the algorithm has any bugs that could lead to losses.

exactly.

as an alternative one could just AES-256 encrypt their mnemonic seed phrase in a text file.

The first weirdness here is that they could just generate another BIP39 seed with the same word count and use that as the encryption key (ie. generate a 128 bit entropy, append the checksum and encode it using the word list). Instead of generating multiple integers below 2048!

i think i remember having or being part of a conversation about this in the past. let M1 be the original seed phrase, M2 be the encrypting seed phrase. Both BIP39 compliant being independent of one another M2 being chosen at random of course. Then let M3= M1+M2 mod 2048 for each word. Then you store M3 out in the open anywhere you like. M2 gets stored in secret somewhere. You recover by doing M1=M3-M2 mod 2048 very simple. No need for any python software or anything. But the burden is that you have to store 2 things rather than one. Even if one of them doesn't need to be private, it still adds to the storage burden. And adds complexity to the situation obviously. But the recovery process can be done by hand. without a computer.

[Yamane_Keto]

The code has not been updated for 6 years. The description to solve the problem is to have the OTP key and seed mnemonic stored separately. Instead of this case, there are more reliable options, such as using a 2-by-3 multi-signature wallet, which requires two signatures to broadcast the transaction, which gives us more diverse options than the OTP key and seed.

[NotATether]

There is one problem with using this method and that it requires you to go to a computer and decrypt the encrypted seed so that you can reveal the OTP secret key.

A strong, robust backup solution should not require you to use specialized decryption tools. It should be intuitive for all Bitcoin wallets like the way the current procedure is very easy to memorize and understand.

[Forsyth Jones]

The first weirdness here is that they could just generate another BIP39 seed with the same word count and use that as the encryption key (ie. generate a 128 bit entropy, append the checksum and encode it using the word list). Instead of generating multiple integers below 2048!

I think I get it what you mean, the code could simply generate an encrypted mnemonic code, but with a valid BIP-39 checksum and this could be used as a decoy wallet if someone found it, but would that really be possible?

i think i remember having or being part of a conversation about this in the past. let M1 be the original seed phrase, M2 be the encrypting seed phrase. Both BIP39 compliant being independent of one another M2 being chosen at random of course. Then let M3= M1+M2 mod 2048 for each word. Then you store M3 out in the open anywhere you like. M2 gets stored in secret somewhere. You recover by doing M1=M3-M2 mod 2048 very simple. No need for any python software or anything. But the burden is that you have to store 2 things rather than one. Even if one of them doesn't need to be private, it still adds to the storage burden. And adds complexity to the situation obviously. But the recovery process can be done by hand. without a computer.

Interesting, the dev of this method commented this, he has an account here at btctalk, could we convince him, consult him to see if the code is OK even after 6 years? Or if he could improve the code to generate 12/24 word seeds with a valid checksum?

He already created a topic talking about it several years ago, but it didn't have much relevance

There is one problem with using this method and that it requires you to go to a computer and decrypt the encrypted seed so that you can reveal the OTP secret key.

A strong, robust backup solution should not require you to use specialized decryption tools. It should be intuitive for all Bitcoin wallets like the way the current procedure is very easy to memorize and understand.

However, this is the intention, to add an extra layer of security to obtain the information necessary to reconstruct the wallet. Also, you can save the OTP-key offline if you want, similar to BIP-39 passphrase.
As long as the recovery method is done on an air-gapped computer I don't see any problems.

Furthermore, several other methods and even traditional ones such as multisig require the use of an offline computer to sign transaction and then transmit it to a PC connected to the network.

I don't know about you guys, but I found this method to be the most interesting I've ever seen and it deserves attention, as it meets my levels of paranoia, which I'm sure can be improved. Of course at the moment I wouldn't use it for my real seeds or main wallets. This could be added into advanced wallets like electrum as an extension.

I'd not use this backup method at the moment unless for testing purposes, as I have been using it for over 1 month testing almost every day and it has not had any failures.

I think BIP-85 is the most mature method for plausible negations for creating child seeds, it can create new seeds based on its parent seed and if it adds passphrase, it creates a child seed based on its parent seed + passphrase (if any), so you must have both to recover... the difference between the BIP-85 and this One Time Pad method is that the BIP-85 creates 12-word sentences with valid checksums!

[larry_vw_1955]

Or if he could improve the code to generate 12/24 word seeds with a valid checksum?

i'd say its very doubtful he would do that since he already addressed that issue in his github page. and just think about it. how would that even be possible? unless your encryption mechanism was homomorphic in the sense that CS(M1)+CS(M2)=CS(M1+M2).

I think BIP-85 is the most mature method for plausible negations for creating child seeds, it can create new seeds based on its parent seed and if it adds passphrase, it creates a child seed based on its parent seed + passphrase (if any), so you must have both to recover... the difference between the BIP-85 and this One Time Pad method is that the BIP-85 creates 12-word sentences with valid checksums!

for plausible deniability, the bip85 method seems best. plus, you can generate an arbitrary number of new mnemonic phrases not just one. i dont see any benefit this OTP tool has over bip85.

[pooya87]

The first weirdness here is that they could just generate another BIP39 seed with the same word count and use that as the encryption key (ie. generate a 128 bit entropy, append the checksum and encode it using the word list). Instead of generating multiple integers below 2048!

I think I get it what you mean, the code could simply generate an encrypted mnemonic code, but with a valid BIP-39 checksum and this could be used as a decoy wallet if someone found it, but would that really be possible?

It is very easy to implement, generate and use. It would also provide the required plausible deniability. The user could even send a small amount of coins to the "decoy" wallet to make it even more believable.
The encrypted mnemonic being a valid one itself means it can be imported in any wallet without needing extra work.