BIP38 python problem

[larry_vw_1955]

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.

[DaveF]

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

[NotATether]

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.

You can encrypt the wallet with AES256, encode the wallet in BASE64 using some easy-to-parse computer font such as Courier New or System (they must be monospaced so they can be perfectly read again using OCR), and then print out the characters onto a large number of sheets of paper. Then you save the AES key and IV as qrcodes. Store all materials in a confidential place such as inside a safe.

When you want to access the file again, read the papers in with a scanner, strip all whitespace and then decode the AES256 with the key and IV you have independently scanned. Requires a lot of paper, but it works.

Or lobby the Electrum folks with a feature proposal to export wallet data to JSON so you have less data to print and scan.

[pooya87]

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.

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

I don't see the point in storing a lot of private keys simply because deterministic key derivation exists. You only store the seed for that KDF and then you can always derive the same exact 1000 private keys in a second whenever you want.
Even if you want multiple different wallets there are still many ways to achieve this. For example BIP32 KDF uses a derivation path that looks like m/x/y/z/... and you can change those values to get a different set of keys. Or BIP39 can add a "passphrase" to derive a different seed from the mnemonic, so same words with a different extra word (ie. the passphrase) can create different wallets.
If you don't like these algorithms you can always use any KDF you like. For example use scrypt with costParam=32,768 and a fixed salt to derive keys from an initial 128 to 256 bit random entropy.

[LoyceV]

I don't see the point in storing a lot of private keys simply because deterministic key derivation exists. You only store the seed for that KDF and then you can always derive the same exact 1000 private keys in a second whenever you want.

I can think of a reason: convenience! It's very easy to take 1 private key from cold storage, and use it to spend funds. You might even be willing to enter it into a hot wallet.
But if you have one seed that gives access to all your private keys, you'll need a cold storage setup just to spend funds from one key.

[pooya87]

I don't see the point in storing a lot of private keys simply because deterministic key derivation exists. You only store the seed for that KDF and then you can always derive the same exact 1000 private keys in a second whenever you want.

I can think of a reason: convenience! It's very easy to take 1 private key from cold storage, and use it to spend funds. You might even be willing to enter it into a hot wallet.
But if you have one seed that gives access to all your private keys, you'll need a cold storage setup just to spend funds from one key.

I could see that be useful with a handful of private keys but 1000 still doesn't make sense to me. If that many keys are being used buying a hardware wallet or setting up a cold storage (DIY) makes a lot more sense than having a "book" of private keys to spend from.

[larry_vw_1955]

You can encrypt the wallet with AES256, encode the wallet in BASE64 using some easy-to-parse computer font such as Courier New or System (they must be monospaced so they can be perfectly read again using OCR), and then print out the characters onto a large number of sheets of paper. Then you save the AES key and IV as qrcodes. Store all materials in a confidential place such as inside a safe.

That is a reasonable solution albeit a kind of expensive one in terms of materials/resources used (ink and paper and physical storage space). I think encoding into the base 64 is going to increase the filesize and increase the number of papers it takes to print the thing out. but you did say "large number of sheets of paper" and you're right about that. it's not going to give any shortcut in that area.  the other issue is there's no fault tolerance built into it. Yes presumably you would test to make sure that it scanned and decrypted fine before you put it into a confidential place (who wouldn't??) but maybe some of the characters were marginal and got corrupted over time and you would have no idea which one or ones and what they were supposed to be and you would be in big trouble.

So while your proposal seems reasonable, in some ways it is not the ideal thing. Thanks for mentioning it though.

[n0nce]

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.

You can encrypt the wallet with AES256, encode the wallet in BASE64 using some easy-to-parse computer font such as Courier New or System (they must be monospaced so they can be perfectly read again using OCR), and then print out the characters onto a large number of sheets of paper. Then you save the AES key and IV as qrcodes. Store all materials in a confidential place such as inside a safe.

In general, the idea of using QR codes is very good. Compared to plain text, they have pretty good error correction, so if the paper is partly damaged it will be still possible to decode them. They're also made specifically for scanning and reading into a computer via camera input, so you won't need to rely on the quality of an OCR software, even if those get better and better. Decoding QR via camera will be much more resilient and reliable.

[larry_vw_1955]

