BIP38 python problem - page 3. | Bitcointalksearch.org

DaveF

legendary

Activity: 3458

Merit: 6231

Crypto Swap Exchange

Quote from: larry_vw_1955 on September 30, 2021, 07:26:19 AM

Quote from: pooya87 on September 27, 2021, 01:47:58 AM

1-3. You still need to know the word list but it could be changed in a way that doesn't depend on a fixed length word list like the algorithm Electrum uses
4-6. This can also be implemented but it would increase the number of words and the result will no longer resemble a normal BIP39 mnemonic.

My idea was an attempt to end up with a result that doesn't look any different from regular seed words.

I need a way to store more information than just the seed words. For each wallet, I figure I might need upwards of 1000 characters. Possibly I'd like to store multiple wallets all at once. So looking at maybe 5000 to 10000 characters. 10 kb. I need to be able to print out an encrypted image on a piece of paper. That would be my cold storage. When I'm ready to redeem, I will scan the image back in and decrypt its contents. And recover the original text file containing all my important seed phrases. I think this would be more secure than putting it on a flash drive since paper can last longer. Hundreds of years. then only problem is that you can't really use qrcodes for that. they would literally be huge.

Or i might just have a need to encrypt a text file containing 1000 private keys. That might require 2 pages.

You would not be able to use regular steganography to do that. You can't rely on most printers and scanners to be able to detect it. You would have to store the images on usb or other digital media.

Here is a basic steganography app:

https://github.com/computationalcore/cryptosteganography

Give it a try and see what you can squeeze into an image that you can scan later.

-Dave

larry_vw_1955

sr. member

Activity: 1036

Merit: 350

Quote from: pooya87 on September 27, 2021, 01:47:58 AM

1-3. You still need to know the word list but it could be changed in a way that doesn't depend on a fixed length word list like the algorithm Electrum uses
4-6. This can also be implemented but it would increase the number of words and the result will no longer resemble a normal BIP39 mnemonic.

My idea was an attempt to end up with a result that doesn't look any different from regular seed words.

I need a way to store more information than just the seed words. For each wallet, I figure I might need upwards of 1000 characters. Possibly I'd like to store multiple wallets all at once. So looking at maybe 5000 to 10000 characters. 10 kb. I need to be able to print out an encrypted image on a piece of paper. That would be my cold storage. When I'm ready to redeem, I will scan the image back in and decrypt its contents. And recover the original text file containing all my important seed phrases. I think this would be more secure than putting it on a flash drive since paper can last longer. Hundreds of years. then only problem is that you can't really use qrcodes for that. they would literally be huge.

Or i might just have a need to encrypt a text file containing 1000 private keys. That might require 2 pages.

pooya87

legendary

Activity: 3430

Merit: 10505

Quote from: larry_vw_1955 on September 27, 2021, 01:17:06 AM

It requires a fixed wordlist.

Any encoding method requires a fixed (usually hard-coded) set of "digits" and if you don't know those you won't be able to decode it. For example if you don't know base16 uses 0-9, a-f you con't decode it. For base2048 you need the digits which in case of a BIP39 mnemonic or what I explained above is the word list that would be required to decode both the mnemonic and the encrypted mnemonic alike.

Quote

i'd much prefer a solution that
1)didn't require a fixed wordlist
2)allowed for variable length mnemonics
3) but still operated by changing words in to other words
4) encodes the derivation path being used so that someone can find their money
5) encodes the particular cryptocurrency that the derivation path above refers to
6) possibly allows for encoding multiple 4/5 pairs of data so that different coins can be referenced

1-3. You still need to know the word list but it could be changed in a way that doesn't depend on a fixed length word list like the algorithm Electrum uses
4-6. This can also be implemented but it would increase the number of words and the result will no longer resemble a normal BIP39 mnemonic.

My idea was an attempt to end up with a result that doesn't look any different from regular seed words.

larry_vw_1955

sr. member

Activity: 1036

Merit: 350

Quote from: pooya87 on September 26, 2021, 05:11:08 AM

Quote from: pooya87 on August 20, 2021, 03:34:40 AM

You have a mnemonic that is n-bits (eg. 128-bits for 12 words) take those bits and encrypt them with AES256 with a key derived from a strong passphrase and a salt derived from the address (like BIP38).
Now you get 128-bits of encrypted data (encryption without IV) which you can encode to 12 words using the same BIP39 scheme. All you have to do is write down these words as if they were your mnemonic.

