<p>BIP 38 is currently the ultimate form of cold storage paper wallets. If you print copies of your BIP38 QR codes corresponding to your private keys, and somebody steals a copy, you are probably not going to loose any money provided you have strong passwords.  </p>

<p>Additionally, software based wallets are starting to support the importation and sweeping of BIP38 encoded cold wallets. Any BIP 38 encoded private keys are easy to spot because the begin with "6PR".  These first three letters allow BIP standards-based wallets to recognize the private keys are AES encrypted and will prompt the user for a password to support importation or sweeping.</p>

CC BY-SA 3.0
2015-02-15T14:48:36.967Z
2015-02-15T14:48:36.967Z
skaht
<p>BIP38 <em>does</em> use AES behind the scenes.</p>

<p>This question is difficult to answer, because AES has multiple modes (ways of using it) and only some of them are secure. As Zaph noted, you also need to pick a secure key derivation function (though a single iteration of PBKDF will not suffice).</p>

<p>Instead of making your own implementation, why not use <code>gpg -c</code> or BIP38?</p>

CC BY-SA 3.0
2014-10-30T15:36:37.270Z
Thanks Nick. What I ended up doing was using OpenSSL. The random 256 bit key is derived using OpenSSL's AES256 CBC cipher. In case the user opts for a password I stretch it a million times using OpenSSL's PKCS5 standardPBKDF2_HMAC with random salt and IV.
Assaf Shomer
CC BY-SA 3.0
2014-10-30T15:48:18.367Z
@AssafShomer `random 256 bit key is derived using OpenSSL's AES256 CBC` You know that AES isn't a random number generator, right?
Nick ODell
CC BY-SA 3.0
2014-10-30T15:54:15.517Z
Of course, what i meant was
Assaf Shomer
CC BY-SA 3.0
2014-10-30T15:55:42.290Z
OpenSSL::Cipher::AES256.new(:CBC).random_key
Assaf Shomer
CC BY-SA 3.0
2014-10-30T15:57:05.420Z
Using the ruby implementation of OpenSSL. Sorry for the multiple comments, not used to enter being Post...
Assaf Shomer
CC BY-SA 3.0
2014-10-30T15:28:05.680Z
2014-10-30T15:28:05.680Z
Nick ODell
<p>See the following links for an <a href="https://bitcoinpaperwallet.com/bip38-password-encrypted-wallets/" rel="nofollow">overview</a> and for <a href="https://github.com/bitcoin/bips/blob/master/bip-0038.mediawiki" rel="nofollow">details</a>.</p>

<p><strong>Note</strong>: In short, if you do not have a strong understanding of the BIP38 encryption and decryption workflow, do not BIP38-encrypt your paper wallet. Just print your paper wallet out without encryption, and keep it safe the same way you would jewels or cash.</p>

<p>Just encrypting with AES provides excellent security but the weakness is the key which is unwieldily since it needs to be random binary data and the encrypted output which is also binary data. In order to use a passphrase as the encryption key a function such as PBKDF2 is generally used and the output can be base64 encoded to make it ASCII so it can be printed/written. Finally, unless you are a crypto domain expert do not roll-your-own security schemes, they generally will contain flaws rendering the security null.</p>

<p>Note: <a href="https://en.wikipedia.org/wiki/Scrypt" rel="nofollow">Scrypt</a> is a form of Password-Based Key Derivation Function (PBKDF2) that has increased memory requirements.</p>

<p>BIP38 encryption provides the above and some inter ability with the crypto currency eco-system.</p>

CC BY-SA 3.0
2014-04-04T13:25:12.503Z
Thank you Zaph, I understand. So here is a more specific question. I am building a simple app for cold storage of Bitcoin on an offline Raspberry Pi (coincooler.com). What I am currently doing is encrypting a comma delimited list of keys with AEScrypt. The password is a random string of length 40 on the alphabet [a-zA-Z0-9 + some extra characters]. Is there a vulnerability in that scheme?
Assaf Shomer
CC BY-SA 3.0
2014-04-04T13:56:48.113Z
When designing a security system first you must decide on the level of security needed. What level of security are you looking for? How many $ will this be protecting?  Just yourself of for public/wide distribution? What are the attacks you are protecting against? There is a large range of security, high end devices self-destruct on detection of tampering or attack. When I designed mass market security products I paid a top level security expert to vet my design and implementation. His first questions were along the line of what I asked above and more.
zaph
CC BY-SA 3.0
2014-04-03T10:55:40.913Z
2015-02-15T07:10:14.210Z
2015-02-15T07:10:14.210Z
zaph
<p>Can anyone explain what are the advantages of using BIP 38 Bitcoin wallet encryption to simply encrypting the private key with AES256?</p>