In general, the idea of using QR codes is very good. Compared to plain text, they have pretty good error correction, so if the paper is partly damaged it will be still possible to decode them. They're also made specifically for scanning and reading into a computer via camera input, so you won't need to rely on the quality of an OCR software, even if those get better and better. Decoding QR via camera will be much more resilient and reliable.

I definitely agree with that, the big problem with qrcodes is they're only good for 1024 characters or so. at least the software I tried only let me make a text string that long but not longer. that's not good enough. I need way more than that.

[LoyceV]

the big problem with qrcodes is they're only good for 1024 characters or so. at least the software I tried only let me make a text string that long but not longer. that's not good enough. I need way more than that.

This site puts the maximum at 4296 alphanumeric characters.

As a test, I took your post with 2439 characters and created this with qrencode:

[larry_vw_1955]

You can encrypt the wallet with AES256, encode the wallet in BASE64 using some easy-to-parse computer font such as Courier New or System (they must be monospaced so they can be perfectly read again using OCR), and then print out the characters onto a large number of sheets of paper. Then you save the AES key and IV as qrcodes. Store all materials in a confidential place such as inside a safe.

I tried this but my Base 64 encoded file has almost 90,000 characters in it and the software (NOTEPAD++) I was using to do this test couldn't handle that. When I printed it to a pdf file, it only printed the first 4 pages.  The OCR tool seemed to scan in those 4 pages ok but I have no idea if it really did since I can't really know until I decode the entire thing but to do that, I need the entire pdf file scanned. Not just the first 4 pages.

When you want to access the file again, read the papers in with a scanner, strip all whitespace and then decode the AES256 with the key and IV you have independently scanned. Requires a lot of paper, but it works.

If I can get to that point. But I have a feeling it's going to require 27 pages of printouts. Unless there was a way to shrink the printing size significantly.

[LoyceV]

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"?

I like BIP38 because it's so difficult to brute-force and the result can be printed. I like how it can even be used on mobile wallets.
I'd love to see something similar for encrypting a 12/24 word seed. Even better if the result is just represented as a seed again: to restore, enter the encrypted seed, the password and wait a few seconds (yes, seconds!) to decrypt it. I'd feel much safer than just storing the unencrypted seed words in plain text.

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.

Why don't you at least print each wallet separately? Adding them all together into one large encrypted and printed text (or image) creates one large point of failure: any unreadable part means you lose access to everything. If you print each wallet separately, you reduce the risk caused by a possible error.

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.

Let's take a step back: why not use one mnemonic that can create thousands of private keys for hundreds of different coins, and save that instead?

[HCP]

I'd love to see something similar for encrypting a 12/24 word seed. Even better if the result is just represented as a seed again: to restore, enter the encrypted seed, the password and wait a few seconds (yes, seconds!) to decrypt it. I'd feel much safer than just storing the unencrypted seed words in plain text.

I'm still struggling to understand why you need something other than the currently available plain text encryption options. This really does seem like reinventing the wheel to me...

Is it because you want wallets to provide built in methods to encode/decode the mnemonic string? Noting that if you end up with "random" text, it sort of defeats one of the core purposes of the mnemonic in the first place... ie. reduction of transcription errors.

Turning the result into another mnemonic string sounds like it should be possible... but then, why not just use the original seed and a strong BIP39 passphrase? Surely this ends up effectively resulting in the same thing... a mnemonic string + passphrase?

It seems like creating a .zip file with a password and then putting that into a .rar archive with another password... or am I missing something?

[n0nce]

the big problem with qrcodes is they're only good for 1024 characters or so. at least the software I tried only let me make a text string that long but not longer. that's not good enough. I need way more than that.

This site puts the maximum at 4296 alphanumeric characters.

~

Further, you can print multiple pages if you need more data (split it up and save each chunk as a QR code) and even adjust for less pages (but more error-prone due to smaller squares) or better readability in the future, but using more pages. However you wish. I would never trust 27 pieces of paper of plain text without checksum or error correction. The probability that a corner catches some humidity and rots away or similar, is too high. There are even insects and stuff that destroy paper.

[larry_vw_1955]

This site puts the maximum at 4296 alphanumeric characters.

As a test, I took your post with 2439 characters and created this with qrencode:

