How to convert a BIP38 key to a BIP39 word list?

[zappylappy]

A BIP39 word list is designed to allow some level of error correction on your hard copy.

So how to convert a BIP38 key to a BIP39 word list?

[o_e_l_e_o]

So how to convert a BIP38 key to a BIP39 word list?

You obviously cannot convert a BIP38 key in to a BIP39 seed phrase, but you can use the BIP39 word list plus checksum method to encode any arbitrary data, if you wish.

First, you would need to convert your BIP38 key in to hex, which should give you an 86 character number. You would then need to hash that number using SHA256, take the first 4 bits (1 character) as the checksum, and append that to the end of your number, giving you 87 characters. Then convert that 87 character hex number in to a 341 digit binary number. Split that number in to 31 groups of 11 digits, and map each of the 31 groups against the BIP39 word list.

[pooya87]

First, you would need to convert your BIP38 key in to hex, which should give you an 86 character number.

If you are talking about the result of the BIP38 encryption then it is 78 characters (39 bytes) not 43.
2 byte prefix
1 byte compressed/uncompressed flag
4 byte salt
32 byte AES result

Since this length is not among the standard lengths accepted by BIP39 standard you have to write your own code which may not be favorable. Not to mention the padding with 11 bit words could be a bit challenging. The better choice is using PGP wordlist which is more straight forward since it encodes each byte (8-bits) to a word. https://en.wikipedia.org/wiki/PGP_word_list

[NotATether]

A BIP39 word list is designed to allow some level of error correction on your hard copy.

Not precisely BIP 39 wordlists, but BIP 39 mnemonic phrases. The wordlist is just a list of 2048 arbitrary words, but the mnemonic is the one with an extra 4 bits of checksum at the end.

First, you would need to convert your BIP38 key in to hex, which should give you an 86 character number. You would then need to hash that number using SHA256, take the first 4 bits (1 character) as the checksum, and append that to the end of your number, giving you 87 characters. Then convert that 87 character hex number in to a 341 digit binary number. Split that number in to 31 groups of 11 digits, and map each of the 31 groups against the BIP39 word list.

The fact that BIP38 keys were designed with the purpose of using it in public in mind is going to make it really hard to find a bitcoin library that wipes its memory after it creates a BIP38 key, since because it's being used to derive a mnemonic phrase is now secret data.

[BrewMaster]

A BIP39 word list is designed to allow some level of error correction on your hard copy.

CMIIW, but doesn't checksum on BIP39 only act as error detection rather than both error detection and correction?

you are right. the SHA256 checksum in BIP39 only tells us that there is an error not how to fix it. the error correction is a characteristic of CRC checksums or for example the Bech32 encoding that uses error correcting code.

[o_e_l_e_o]

If you are talking about the result of the BIP38 encryption then it is 78 characters (39 bytes) not 43.

If you were to use your decryption key to convert the BIP38 key back to a WIF, and then convert that in to hex, then yes, you are right. But if you want to simply encode your encrypted BIP38 key in to a word list (perhaps to make it less error prone to write down), then doing a straight convert of the 58 character Base58 BIP38 key in to Base16 will give you 86 characters. This is what I assumed OP was asking.

[pooya87]

If you are talking about the result of the BIP38 encryption then it is 78 characters (39 bytes) not 43.

If you were to use your decryption key to convert the BIP38 key back to a WIF, and then convert that in to hex, then yes, you are right. But if you want to simply encode your encrypted BIP38 key in to a word list (perhaps to make it less error prone to write down), then doing a straight convert of the 58 character Base58 BIP38 key in to Base16 will give you 86 characters. This is what I assumed OP was asking.

Oh OK.  When I see different encodings, I always see the data part not the checksum. The BIP38 key decoded with Base58 that returns 43 bytes would already contain a 32-bit checksum in it which is what I removed to get 39 bytes of actual data.

[Saint-loup]

So how to convert a BIP38 key to a BIP39 word list?

You obviously cannot convert a BIP38 key in to a BIP39 seed phrase, but you can use the BIP39 word list plus checksum method to encode any arbitrary data, if you wish.