To import to a wallet you just decrypt these words and convert to an un-encrypted BIP39. That is decode 12 words to get the byte[], derive the AES key from the passphrase and address like above, decrypt using AES256. Now you have un-encrypted 128-bit entropy. Encode this using BIP39 scheme and you have the original words.

that's a pretty neat idea the only potential problem I see with it is, it's not very "portable". It requires a fixed wordlist. what if there is no wordlist at all? or what if the wordlist is different than the bip39 one. that means we have to store a complete copy of whatever wordlist it is we want to use and somehow the software has to be smart enough to know what wordlist we want it to use?

i'd much prefer a solution that
1)didn't require a fixed wordlist
2)allowed for variable length mnemonics
3) but still operated by changing words in to other words
4) encodes the derivation path being used so that someone can find their money
5) encodes the particular cryptocurrency that the derivation path above refers to
6) possibly allows for encoding multiple 4/5 pairs of data so that different coins can be referenced

pooya87

legendary

Activity: 3430

Merit: 10505

Quote from: larry_vw_1955 on September 26, 2021, 01:47:06 AM

any number can be encoded as a hexadecimal string. which you can think of as a text string composed of the characters 0-9,A-F. there is a 1-1 relationship between the hexadecimal text string and bitcoin private key that it represents. Or just think of 256-bit text string consisting of 0s and 1s. That's a string too. or it can be thought of as such without causing any confusion or problem.

That's true but when you enter a private key WIF (the string) it still has to be converted to bits and treated as an integer but when you enter a mnemonic (the string) is treated as a string and even decoded using UTF8 when deriving BIP32 seed from it.

Quote from: pooya87 on August 20, 2021, 03:34:40 AM

You have a mnemonic that is n-bits (eg. 128-bits for 12 words) take those bits and encrypt them with AES256 with a key derived from a strong passphrase and a salt derived from the address (like BIP38).
Now you get 128-bits of encrypted data (encryption without IV) which you can encode to 12 words using the same BIP39 scheme. All you have to do is write down these words as if they were your mnemonic.

To import to a wallet you just decrypt these words and convert to an un-encrypted BIP39. That is decode 12 words to get the byte[], derive the AES key from the passphrase and address like above, decrypt using AES256. Now you have un-encrypted 128-bit entropy. Encode this using BIP39 scheme and you have the original words.

larry_vw_1955

sr. member

Activity: 1036

Merit: 350

Quote from: pooya87 on September 25, 2021, 12:24:46 AM

A bitcoin private key is not plain text, it is technically a number and can easily be treated as a stream of bytes with fixed length (32 bytes). A mnemonic on the other hand is technically plain text even though it can be converted to a stream of bytes but it will have variable size.

any number can be encoded as a hexadecimal string. which you can think of as a text string composed of the characters 0-9,A-F. there is a 1-1 relationship between the hexadecimal text string and bitcoin private key that it represents. Or just think of 256-bit text string consisting of 0s and 1s. That's a string too. or it can be thought of as such without causing any confusion or problem.

Quote

With that said I'm all for a "standard" way of encrypting a mnemonic, I've already posted about what I think such a method could look like a couple of times on this forum.

Very good! Maybe I can locate them somehow. But you post so often that it might be kind of hard to dig them all up but it would be worth it I'm sure. Cheesy

pooya87

legendary

Activity: 3430

Merit: 10505

Quote from: larry_vw_1955 on September 24, 2021, 09:48:28 PM

Why would you need to waste time and effort creating a method to encrypt a bitcoin private key when you already have plenty of perfectly adequate (and proven) encryption systems for encrypting "plain text"?

A bitcoin private key is not plain text, it is technically a number and can easily be treated as a stream of bytes with fixed length (32 bytes). A mnemonic on the other hand is technically plain text even though it can be converted to a stream of bytes but it will have variable size.

With that said I'm all for a "standard" way of encrypting a mnemonic, I've already posted about what I think such a method could look like a couple of times on this forum.

larry_vw_1955

sr. member

Activity: 1036

Merit: 350

Quote from: HCP on September 24, 2021, 08:32:04 AM

Why would you need to waste time and effort creating a method to encrypt a seed when you already have plenty of perfectly adequate (and proven) encryption systems for encrypting "plain text"? Huh

You know that's a really silly question. Let me rephrase it slightly and maybe you can help answer it:

