Using BIP38 to encrypt BIP39 seed phrase

[LoyceV]

I've had the idea for years, and can now complete it thanks to tremendous help from WanderingPhilospher in finding vanity addresses.

BIP38 encryption
Ever since I read I'm BIP38 curious, please help me out!, I've been impressed by BIP38 encryption. That topic showed that $1000 wasn't enough to crack password "zLwMiR" in 2 years, even after several hints. It's just too expensive in terms of computing power to brute-force even such a simple password.

Encrypting seed words
Ever since I've used my first seed word phrase, I felt unconfortable with the balance between keeping the seed secure, and making sure I don't lose access myself. It always feels like a compromise.

So, how about combining those two?

BIP38 meets BIP39
Here's the idea: BIP39 uses 2048 words. In loyce.club/other/keys.txt (which can be copied onto your air-gapped computer), you'll find an uncompressed Legacy Bitcoin address for each of the BIP39 words. Each Bitcoin address starts with a word, separated from the rest of the address by a number.
Example:
abandon: 1AbANDon25kw25M4ioLdPfLxZ1FCwzF8DY 5JDY3hzX2GnBbbExHaXjnbsjoPeFBQko9WxtaTGMi2GhYRBjtsb
If you encrypt this private key, you're encrypting the word "abandon".

Why?
I like using basic tools that have been around for a very long time. Both BIP38 and BIP39 are quite intuitive, both can easily be handled on an air-gapped computer that will never go online again, both are suppored by multiple wallets, and both can easily be verified from scratch before funding any of the addresses it creates. This is a lot of work, but I don't mind as this gives me long-term peace of mind and I don't have to do this often. I don't mind that it takes me a few hours to do this properly.

Example
IanColeman's site gave me this mnemonic:

Code:

before project cheese slice spin unaware cupboard sail job wine neck switch

That gives the following words from my list:

Code:

1. before: 1before1qvdDNyAv5c6SE9Wxo1mvYNCnt 5KDetmpXg2o8yKJ346wXeUMHQ8TkYP4mCQhNfQHdv7gyFydT6AV
2. project: 1ProJECT1WAW56GDMEGB86oUdxxubip3rA 5K43d9P5znTNvaq1KcUDiDyXBa8XZz5fE1fHSN38aA3KmARxyzj
3. cheese: 1cheese2ioSZaPu2NKmsGDwwbuAJuXs39 5JaokRJPCeohcXZSpMkXNhqcmdMy2BGQKakaV9N8AjKHZyWrqbf
4. slice: 1sLice155tu2NPm5JJCdymeDpRJ2yX7EA 5JNeo3CGzUKKJmTaBXcrJFWLBFDrZU8BXH4FqtKR4mSyzErgTpm
5. spin: 1spin12DRzTjbHHAnzDkKXqyUAtQSnfTX 5JPstBYY2B7ftPFdtXvevFaTV7wsncYprmYUSkTRvABeZGd8yDV
6. unaware: 1unawaRe2FpQDpas21ohbj82TzQmzxHbF 5KKfkhsuPHgMwAAvpMdU1VC5tLyHsyYfU5YpkZ1SMELV2gxsZgg
7. cupboard: 1CuPBoArd8xGjvMeRT9nm2iUzuEUwn8aam 5KhgsXPt8NzR4nYLYd3TFLd5zPms1PcPf2RhNDnGCQbaSM44GKJ
8. sail: 1saiL116KGiQ5kNhZEFJ2RbrBKWV88nkR 5KYNS52oGMg7u3u8puKLyzLjEJD2jcYTbfxCEp6hNBvYK9AbA1G
9. job: 1job112QVAsJKD4dYP9qtdK5DhUxmgzdi 5KBZyvXfAZSNsJQMRcgtW6iBXasZ5Gq5ubLYWsJcHE5LfF9bxxK
10. wine: 1wine11qzih8Xr1VV2sHTQyswiV8XMfk5 5KWss4Ug2nxWZQMykJSVVyFoKGLA5RYXCXgXRtUNEG9ADoJL39b
11. neck: 1neck13UY3AvVqtXTtf6P1pgGJMEkbmbH 5K4ruwwqbFQRMcUFJdLH89m4dGBC8d3K7uDU5iHHQNATUdPhJ12
12. switch: 1switch1RTJJcqv87RtbQf7gdEBf126rA 5HqmuHdJ6yKyx5cH6HF7ox44K9wpALGZerAfGZbQKDaQhCWsrGm

