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

If you're talking about several kB, that's going to be very annoying to do. At least add partial checksums per line or multiple lines.
Say this is your data (from random.org:
A simple md5sum per line would be:
This makes it much faster to check where you have a reading error.

There are also offline QR-code generators that replace a Bitcoin address by something else. And I wouldn't be surprised if some QR-readers do the same.

At first glance the above method seems to sound doable and promising however, iit does have some issues. one of the main ones is that there is no way that any piece of ocr software can "perfectly read" the characters off of a printed page.

In short, if you preserve your data well, you might end up having to hand-type it in (or at least go through it with your own eyeball character by character to fix scanning errors) to restore the unencrypted version. Assuming you can do that and don't mind doing that then this method could possibly work.

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.........

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.

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

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.

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.

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.

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.

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.

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?

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.

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.

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?

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.


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.

This site puts the maximum at 4296 alphanumeric characters.

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

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.

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.

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.

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.

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 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.

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.