Why would you need to waste time and effort creating a method to encrypt a bitcoin private key when you already have plenty of perfectly adequate (and proven) encryption systems for encrypting "plain text"? Huh

HCP

legendary

Activity: 2086

Merit: 4314

Why would you need to waste time and effort creating a method to encrypt a seed when you already have plenty of perfectly adequate (and proven) encryption systems for encrypting "plain text"? Huh

As for supporting Electrum... Electrum already has perfectly functional wallet file encryption. ¯\_(ツ)_/¯

I'm not sure what it is that you're attempting to achieve here? Huh

larry_vw_1955

sr. member

Activity: 1036

Merit: 350

Quote from: n0nce on September 21, 2021, 09:24:57 PM

So BIP38 would have to be changed to not encrypt and encode a private key, but instead to encrypt and encode a seed phrase instead.

At this point the scope changes completely and will require a new BIP in my opinion.

yeah that may be true but it's still a doable thing. Not sure why it hasn't been done. other than just no one caring. one thing they wuld need to make sure though is to support electrum Grin

now that i think about it though. there's no "address" that corresponds to an hd wallet so instead of the address what would you print out? the first 10 addresses?

n0nce

hero member

Activity: 882

Merit: 5814

not your keys, not your coins!

Quote from: larry_vw_1955 on September 13, 2021, 05:15:05 AM

Quote

The thing is that wallets are always HD so there is little use for a single key encryption technique for them. However the method itself is still useful and will remain useful for paper wallet creation.

bip38 could be extended to allow for hd wallets i am sure. why they dont' do that is hard to understand. how long wold it take them to come up with that maybe 2 or 3 days tops, with lunch breaks?

The point about hardware wallets is that they don't just have 1 private key. They generate a seed phrase from which an infinite amount of private keys can be derived. So BIP38 would have to be changed to not encrypt and encode a private key, but instead to encrypt and encode a seed phrase instead.

At this point the scope changes completely and will require a new BIP in my opinion.

larry_vw_1955

sr. member

Activity: 1036

Merit: 350

Quote

The thing is that wallets are always HD so there is little use for a single key encryption technique for them. However the method itself is still useful and will remain useful for paper wallet creation.

bip38 could be extended to allow for hd wallets i am sure. why they dont' do that is hard to understand. how long wold it take them to come up with that maybe 2 or 3 days tops, with lunch breaks?

larry_vw_1955

sr. member

Activity: 1036

Merit: 350

Quote

Thanks for the correction, there are so many BIPs that i sometimes forget the correct number. Even so, BIP 38 is still most common option to encrypt private key, even bitaddress support it. I'm also not aware of other encryption standard solely for cryptocurrency private key.

Well I mean yeah, bitaddress does have a certain level of support for bip38 but in my limited testing, I found it failing for a certain test vector. But that's ok, the code that I have works for that test vector just fine. So I guess I'll stick to that.

pooya87

legendary

Activity: 3430

Merit: 10505

Quote from: ABCbits on September 05, 2021, 05:51:43 AM

Here's a hint, if they ask you to backup 12/24 words and mention it can be recovered on most wallet, most likely it use BIP 38.

I think you may be confusing BIP-38 (Passphrase-protected private key) with BIP-39 (Mnemonic code for generating deterministic keys). The former is supported by only a handful of wallets and tools while the later is supported by almost everything. OP was talking about the former.

ABCbits

legendary

Activity: 2856

Merit: 7410

Crypto Swap Exchange

Quote from: larry_vw_1955 on September 04, 2021, 08:30:07 AM

Well here's the thing. BIP38 is going away. Eventually there won't be any wallets or any software that supports it.

It's literally available on many wallet, including hardware and multi-cryptocurrency wallet. Here's a hint, if they ask you to backup 12/24 words and mention it can be recovered on most wallet, most likely it use BIP 38. There are few competitor such as Electrum Seed Version System, but still can't beat BIP 38 even though it has versioning system and better security.

Quote from: n0nce on September 04, 2021, 09:21:33 AM

Quote from: larry_vw_1955 on September 04, 2021, 08:30:07 AM

Lucky for me though I was able to implement it in python 3.7 so I can use bip38 as long as I want to unless python decides to bullshit its users again like they did with the 2 to 3 upgrade.

Off-topic but... Python didn't bullshit its users. There was a long transition period where both were supported, Python 3 brings many needed features to the table like typing and is generally the better programming language.