<encryption><bip38>
Comparing Bip 38 to AES256
Assaf Shomer
# Comparing Bip 38 to AES256

(Asked by: username_0 on 2014-04-03)

Can anyone explain what are the advantages of using BIP 38 Bitcoin wallet encryption to simply encrypting the private key with AES256?

**Tags:** encryption, bip38


---

## 3 answers

### Answer by username_3 on 2014-04-03. Score: 6 | Accepted answer

See the following links for an [overview](https://bitcoinpaperwallet.com/bip38-password-encrypted-wallets/) and for [details](https://github.com/bitcoin/bips/blob/master/bip-0038.mediawiki).

**Note**: In short, if you do not have a strong understanding of the BIP38 encryption and decryption workflow, do not BIP38-encrypt your paper wallet. Just print your paper wallet out without encryption, and keep it safe the same way you would jewels or cash.

Just encrypting with AES provides excellent security but the weakness is the key which is unwieldily since it needs to be random binary data and the encrypted output which is also binary data. In order to use a passphrase as the encryption key a function such as PBKDF2 is generally used and the output can be base64 encoded to make it ASCII so it can be printed/written. Finally, unless you are a crypto domain expert do not roll-your-own security schemes, they generally will contain flaws rendering the security null.

Note: [Scrypt](https://en.wikipedia.org/wiki/Scrypt) is a form of Password-Based Key Derivation Function (PBKDF2) that has increased memory requirements.

BIP38 encryption provides the above and some inter ability with the crypto currency eco-system.

> **Comments:**
> **username_0**: Thank you username_3, I understand. So here is a more specific question. I am building a simple app for cold storage of Bitcoin on an offline Raspberry Pi (coincooler.com). What I am currently doing is encrypting a comma delimited list of keys with AEScrypt. The password is a random string of length 40 on the alphabet [a-zA-Z0-9 + some extra characters]. Is there a vulnerability in that scheme?  
> **username_3**: When designing a security system first you must decide on the level of security needed. What level of security are you looking for? How many $ will this be protecting?  Just yourself of for public/wide distribution? What are the attacks you are protecting against? There is a large range of security, high end devices self-destruct on detection of tampering or attack. When I designed mass market security products I paid a top level security expert to vet my design and implementation. His first questions were along the line of what I asked above and more.  

---

### Answer by username_1 on 2015-02-15. Score: 0

BIP 38 is currently the ultimate form of cold storage paper wallets. If you print copies of your BIP38 QR codes corresponding to your private keys, and somebody steals a copy, you are probably not going to loose any money provided you have strong passwords.

Additionally, software based wallets are starting to support the importation and sweeping of BIP38 encoded cold wallets. Any BIP 38 encoded private keys are easy to spot because the begin with "6PR". These first three letters allow BIP standards-based wallets to recognize the private keys are AES encrypted and will prompt the user for a password to support importation or sweeping.


---

### Answer by username_2 on 2014-10-30. Score: 0

BIP38 *does* use AES behind the scenes.

This question is difficult to answer, because AES has multiple modes (ways of using it) and only some of them are secure. As username_3 noted, you also need to pick a secure key derivation function (though a single iteration of PBKDF will not suffice).

Instead of making your own implementation, why not use `gpg -c` or BIP38?

> **Comments:**
> **username_0**: Thanks username_2. What I ended up doing was using OpenSSL. The random 256 bit key is derived using OpenSSL's AES256 CBC cipher. In case the user opts for a password I stretch it a million times using OpenSSL's PKCS5 standardPBKDF2_HMAC with random salt and IV.  
> **username_2**: @username_0 `random 256 bit key is derived using OpenSSL's AES256 CBC` You know that AES isn't a random number generator, right?  
> **username_0**: Of course, what i meant was  
> **username_0**: OpenSSL::Cipher::AES256.new(:CBC).random_key  
> **username_0**: Using the ruby implementation of OpenSSL. Sorry for the multiple comments, not used to enter being Post...  

---