That's pretty amazing, the problem there is that software you mentioned is for linux. I would need a windows tool that could do the same type of thing. The qrcode software I have was able to read your huge qrcode and decode it into text but when I tried to encode the same text into a qrcode, it wouldn't work since it only allows up to 1024 characters apparently.

[larry_vw_1955]

.... However you wish. I would never trust 27 pieces of paper of plain text without checksum or error correction. The probability that a corner catches some humidity and rots away or similar, is too high. There are even insects and stuff that destroy paper.

So what you're saying is AES then Base64 encode and then do some error correction processing on it? That would make the file even longer but I'm willing to consider it. But I haven't heard of people doing a triple process thing like that before. So I'm not even sure its possible.

Also, the issue I'm experiencing with Notepad++ seems to be a longstanding one: https://community.notepad-plus-plus.org/topic/18197/issue-printing-long-lines/12
They should have had time to fix that bug by now but I guess they don't care.

[pooya87]

why not just use the original seed and a strong BIP39 passphrase? Surely this ends up effectively resulting in the same thing... a mnemonic string + passphrase?

Looks are deceiving. The extra word used in BIP39 is called "passphrase" but it is not encrypting anything. It also is not providing nearly enough security as when you actually encrypt something.
Take BIP38 for example focusing on the key derivation only, you can't even begin comparing the security that scrypt provides in BIP38 with what PBKDF2 provides in BIP39! For quick comparison the recommended iteration count used in PBKDF2 for security sensitive usages is 10 million; BIP39 uses 2048! Meanwhile costparam of 16384 used in scrypt is already more than enough, not to mention there is AES256 on top of that.

[larry_vw_1955]

I'd love to see something similar for encrypting a 12/24 word seed. Even better if the result is just represented as a seed again: to restore, enter the encrypted seed, the password and wait a few seconds (yes, seconds!) to decrypt it. I'd feel much safer than just storing the unencrypted seed words in plain text.

I think a person can implement exactly that process in a very trivial way. For example, say you are using the bip39 english wordlist. Say your mnemonic is 24 words long. Then you need to generate 24 random integers between 1 and 2048. Those 24 integers are your passphrase. They will serve as "offsets" when they get added to the indexes of the words in your unencrypted seedphrase. The addition is modulo 2048. Done. Now you have two things to keep track of instead of one but I guess that's the price you pay for having an encrypted seedphrase. As long as someone doesn't get ahold of both of those things, they can't do anything.

Come to think of it, the passphrase could just be any random set of 24 word seed phrase taken out of the wordlist because if you think about it, their indexes in the wordlist is those 24 integers I mentioned above.

So you have to store an encrypting seed phrase and also the encrypted seed phrase, both 24 words in length. To decrypt, you just subtract the encrypting seed phrase from the encrypted seed phrase  and voila. Is that too much trouble??

I am sure there is ways to make it more userfriendly. I mean electrum could generate the encrypting and encrypted seed phrases along with the normal seed so you would be good to go off the bat! That would be amazing.

[LoyceV]

I'm still struggling to understand why you need something other than the currently available plain text encryption options. This really does seem like reinventing the wheel to me...

One reason is I'm not familiar with other encryption that I can print, but another reason is that anything non-standard makes recovery more difficult years later. I (or someone else) may not remember exactly what was used.

Is it because you want wallets to provide built in methods to encode/decode the mnemonic string?

That would be my preferred solution.

Turning the result into another mnemonic string sounds like it should be possible... but then, why not just use the original seed and a strong BIP39 passphrase? Surely this ends up effectively resulting in the same thing... a mnemonic string + passphrase?

BIP39 passwords are relatively easy to brute-force. I like how BIP38 is several orders of magnitude more difficult, which means the password itself can be easier to remember for many years.

That's pretty amazing, the problem there is that software you mentioned is for linux. I would need a windows tool that could do the same type of thing.

Sorry, I can't help you there. You could search for the source code, but setting up a Linux system is probably easier.

[larry_vw_1955]

Looking at qrencode website (https://fukuchi.org/works/qrencode/), there are windows port such as http://code.google.com/p/qrencode-win32/, but it's a bit outdated. Besides, there are lots of QR code software/library on Windows, surely there are few which support more than 1K character.

There might be but it seems like everything is gone online now. They want to let you do everything "online" through their website. I guess they hoping someone puts in their private key. there's got to be a way to filter out those kind of search results.........