For this proof of concept, I'll use "LoyceV" as (very weak) password:

Code:

 1. 6PRQduYHf1fXycTTesCduex5usaUisZS4FJmyDeoXkpAcPHpxUmMCSRnmm
 2. 6PRQAmpv9nUVpJiRwrnwETPwYQkY6BDa3KizvJ2dcmhsH38niXPwoV8ViW
 3. 6PRQUgLQeBWxkPeP9rAvvdnzMHmTzmynxbNPiJVtdA4gm3bse9asEpH5DF
 4. 6PRQafe1PJ7BafAgygGgKoMbysFrEhwFk7zh5RypMxsk4gTmNDcUo3KRz7
 5. 6PRReFAEdcq3NwLjTWPAHQ3va7MFXpNKxsdtn1KPrkxFq1VeChKw8LzWR4
 6. 6PRPNeeWZSUyc9q1V7J72ypxVT5rsRiAfV6Ls2Vuq6scm87NyVaqgkZ52W
 7. 6PRSKtsXFuE4aTnZpmZVJPpxw5eWvZKMbEUoCSBKtoZMus2GVvTgkwBJZ9
 8. 6PRVnqFocoHiFrE4xjDxdfXjeYq7DwbGrtpyJ4iuWg2BtjY4GFvY54UgGa
 9. 6PRKGSWPYnVkrJckTHsfzoWg8ucTmyVnLihF6SnVrdovvMaiFnjJgemLWc
10. 6PRR7dstzrLvAATLKTdcNeWiMDAc7FjExX5YLaWaVFw6P5DnL8soLDtKD5
11. 6PRNmmRss6wScXikeyapkkprN1yoGH7eWmMiiTm9Q5F7kXsM5b3Uf8pkG7
12. 6PRLka4Azk4z4K9mE4o8sSjjRwBcESXLznktbe3j9b2BVRgVgSyxTvWEB8

Printing the above would be my backup.

How?
Start with a proper air-gapped offline system. Any old laptop with 8 GB RAM should do. If you don't have one, you can probably find a second hand laptop for less than the price of a decent new hardware wallet. Unplug your ethernet cable, close the curtains. If you're truely paranoid, you can physically remove all hard drives and Wireless modules.
Get a Linux LIVE DVD, use Ubuntu, Knoppix or Tails for instance. I prefer DVD over USB so I'm sure nothing gets saved. I use an exteral DVD drive with a Knoppix DVD with this boot-option:

Code:

knoppix64 toram

After loading with this option, the DVD drive can be removed.

Hardware
You'll also need a printer. Not wireless, but with a good old-fashioned cable. I like cheap old LaserJets. If it's too new, chances are it's not supported yet by your Linux LIVE DVD. Test it before you continue.