Maybe he's complaining about most linux distro had to drop lots of software which still depend on Python 2 or few software got discontinued since the author have no intention to convert it to Python 3.

n0nce

hero member

Activity: 882

Merit: 5814

not your keys, not your coins!

Quote from: larry_vw_1955 on September 04, 2021, 08:30:07 AM

Lucky for me though I was able to implement it in python 3.7 so I can use bip38 as long as I want to unless python decides to bullshit its users again like they did with the 2 to 3 upgrade.

Off-topic but... Python didn't bullshit its users. There was a long transition period where both were supported, Python 3 brings many needed features to the table like typing and is generally the better programming language.

pooya87

legendary

Activity: 3430

Merit: 10505

Quote from: larry_vw_1955 on September 04, 2021, 08:30:07 AM

BIP38 is going away.

No, it is not.

Quote

Eventually there won't be any wallets or any software that supports it. It never really caught on.

The thing is that wallets are always HD so there is little use for a single key encryption technique for them. However the method itself is still useful and will remain useful for paper wallet creation.

Quote

~ since all we have is a generic "protocol specification".

Which is more than enough for a developer to implement it.

Quote

The fact that you can't even find a python 3.7 implementation of it speaks volumes.

You are just not searching well enough:
A python bitcoin library:
https://github.com/1200wd/bitcoinlib/blob/c52cdfc9fe7feaedcf4dc3e43ceca4071865281b/bitcoinlib/encoding.py#L772-L845

A shitcoin wallet's library:
https://github.com/joshmcintyre/blockchainmower/blob/7457c361b5b2792e7cd3c4882713d6b71efddcda/src/electron_cash_lib/bitcoin.py#L1023

From a paper wallet builder:
https://github.com/ryanralph/DIY-Piper/blob/0df360f61707739dd7ba5b7758f79b7c8e136867/bitcoin/bip38.py#L17

A set of utilities from @darosior:
https://github.com/darosior/bitcoineasy/blob/master/bitcoineasy/bip38.py

Another paper wallet builder:
https://github.com/zobin8/PyperWallet/blob/master/pyperlib/cryptor.py

P.S. Note that I'm not endorsing any of the above links, just pointing out examples of python (mostly v3) implementation of BIP38. Aside from that there are lots of python 2 implementations that could simply be converted to python 3.

larry_vw_1955

sr. member

Activity: 1036

Merit: 350

I worked on the EC non-multiply mode. I never messed with EC multiply mode but I actually think the EC Multiply mode is the far more interesting of the two. The BIP itself is genius. Maybe a bit overly complicate for the non-multiply mode in the sense that there's probably far more simpler ways to encrypt a bitcoin private key such as just using winrar but hey...

larry_vw_1955

sr. member

Activity: 1036

Merit: 350

Quote from: n0nce on September 03, 2021, 06:18:23 PM

I would like to inform you that a BIP is a bitcoin improvement proposal, so more like a protocol specification, and does not need a reference implementation in any language, especially not in Python, since Bitcoin Core is mostly written in C and C++.
Like, do you expect for every BIP that is 'taken seriously' to have a reference implementation in all programming languages? Wink

Well here's the thing. BIP38 is going away. Eventually there won't be any wallets or any software that supports it. It never really caught on. It's kind of a shame because I do think it's a cool piece of technology but unfortunately, we've lost the knowledge on how to implement it since all we have is a generic "protocol specification". The fact that you can't even find a python 3.7 implementation of it speaks volumes. No one cares about bip38. And no one will in the future.

Lucky for me though I was able to implement it in python 3.7 so I can use bip38 as long as I want to unless python decides to bullshit its users again like they did with the 2 to 3 upgrade.

NotATether

legendary

Activity: 1568

Merit: 6660

bitcoincleanup.com / bitmixlist.org

Quote from: ?? on ??

What the quote means is that you use AES with the following settings:
key size = 256 (bit) (the derived key from scrypt)
mode = ECB (each block is encrypted individually)
IV = new byte[16] (empty initialization vector)
padding = none

Yes, those settings are correct.

The AES256Encrypt function described in BIP38 doesn't chain AES blocks together, and the IV is zeroed out before using it (it's not randomized).

Since this function transforms 16 bytes of input into 16 bytes of output, no padding is needed.

Topic: BIP38 python problem - page 3. (Read 897 times)