First, you would need to convert your BIP38 key in to hex, which should give you an 86 character number. You would then need to hash that number using SHA256, take the first 4 bits (1 character) as the checksum, and append that to the end of your number, giving you 87 characters. Then convert that 87 character hex number in to a 341 digit binary number. Split that number in to 31 groups of 11 digits, and map each of the 31 groups against the BIP39 word list.

Excuse-me but I don't understand why you are only taking 4bits for the checksum?
AFAIK BIP39 requires to take ENT/32 bits for the checksum.
An hexadecimal number worths 4bits (F=1111). So if you want to use hexadecimal numbers you need to divide the hexadecimal string by only 8 (ie 32/4).

86/8=10.75=11bits

And if you convert your hexadecimal string in bits as required by BIP39 that's also what you'll get :
86x4=344bits
344/32=10.75

First, an initial entropy of ENT bits is generated. A checksum is generated by taking the first ENT / 32 bits of its SHA256 hash.
https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki

(Besides that I don't find 86 hexadecimal characters to encode 58 characters in base 58 but only 85. Because 16⁸⁵ is already greater than 58⁵⁸.)

[o_e_l_e_o]

Excuse-me but I don't understand why you are only taking 4bits for the checksum?

This is not a true BIP39 encoding so we don't actually need to follow the standard exactly. In fact, using ENT/32 bits for the checksum is impossible since you end up with 10.75 bits as you have said.

The reason I stuck with 4 bits is because it avoids the need for padding. If you were to round up to use 11 bits of checksum, then you end up with a 348 bit number, which does not divide evenly by 11, meaning you cannot map it to the BIP39 wordlist without adding a bunch of padding zeroes. If you want more than 4 bits of checksum, then you should go for 15 instead to avoid the need for padding.

(Besides that I don't find 86 hexadecimal characters to encode 58 characters in base 58 but only 85. Because 16⁸⁵ is already greater than 58⁵⁸.)

Since BIP38 keys all start with 6P, when you convert to hex the first byte will always be 01. The leading zero is the reason for the additional character.

[NotATether]

Excuse-me but I don't understand why you are only taking 4bits for the checksum?

This is not a true BIP39 encoding so we don't actually need to follow the standard exactly. In fact, using ENT/32 bits for the checksum is impossible since you end up with 10.75 bits as you have said.

The reason I stuck with 4 bits is because it avoids the need for padding. If you were to round up to use 11 bits of checksum, then you end up with a 348 bit number, which does not divide evenly by 11, meaning you cannot map it to the BIP39 wordlist without adding a bunch of padding zeroes. If you want more than 4 bits of checksum, then you should go for 15 instead to avoid the need for padding.

But you can avoid this by only using word counts that are multiples of three right? (12, 15, 18, ...) We don't have to only use 11 bits of entropy/word and 4 bits of checksum since that only fits inside 12-word phrases perfectly without any padding.

It's pretty much a compromise between individual phrase length and the number of phrases you're weilling to generate. Since the phrases have error correction in themselves that is the checksums I'm more inclined to take smaller groups of 24-word phrases although one would still need to make 16 of these phrases.

Also since there is a byte of flags in the encrypted key there are a certain combination of phrases that will make the same BIP38 key (some flag bytes are reserved).

[o_e_l_e_o]

But you can avoid this by only using word counts that are multiples of three right? (12, 15, 18, ...)

Correct. BIP39 specifies 12, 15, 18, 21, or 24 words, which corresponds to 128 + 4, 160 + 5, 192 + 6, 224 + 7, and 256 + 8 bits of entropy + checksum, each of which is exactly divisible by 11, meaning straightforward mapping of each 11 bit segment to a word on the BIP39 word list.

We don't have to only use 11 bits of entropy/word and 4 bits of checksum since that only fits inside 12-word phrases perfectly without any padding.

Sure, you can split up your entropy any way you like. You could split in to 8 bit chunks and encode against word list of 256 words, or you split in to 15 bit chunks and encode against a word list of 32,768 words, for example. But if you want to use the BIP39 word list of 2048 words, then you need to split in to 11 bit chunks.