Software
Use an USB stick (or just burn another DVD) to copy bitaddress.org (look for the Github link), Ian Coleman's Mnemonic Code Converter and keys.txt to your air-gapped system. Use Tor Browser while downloading for improved privacy. I haven't tested command line software for BIP38 encryption and decryption yet. This can speed up the process, but for this post I'll stick to the basic tools.
Open "Bitaddress" in Firefox, and go to Wallet Details. Depending on your Live Linux you may need to enable scripts to run in the browser. Enter the private key, tick "BIP38 Encrypt?", and enter the passphrase. Encryption takes a while (which is the reason we're doing this).
It's up to you if you want to use different passwords for each seed word, but it's probably safer to use just one. If you want to make it more difficult, just make it longer.
Scroll down to get the BIP38 encrypted private key (starting with 6PR).

Check if the private key produces the correct seed word. If there's a mistake in my keys-list, let me know.
Depending on which Linux DVD you used, you'll probably find LibreOffice or at least AbiWord. Use this to temporarily store the BIP38 encrypted seed words. Add numbers for your own convenience. Switch the page orientation to landscape, choose a fixed width font, and make the font large enough to fill the entire page with keys (a small font makes it difficult to distinguish the characters in for instance 8BB88B8BB8B, S55SS5S5S5 or KXXKKXKKXK).
Print it, print it again, and laminate it. Store safely.

Don't mess up when you're handling seed phrase and creating backups for your future wealth. Make enough backups!

Check, double check
And check again! Better safe than sorry. Verify to make sure you can restore your seed phrase from your backup from scratch (so on a freshly rebooted air-gapped computer).
Take the time to TYPE all of the encrypted keys into an air-gapped computer to make sure you can restore your backup from your paper backup. Blind typing helps a lot.
While you're at it: this is a good moment to use your air-gapped system to verify you can use Ian Coleman's Converter to reproduce the same Bitcoin address as your wallet gives you. This should work, and by testing it before you need it you know for sure you can reproduce the keys if you ever need to.

Remember
DO NOT lose your password! As the BIP38 curious-topic proves, you won't be able to brute-force it (which, after all, is the reason for using encryption). It may be good to keep another backup anyway, for instance by stamping your seed phrase into metal washers. This allows you to keep backups for the same seed on different locations with different threat-levels.

Why not just extend the seed phrase with a passphrase?
"Just" a passphrase (also called 13^th/25^th word) doesn't add very heavy encryption in case someone finds your seed word backup. Besides, you can still add a passphrase to your BIP38 encrypted seed phrase.

Work in progress
Let me know if I missed anything, and I'll add it to this short guide. It's probably not very fool-proof yet, but fools people who don't understand what they're doing shouldn't be handling private keys anyway

No spam please.
Self-moderated against spam. Discussion and questions are welcome.

Disclaimer
I'd hope I wouldn't have to tell anyone not to fund any of the addresses in my keys-list, but I'll do it anyway: if you fund them, someone will take your money. Probably within seconds.

[Charles-Tim]

Hope this is not kind of complex? Do not mind me, I think it is kind of complex for me. But maybe not complex for other people. Also it is perfect.

Why not just extend the seed phrase with a passphrase?
"Just" a passphrase (also called 13^th/25^th word) doesn't add very heavy encryption in case someone finds your seed word backup. Besides, you can still add a passphrase to your BIP38 encrypted seed phrase.

The simple method I have is seed phrase and passphrase.

What if the addresses without passphrase are funded with small amount while the passphrase ones are funded with higher amount of money.

The last passphrase I have for my seed phrase contains at least 30 characters with upper cases, lower cases, numbers and two other characters. Can that be easy to decrypt?

[pooya87]

Have you checked the algorithm with anyone who understands cryptography?

I'm not the one who understands it but I have a bad feeling about reusing the same password for same AES encryption using ECB mode 12 times. They say ECB mode is considered insecure for encrypting multiple blocks with the same key.

Another issues is the plaintext that is being encrypted. The 2048 keys that are encrypted may introduce another vulnerability in the algorithm. Keep in mind that in BIP38 the plaintext is the private key which is also unknown but here what you encrypt is known.

[LoyceV]

Have you checked the algorithm with anyone who understands cryptography?

No.

I'm not the one who understands it but I have a bad feeling about reusing the same password for same AES encryption using ECB mode 12 times. They say ECB mode is considered insecure for encrypting multiple blocks with the same key.

I thought about this, but kinda dismissed it. Your post now makes me more concerned I might have missed something here.

Another issues is the plaintext that is being encrypted. The 2048 keys that are encrypted may introduce another vulnerability in the algorithm. Keep in mind that in BIP38 the plaintext is the private key which is also unknown but here what you encrypt is known.

Also a good point. Maybe @Coding Enthusiast can say something about it, since he's built BIP38 recovery into FinderOuter.

[Forsyth Jones]

Great topic, Loyce! Another idea would be to produce encrypted QR codes (from the encrypted backup, i.e. all words encrypted with BIP38!).

Have you checked the algorithm with anyone who understands cryptography?

I'm not the one who understands it but I have a bad feeling about reusing the same password for same AES encryption using ECB mode 12 times. They say ECB mode is considered insecure for encrypting multiple blocks with the same key.

Another issues is the plaintext that is being encrypted. The 2048 keys that are encrypted may introduce another vulnerability in the algorithm. Keep in mind that in BIP38 the plaintext is the private key which is also unknown but here what you encrypt is known.

You raised a valid point. While reading the OP, I was also thinking about this problem. The biggest risk here is that WIF keys have a predictable format, and if some idiot chooses a weak password, brute force attacks become more viable. Since WIF keys have a predictable list of private keys that LoyceV made publicly accessible, attackers can identify encryption patterns more easily.

However, I still consider the method secure, as long as the passphrase for BIP38 used follows good security practices and isn't breakable. We know that BIP-38 encryption has proven to be secure and unbreakable over time (as long as it's applied with a strong passphrase), but we still don’t know if there are any vulnerabilities when mixing BIP39 with BIP38. It would be interesting to hear the opinion of someone specialized in cryptography on this method.

Another alternative would be the BIP-85 method, originally known for "protecting all your seeds with just one backup." Each index in BIP-85 always generates the same derived seed, making managing multiple wallets more secure and practical. Something that few people know is that adding a BIP39 passphrase to BIP85 completely changes the derived seeds, which can add an extra layer of protection... and you are free to add another BIP39 passphrase to the derived seed, but it gets more complex since there are multiple layers of encryption, and not everyone can manage this process, so it depends on your threat model.

Why not just extend the seed phrase with a passphrase?
"Just" a passphrase (also called 13^th/25^th word) doesn't add very heavy encryption in case someone finds your seed word backup. Besides, you can still add a passphrase to your BIP38 encrypted seed phrase.

Is the BIP39 passphrase strong enough to protect "hidden wallets" from a seed phrase?

Additionally, there is the XOR method, where a cryptographic key acts as a kind of password/passphrase, generating a new seed phrase with completely different words that have no cryptographic relation to the original seed phrase. Unlike the BIP39 passphrase, which modifies the entire wallet structure by altering the chaincode and extended private key, the XOR method simply adds a mask to the original seed phrase. What do you all think of this method?

I covered these methods in the following topics:

How to backup multiple seeds derived from one: BIP-85

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

Original xor method: https://seedxor.com/

It would be great to hear the opinion of someone with advanced cryptographic knowledge to assess the security of these approaches. Although I have a lot of confidence in BIP85 combined with a passphrase, it’s always good to test the robustness of these methods against more sophisticated attacks.

[satscraper]

I prefer to encrypt my SEED phrase with ed25519 pgp key hold on   hardware  dongle ^{Yubikey 5} which may be cloned as much times as you like.

Cloned dongles are PIN-protected, ^{allowing only two incorrect PIN attempts}, which eliminates the need for me to store my encryption entity elsewhere.

I am so confident in my SEED protection that I have spread my SEED literally all over the world openly keeping it at my relatives and friends.

P.S. Bip38 encryption implies the strong relevant password ^{nothing can be compared with ed25519-based-one} and the need to keep this password safely. I would not use BIP38 as involved  safeguarding scheme looks for me  like the serpent devouring-its-tail.
.

[ABCbits]

Cool idea, but i'd rather use openssl which are more popular and offer better flexibility (you can choose encoding and encryption type). An example, https://jameshfisher.com/2017/03/09/openssl-enc/.

I'm not the one who understands it but I have a bad feeling about reusing the same password for same AES encryption using ECB mode 12 times. They say ECB mode is considered insecure for encrypting multiple blocks with the same key.

I did quick research and it's worse than i expected, see https://crypto.stackexchange.com/a/20946.

[apogio]

Cool idea, but i'd rather use openssl which are more popular and offer better flexibility (you can choose encoding and encryption type). An example, https://jameshfisher.com/2017/03/09/openssl-enc/.

Surprisingly openssl uses a deprecated key derivation method for encoding (password based encryption).

If you try to run:

Code:

$ openssl enc -k secretpassword123 -aes256 -base64 -e -in plain.txt -out cipher.txt

it will prompt you to use -pbkdf.

Probably in order to delay possible brute-force attacks.

[LoyceV]

However, I still consider the method secure, as long as the passphrase for BIP38 used follows good security practices and isn't breakable.

That was my assumption too, but as pooya87 pointed out, it's only an assumption. On the other hand, this isn't meant to publish online, it's meant for offline storage and an attacker first has to gain physical access. Then, encryption for sure is more secure than no encryption.

It would be interesting to hear the opinion of someone specialized in cryptography on this method.

I don't know any cryptography experts.

Is the BIP39 passphrase strong enough to protect "hidden wallets" from a seed phrase?

I think it uses less heavy encryption than BIP38, but a long difficult password should be secure.

I prefer to encrypt my SEED phrase with ed25519 pgp key hold on   hardware  dongle ^{Yubikey 5} which may be cloned as much times as you like.

A hardware dongle still feels like a black box to me, and I wouldn't feel comfortable if I can't reproduce it from scratch if I lose or break all my dongles.

Cool idea, but i'd rather use openssl which are more popular and offer better flexibility (you can choose encoding and encryption
I did quick research and it's worse than i expected, see https://crypto.stackexchange.com/a/20946.

I read it, but don't really understand what I'm reading. So I can't tell how much of this applies to BIP38.

Code:

$ openssl enc -k LoyceV -aes256 -base64 -e -in plain.txt -out cipher.txt

That would turn my Example into this:

Code:

U2FsdGVkX1/DP8w0aAG6fNTIHBqGwcz5Qt7ZV4syJCnFpQ0uSO2TYU0J8DU0l4iE
J458guMfwu+M9bS9z5+SMZnDipL9g3/+X8DOhk4k9JdXb7bms0ObXt6IJN1CvXg6

It's still plain text, so it can be printed. But it's much lighter encryption than BIP38: it takes a fraction of a second to decode, which makes brute-forcing easier.

[apogio]

Is the BIP39 passphrase strong enough to protect "hidden wallets" from a seed phrase?

I think it uses less heavy encryption than BIP38, but a long difficult password should be secure.

That's a very common misconception, so allow me please to clarify a few things.

BIP39 is nothing more than a mechanism to translate entropy into an easy to read format.

This entropy (normally 128 - 256 bits) that I am referring to is later used to derive a longer (512-bit) seed.

You are getting the longer seed using a key-stretching function which is called PBKDF2. It's literally a stretching function.

PKBDF2 is primarily used because it's brute-force resilient and secondarily because it allows the use of a salt.

PBKDF2 takes two arguments as input: the initial entropy and a salt.

The salt is composed of the string constant "mnemonic" + an optional passphrase.

As such, it's not an encryption mechanism, but rather a seed extension mechanism. The passphrase doesn't act as password, but it literally adds more bits to the initial entropy before it's being used in the PKBDF2 function.

Finally, a normal question would be "how is the final seed always 512 bits long"? It's because PBKDF2 stretches the input with 2048 rounds of HMAC-SHA512 function.


*Source: bitcoinbook by Andreas Antonopoulos

Is the BIP39 passphrase strong enough to protect "hidden wallets" from a seed phrase?

Much more than you can imagine. If the passphrase is produced by a good entropy source, on an offline device, then it's incredibly secure and strong.

Fire up any terminal on Linux and put this command:

Code:

xxd -u -l 16 -p /dev/urandom

sample output:

Code:

FC1DA399745A1B9289C35ED9DEF1149B

Is this secure? It's composed of 32 hexadecimal characters.

The entropy (in bits) is:

ln(16^32)/ln(2) = 128 bits.

Super strong, if you just take into consideration that the security of any private key in bitcoin is 128 bits.


Final thought, as much as I love experimenting, I reckon BIP38 encryption was chosen primarily to be brute-force "safe". It's because average users wouldn't put secure passwords for BIP38.

[LoyceV]

Is the BIP39 passphrase strong enough to protect "hidden wallets" from a seed phrase?

I think it uses less heavy encryption than BIP38, but a long difficult password should be secure.

That's a very common misconception, so allow me please to clarify a few things.
~
As such, it's not an encryption mechanism, but rather a seed extension mechanism. The passphrase doesn't act as password, but it literally adds more bits to the initial entropy before it's being used in the PKBDF2 function.

All true, but the end-result is the same: you'll need to know the password to access the funds. And if you don't know it, it's less "heavy" to brute-force.

sample output:

Code:

FC1DA399745A1B9289C35ED9DEF1149B

Is this secure? It's composed of 32 hexadecimal characters.
~
Super strong, if you just take into consideration that the security of any private key in bitcoin is 128 bits.

I'm trying to find a balance between "I can remember it" and "it can't easily be brute-forced". If I use 32 random characters, I can't remember it (for years).

Final thought, as much as I love experimenting, I reckon BIP38 encryption was chosen primarily to be brute-force "safe". It's because average users wouldn't put secure passwords for BIP38.

That's why I like it. I can only remember so many very complicated passwords.

I'm considering posting an encrypted seedphrase online. Not with a lot of funds, but enough for this scenario where I want to make a small payment and all I have is an internet connection.

[apogio]

I'm trying to find a balance between "I can remember it" and "it can't easily be brute-forced". If I use 32 random characters, I can't remember it (for years).

Although many people dislike what I 'll say, a passphrase should be backed up in a separate location with the seed phrase and it must be difficult, otherwise it's not worth the effort.

I don't like passphrases to be honest...

I prefer BIP38 passwords over BIP39 passphrases because they are more intuitive than a passphrase. If you try to access a BIP38 encrypted private key, you won't be able to unlock it without the correct password and it should hint you about it. With a passphrase you will create a different wallet which will be empty and perhaps the average user may feel frustrated about it.

I prefer multi-sig over passphrases because it allows you to maintain full separation of the of the necessary equipment to sign a tx. With passphrases you need to bring the passphrase and the seed phrase together, whereas with multi-sig you can sign in Japan and then sign in Nigeria without ever bringing the cosigners together.

[LoyceV]

Although many people dislike what I 'll say, a passphrase should be backed up in a separate location with the seed phrase

I'd say it: "it depends". If you use extend your seed phrase for plausible deniability, you should use different backup locations.

I don't like passphrases to be honest...

Exactly. That's how you work on your plausible deniability

I prefer BIP38 passwords over BIP39 passphrases because they are more intuitive than a passphrase. If you try to access a BIP38 encrypted private key, you won't be able to unlock it without the correct password and it should hint you about it. With a passphrase you will create a different wallet which will be empty and perhaps the average user may feel frustrated about it.

I prefer multi-sig over passphrases because it allows you to maintain full separation of the of the necessary equipment to sign a tx. With passphrases you need to bring the passphrase and the seed phrase together, whereas with multi-sig you can sign in Japan and then sign in Nigeria without ever bringing the cosigners together.

It's part of the beauty of crypto: different ways to do things, depending on your use case

[Forsyth Jones]

Although many people dislike what I 'll say, a passphrase should be backed up in a separate location with the seed phrase and it must be difficult, otherwise it's not worth the effort.

I don't like passphrases to be honest...

I prefer BIP38 passwords over BIP39 passphrases because they are more intuitive than a passphrase. If you try to access a BIP38 encrypted private key, you won't be able to unlock it without the correct password and it should hint you about it. With a passphrase you will create a different wallet which will be empty and perhaps the average user may feel frustrated about it.

I prefer multi-sig over passphrases because it allows you to maintain full separation of the of the necessary equipment to sign a tx. With passphrases you need to bring the passphrase and the seed phrase together, whereas with multi-sig you can sign in Japan and then sign in Nigeria without ever bringing the cosigners together.

But that is the original purpose of BIP39 passphrases: to create infinite wallet possibilities by extending the original mnemonic through an encryption salt, as you correctly pointed out.

Unfortunately the average user doesn't fully grasp encryption. When they venture into this, they often lose passphrases, confuse passphrases with wallet encryption passwords, and fall victim to phishing scams by entering their seed phrases.

This feature isn't designed for newbies or inexperienced users; it should be used by people who, before attempting anything, thoroughly research the topic from reliable, specialized sources.

BIP39 passphrases aren't an encryption feature.... they're a plausible deniability feature.

I'm trying to find a balance between "I can remember it" and "it can't easily be brute-forced". If I use 32 random characters, I can't remember it (for years).

In this case, it would be better to use passphrases (adding random words instead of complex passwords), typically composed of 6 to 8 words. This is more effective than using a set of 32 complex characters that are hard to memorize. Depending on the length of the passphrase used, it can offer the same level of security (in bits) as a complex, random password.

If you don't want to use password managers (like keepass), which may or may not be connected to an online computer (though it is possible to use keepass in an air-gapped environment to create passphrases and complex passwords, and the encrypted file with your keepass master password can be stored on a USB drive or other removable media to keep it offline). With or without the help of an offline password manager, the best alternative is to use passphrases instead of complex passwords if you don’t feel comfortable using random passwords and don’t trust your long-term memory, as they are easier to remember and offer a comparable level of security.

[ABCbits]

Cool idea, but i'd rather use openssl which are more popular and offer better flexibility (you can choose encoding and encryption
I did quick research and it's worse than i expected, see https://crypto.stackexchange.com/a/20946.

I read it, but don't really understand what I'm reading. So I can't tell how much of this applies to BIP38.

I barely understand the implication towards BIP 38, but it's enough to reconsider different option.

Code:

$ openssl enc -k LoyceV -aes256 -base64 -e -in plain.txt -out cipher.txt

That would turn my Example into this:

Code:

U2FsdGVkX1/DP8w0aAG6fNTIHBqGwcz5Qt7ZV4syJCnFpQ0uSO2TYU0J8DU0l4iE
J458guMfwu+M9bS9z5+SMZnDipL9g3/+X8DOhk4k9JdXb7bms0ObXt6IJN1CvXg6

It's still plain text, so it can be printed. But it's much lighter encryption than BIP38: it takes a fraction of a second to decode, which makes brute-forcing easier.

You could try adding -pbkdf2 and -iter TOTAL_ITER together, although it means you need to remember/write down total iteration.

[LoyceV]

You could try adding -pbkdf2 and -iter TOTAL_ITER together, although it means you need to remember/write means total iteration.

That's not bad at all Writing down "10 million times" or just the entire decrypt-command isn't a problem:

Code:

openssl enc -k LoyceV -aes256 -base64 -pbkdf2 -iter 10000000 -e -in plain.txt -out cipher.txt #encrypt
cat cipher.txt
U2FsdGVkX18wCeQDZDN529q/C9AsHrxcjFdX2RMhdWMfNs3ySbN1pq95vBJGKoMq
bH9JhocEQzrhn9crJsj3EdKIDzfAceE/wHJFnY0L3zvvVhI6ujVpmIXQWkFAGKbk

And:

Code:

openssl enc -k <passphrasehere> -aes256 -base64 -pbkdf2 -iter 10000000 -d -in cipher.txt -out plain_again.txt #decrypt
cat plain_again.txt
before project cheese slice spin unaware cupboard sail job wine neck switch

This takes long enough to discourage anyone from trying a billion different password combinations.

[apogio]

That's not bad at all Writing down "10 million times" or just the entire decrypt-command isn't a problem:

Code:

openssl enc -k LoyceV -aes256 -base64 -pbkdf2 -iter 10000000 -e -in plain.txt -out cipher.txt #encrypt
cat cipher.txt
U2FsdGVkX18wCeQDZDN529q/C9AsHrxcjFdX2RMhdWMfNs3ySbN1pq95vBJGKoMq
bH9JhocEQzrhn9crJsj3EdKIDzfAceE/wHJFnY0L3zvvVhI6ujVpmIXQWkFAGKbk

Are you going to save this? I mean, is it really easy to back it up? It looks intimidating to me.

[Forsyth Jones]

Are you going to save this? I mean, is it really easy to back it up? It looks intimidating to me.

It would be better to save it as an encrypted file (cipher.txt) and keep it in safe places, such as spread across pen drives, microSD cards, CDs, etc.

It's not worth going to all the trouble of writing it down on paper.

Just like encrypted .gpg files or any other cipher methods, the files are kept saved in different places.

Regarding ease of use, it's better to write a step-by-step guide for the commands to keep a record of and use in case of recovery.

It's an interesting backup option, although i prefer more readable things with similar security.

[apogio]

It would be better to save it as an encrypted file (cipher.txt) and keep it in safe places, such as spread across pen drives, microSD cards, CDs, etc.

It's not worth going to all the trouble of writing it down on paper.

Just like encrypted .gpg files or any other cipher methods, the files are kept saved in different places.

Yeah, that's essentially the method I 've suggested in my BRAIN21 paper wallet generator.
If you skip the latest feature with the actual paper wallet generation (the 2 QR codes), you will see that my program automatically asks for a password and saves the encrypted keys on a safe directory.
You can then take the keys and save them digitally.
My main reason for not using my own method, is that I generally dislike keeping digital backups. There are numerous times when things got out of hand, even with "reputable" bitcoiners.

[LoyceV]

Are you going to save this? I mean, is it really easy to back it up? It looks intimidating to me.

I haven't used it in a real application yet, but it sure is on my list of options now. It's just text, what's intimidating about text?
Easy test: print it in a large enough font, and see if you can restore your addresses on a freshly rebooted Linux Live system.
I don't mind having different storage systems for different copies of the same backup.

It would be better to save it as an encrypted file (cipher.txt) and keep it in safe places, such as spread across pen drives, microSD cards, CDs, etc.
It's not worth going to all the trouble of writing it down on paper.

I trust paper a lot longer than anything electronic.

i prefer more readable things with similar security.

Ideally, the encrypted data should be converted into standard BIP39 words again, but I haven't found any (standard) way to do that.