Pages:

Author

Topic: BIP39 lookup table for paranoids (Read 571 times)

Tbnzsf

brand new

Activity: 0

Merit: 0

pseudo_geek

newbie

Activity: 21

Merit: 10

Quote from: NotATether on December 07, 2020, 06:32:30 AM

Honestly I don't think BIP39 has fatal problems, although it indeedly has many imperfections. It doesn't seem to be the same case of something like POODLE attack - as long as you use SSL3.0, you are always vulnerable to such attacks; however just keep using BIP39 doesn't seem to introduce similar risks.

pseudo_geek

newbie

Activity: 21

Merit: 10

Quote from: NotATether on December 07, 2020, 06:32:30 AM

That's also what happened to the SSL 3.0 RFC after the POODLE attack was discovered, they published a new one that deprecated its use.

SSL/TLS session is transient thing. Therefore, it's less painful to migrate to upgraded/patched new protocol - although it's not completely painless, because there's many situations where installed old software can't be (easily) upgraded.

Quote from: NotATether on December 07, 2020, 06:32:30 AM

Meanwhile this is where alternatives to BIP39 have got us to:

https://imgs.xkcd.com/comics/standards.png

Agreed.

NotATether

legendary

Activity: 1568

Merit: 6660

bitcoincleanup.com / bitmixlist.org

Quote from: pseudo_geek on December 07, 2020, 06:02:42 AM

Quote from: pooya87 on December 07, 2020, 01:04:47 AM

You keep using the term "standard" while there is no such thing in bitcoin.

To me, it doesn't matter which word to use. If you feel uncomforatble about the word "standard", maybe I could replace it with something else, like "specification", "proposal" etc?

Yes those are better, a lot of BIPs have never made it to enforcement stage, which is what the word standard implies.

Once a BIP is published it becomes very hard to walk it back short of a major security vulnerability found in the design in which case they would theoretically release another BIP that deprecates the previous one, in fact that's sort of what happened to BIP39 (minus "major") if you read the comments on the github mediawiki page in the bips/ repo they wrote that they discourage its use. That's also what happened to the SSL 3.0 RFC after the POODLE attack was discovered, they published a new one that deprecated its use.

But you can't just obliterate a proposal from existence once its published in the internet because there is the risk that people have already made implementations based on it and deleting the proposal would invalidate those programs in the sense that it can't be proved anymore that they comply with the BIP based on official information.

It's the same reason RFC doesn't delete standards, Git hosting sites discourage you from overwriting remotes with a force push, and well-behaved programs do not reuse version bits that have been allocated for something else.

Meanwhile this is where alternatives to BIP39 have got us to:

pseudo_geek

newbie

Activity: 21

Merit: 10

Quote from: pooya87 on December 07, 2020, 01:04:47 AM

You keep using the term "standard" while there is no such thing in bitcoin.

To me, it doesn't matter which word to use. If you feel uncomforatble about the word "standard", maybe I could replace it with something else, like "specification", "proposal" etc?

Quote from: pooya87 on December 07, 2020, 01:04:47 AM

There is no centralized authority forming a standard committee defining what must or mustn't be used. Any developer decides what is the most appropriate approach and uses that instead.

Then it just turns out that, freedom/permissionless has its inevitable price to pay - a chaotic ecosystem which has been confusing/frustrating users up till now... Okay, okay, I'll stop here, I don't want to troll. Nobody (including me) can force any dev to change his mind to adopt anything (including BIP39) - however, in my opinion, if every dev designs his own awesome (/s) mnemonic scheme, then the users will simply get headache -again, they don't know WTF the mnemonic phrase at their hand is, they can't show it to some random experts on the Internet either (because it's confidential - anyone knows the mnemonic can instantly steal the funds locked by it).

Quote from: pooya87 on December 07, 2020, 01:04:47 AM

In fact these differences are a good indication of existing flaws in mnemonic algorithms. (everyone is trying to address them in their own way).

I know the imperfections of BIP39. I've already said that imperfections != fatal flaws.

Especially, I don't see those "BIP39-killers" like Electrum 2.0 can "fix" the so-called flaws of BIP39 - at least BIP39 hasn't been killed up till now. Countless users rely on it. You can't let BIP39 poof overnight. And, BIP39 works - I don't think it's necessary to kill it either.

"BIP39-killers" can't kill BIP39 - on the contrary those "BIP39-killers" themselves can't be killed either, which is ironically exactly the same case of BIP39.

In my opinion, ideally every wallet shoud take care of every mnemonic scheme, including either BIP39 or Electrum2.0, aezeed etc, however in reality this doesn't seem to happen for now, that's why users got frustrated/confused.

Quote from: pooya87 on October 16, 2020, 12:23:32 AM

This problem is not particularly created by devs, it is introduced at a later time when new scripts were introduced to bitcoin.
...
You also have to see this from the eyes of people who aren't familiar with many details of bitcoin. There are those who don't know what P2WPKH means let alone want to select it when recovering their wallet from mnemonic.

SegWit is another different topic. I can totally blame SegWit for the new commonly/widely used address/script types it had introduced to bitcoin, which forces the users to learn more - as a lazy human, learning is painful, isn't it. Let alone the privacy implications brought by SegWit, like: different script type may reveal which output is the change.

However, I still don't want to blame SegWit, because as a soft-fork upgrade, it at least achieved something (like, voluntary, opt-in, gradual upgrading, without breaking compatibility) after paying such price.

Quote from: pooya87 on October 16, 2020, 12:23:32 AM

For example there were no SegWit when BIP39 came out

Maybe the BRD (Bread) wallet is the better example than SegWit to support your argument? I didn't watch through such history, but git commit date etc indicates that BRD had adopted BIP39 before BIP44 came out. Then BRD keep using such "nonstandard" path up till now.

However, just like what I've outlined in my previous post, such case is not bad, a user can still manually specify (or something better, like what Electrum had recently done, to automatically probe/scan) such nonstandard path.

Quote from: pooya87 on October 16, 2020, 12:23:32 AM

and users can create both legacy and SegWit wallets from the same mnemonic

That's exactly the nice advantage of BIP39, with BIP44/49/89 compliance. So smooth, so convenient, without re-creating a brand new wallet as well as redoing the boring backup job for it.

Quote from: pooya87 on October 16, 2020, 12:23:32 AM

but while recovering they have to explicitly tell the wallet their address type or could end up with a wrong set of addresses.

To be frank, that's exactly the discrimination (mentioned in my previous post) put on BIP39 by Electrum devs, who obviously dislike BIP39 very much. However I would still appreciate them, because at least they worked hard to provide basic support for BIP39/44/49/84, albeit they insist on putting such scary/annoying warnings/discrimination on BIP39 wallets.

I also respect their decision to not provide those 3 address types (1/3/bc1, or P2PKH/P2SH-P2WPKH/P2WPKH) in one same wallet - although I really think such decision sacrifices convenience/usability for code simplicity/maintainability etc, which doesn't seem worthwhile.

Quote from: pooya87 on October 16, 2020, 12:23:32 AM

The alternative algorithms are each addressing different features that are lacking from BIP39 in their own way. For instance Electrum makes it flexible so that the algorithm can accept any wordlist of any number of words instead of the fixed 2048 ones BIP39 uses.

Just like my post above, I think I know how Electrum 2.0 seed achieve its amazing feature of validating a seed phrase without knowing the word list. However such trick doesn't seem to be so necessary, although it seems to be cool - although I see the fact that vanity mining on seed can introduce some lags during seed generation, I don't think it's a fatal problem either, I honestly still think it's cool.

Quote from: pooya87 on October 16, 2020, 12:23:32 AM

Quote

In my opinion, the "lack of version/type bits" is on the contrary a feature rather than a flaw - it means that you can adopt new coin types/address types/"accounts" (isolated subgroups of addresses) without redoing the boring backup job once again.

Good point but still having it is better than not having it.

I tend to agree with you - however the lack of version/type bits can also be justified with simplicity: it's a seed, nothing more. Just like the case of yprv/zprv, I appreciate the newly designed "output descriptors", which is intended to take over the job previously handled by yprv/zprv. There's also criticism on yprv/zprv because yprv/zprv is "violation of layering". What's more, no matter whether BIP39 looks ugly, after all it works, countless users have been relying on it. I don't think disturbing existing users good, especially when there's no much sigificant gain (like new features such as Shamir's Secret Sharing etc).

Quote from: pooya87 on October 16, 2020, 12:23:32 AM

Besides you can still override the default behavior and derive any key at any path you like.

This can be used to nitpick "BIP39-killers" like Electrum 2.0, aezeed etc as well.

Quote from: pooya87 on October 16, 2020, 12:23:32 AM

I was talking about the words used in the word list and the inconsistency that exists for the rules required to choose a word. For example you shouldn't use words that are similar (aim, air) but some words lists like English do.

There are better examples supporting your argument, like: "arm" vs "armed", "mix" vs "mixed". Besides, I think it's really not good for the simplified Chinese word (character) list to lack sorting according to pronunciation/pinyin.

However, I still want to repeat my opinion that such imperfections are not fatal, so that it doesn't seem worthwhile to try to "kill BIP39" - let alone the fact that BIP39 can't be killed, up till now at least.

Quote from: pooya87 on October 16, 2020, 12:23:32 AM

Quote from: pseudo_geek on December 06, 2020, 11:36:19 AM

Also, how could Electrum 2.0 seed achieve its amazing feature of validating a seed without knowing the word list?

It does need to know the wordlist but it doesn't force you to use 2048 words in your list, you can have 10000 words for example or 3!

To my understanding, the beauty of Electrum 2.0 seed is that, a wallet which doesn't generate new Electrum 2.0 seeds (in other words, being able to import existing Electrum 2.0 seeds) don't need to know (hard-code, download) the word list at all, just hashing (and the tiny bit of knowledge of defined version bits) is already enough.

Quote from: pooya87 on October 16, 2020, 12:23:32 AM

Quote

That explains why Electrum wallet GUI often seems to lose responding for several seconds during generating new seed - because it's still busy finding the required vanity seed for you.

What you are explaining is not about the word list but the algorithm used and it is a very fast one since it is simply computing a handful of HMACSHA512 hashes that is quite fast and should not slow down the UI at all.
If you are experiencing a slow speed it may be due to generation of all the child keys from that seed.

I don't think losing responding for merely several seconds during a one-time job like seed generation is a significant problem - actually I think it's almostly negligible. However to my understanding it's indeedly caused by vanity mining. which also explains why sometimes it doesn't seem to lag at all, and sometimes it lags for some more seconds.

Also, obviously such vanity mining doesn't have much to do with word list - I never said it either.

pooya87

legendary

Activity: 3472

Merit: 10611

Quote from: pseudo_geek on December 06, 2020, 10:49:08 AM

No, it's not hard at all. With standard derivation paths (and corresponding script/address type) including BIP44/49/84 etc, it works pretty well, across multiple wallets made by different vendors.

What's more, some "BIP39-killing" seed standards, like Electrum 2.0 seed and aezeed, share exactly the same word list with BIP39. Then what happens? Those ambiguous seed standards almostly effectively become yet another (much-blamed) "nonstandard derivation paths" themselves...

You keep using the term "standard" while there is no such thing in bitcoin. There is no centralized authority forming a standard committee defining what must or mustn't be used. Any developer decides what is the most appropriate approach and uses that instead.
In fact these differences are a good indication of existing flaws in mnemonic algorithms. (everyone is trying to address them in their own way).

Quote from: pooya87 on October 16, 2020, 12:23:32 AM

the mnemonic doesn't give you any indication of the derivation path or the script types and since each wallet uses its own thing

This problem is not particularly created by devs, it is introduced at a later time when new scripts were introduced to bitcoin. For example there were no SegWit when BIP39 came out and users can create both legacy and SegWit wallets from the same mnemonic but while recovering they have to explicitly tell the wallet their address type or could end up with a wrong set of addresses.
You also have to see this from the eyes of people who aren't familiar with many details of bitcoin. There are those who don't know what P2WPKH means let alone want to select it when recovering their wallet from mnemonic.

Quote from: pooya87 on October 16, 2020, 12:23:32 AM

the word-lists and their inconsistency is mainly because over the years new lists were added and over the years the rules for new ones were improved requiring more unique lists with distinct words.

To check validity of a BIP39 mnemonic, a corresponding word list is needed - so what if word list is not known? BIP39 said: oh, maybe, maybe... you can just ignore it. Grin

"maybe just ignore it" - that's the blamed inconsistency of BIP39.

Quote from: pseudo_geek on December 06, 2020, 11:36:19 AM

Also, how could Electrum 2.0 seed achieve its amazing feature of validating a seed without knowing the word list?

It does need to know the wordlist but it doesn't force you to use 2048 words in your list, you can have 10000 words for example or 3!

Quote

That explains why Electrum wallet GUI often seems to lose responding for several seconds during generating new seed - because it's still busy finding the required vanity seed for you.

pseudo_geek

newbie

Activity: 21

Merit: 10

There're also other things about Electrum 2.0 seed that I want to nitpick, like, if I'm not mistaken, Electrum wallet doesn't forbid using existing standard (single-signed) seed as a multi-sig cosigning key, and vice versa. Therefore, it's exactly the same problem of "only having the 12-word seed is still not enough", isn't it - if you enter a multi-sig seed as a standard (single-sig) one into Electrum, it will show you a blank wallet with 0 balance (typical symptom of "BIP39 derivation path syndrome"); if you forgot to take good care of such a dual-role seed, your co-signer/co-owner will probably blame you (because the co-owned funds might be stolen or permanently locked out).

Also, how could Electrum 2.0 seed achieve its amazing feature of validating a seed without knowing the word list? The answer is: vanity mining. Electrum does vanity mining on its seed in order to embed their version bits into the seed phrase. That explains why Electrum wallet GUI often seems to lose responding for several seconds during generating new seed - because it's still busy finding the required vanity seed for you.

pseudo_geek

newbie

Activity: 21

Merit: 10

Quote from: pooya87 on October 16, 2020, 12:23:32 AM

recovery using mnemonic (which was supposed to be easy) becomes hard.

No, it's not hard at all. With standard derivation paths (and corresponding script/address type) including BIP44/49/84 etc, it works pretty well, across multiple wallets made by different vendors.

Even if the nonstandard paths are taken into consideration, it's still not bad - almostly the only thing you need is merely a string called "derivation path" (or something more modern, like "output descriptor") - which is what Electrum, a BIP39-supporting-but-disliking wallet, has been doing up till now. There are only few exceptions like Bitcoin Core's hardened address derivation, which also seems to be easy cases to cover to me. Besides, there're no extra executable binaries to download, so that no need to worry about malwares. (Oh, if you insist on thinking deeper on this, a malicious "deep" "exotic" derivation path can be destructive as well, just like a maliciously tampered passphrase of BIP39 mnemonic - however I think this problem is probably avoidable by, like, providing a known list to the user - also, even if there's a "deep" "exotic" derivation path, it's still remembered by the wallet until deletion, while the passphrase would be forgotten by the wallet immediately)

Then what about the so-called "fixes" to BIP39's so-called flaws?

In my opinion, obviously a chaotic ecosystem with many competing incompatible mnemonic schemes is really making users feeling bad - as a user you generally can't show the mnemonic phrase to some random expert to determine WTF it is, because it's obviously confidential.

What's more, some "BIP39-killing" seed standards, like Electrum 2.0 seed and aezeed, share exactly the same word list with BIP39. Then what happens? Those ambiguous seed standards almostly effectively become yet another (much-blamed) "nonstandard derivation paths" themselves...

Quote from: pooya87 on October 16, 2020, 12:23:32 AM

the mnemonic doesn't give you any indication of the derivation path or the script types and since each wallet uses its own thing

After thinking about this problem, I think it's reasonable for a dev to feel bad about dealing with sh*ts (of unimaginable infinite possibilities) produced by other devs, or just themselves in the past. It's also not too bad (although it is definitely bad IMO, like outlined above) if different seed standards exclusively reject with each other (which is still better than the status quo outlined above, sigh). It should be not-so-bad (still bad, but also still ideal/better situation than the status quo, that devs tends to discriminate, or even ignore other disliked seed standards) that every wallet also take good care of other seed standards, but this requires efforts for the devs to implement and maintain.

However, unfortunately some (supposed) "BIP39-killer" seed standards like Electrum 2.0 and aezeed don't seem to be good precedences, because they are BIP39-ambiguous.

In my opinion, the "lack of version/type bits" is on the contrary a feature rather than a flaw - it means that you can adopt new coin types/address types/"accounts" (isolated subgroups of addresses) without redoing the boring backup job once again.

However I also admit that in a case the user wants to destroy a backup, a forgotten derivation path/coin type/address type etc can be really destructive - although in my opinion it's just what bitcoin has been from the very beginning - even Satoshi himself said that "you should never delete a private key". Besides, I also admit that destroying an old mnemonic with forgotten funds is not the only possibility, leaking to the public is also a possible threat.

Also, although BIP44/49/84 provides isolation amoung different address types/coin types/"accounts", I admit that such isolation is likely to be simply bypassed by bad habit of carelessly importing the mnemonic (which is the "root" of everything) everywhere (rather than better behavior of exporting/importing properly isolated child HD node xpub/xprv/output descriptors).

Quote from: pooya87 on October 16, 2020, 12:23:32 AM

the word-lists and their inconsistency is mainly because over the years new lists were added and over the years the rules for new ones were improved requiring more unique lists with distinct words.

To check validity of a BIP39 mnemonic, a corresponding word list is needed - so what if word list is not known? BIP39 said: oh, maybe, maybe... you can just ignore it. Grin

"maybe just ignore it" - that's the blamed inconsistency of BIP39.
To my understanding it's not strictly about more and more languages being added, because wallet can still use the newly added word list to check the validity.
The one-way hash of BIP39 also disallowed conversion among different languages, so to summarize, it ruined both the advantage of one-way hash (so that checking validity won't need a word list) and the advantage of "bijective/reversible encoding" (for example, there might be awkward situations like inability to input CJK characters - this issue still seems to present even if it's bijectively/reversibly encoded, however conversion might still be useful. also, it seems to be nice to directly encode an existing HD master node).

However, I don't think these problems are fatal.

To summarize, I don't consider BIP39 perfect either. However I just don't want to see the "fix BIP39 by killing BIP39" story to happen again, only adding yet another incompatible (or even worse, ambiguous) seed standard to the whole ecosystem, without bringing much benefits/new features (like Shamir's Secret Sharing etc).

pooya87

legendary

Activity: 3472

Merit: 10611

Quote from: pseudo_geek on October 15, 2020, 10:20:32 PM

I'm aware. BIP39 requires the wordlist to check validity of a mnemonic phrase, which is one of many reasons why some people dislike BIP39. This can be viewed as a self-inconsistency of BIP39 spec, however I just think the fact that "wordlist flexibility" of BIP39 doesn't really work is not very important. Official English wordlist can work well, that's enough. In my opinion, the attempts to takeover BIP39 will only make the situation even worse, that the user (even machine) can't tell exact type of those 12 words at hand.

people dislike BIP39 but "checking validity" is not one of them. there are lots of issues with this proposal that has made it not-desirable. for example the mnemonic doesn't give you any indication of the derivation path or the script types and since each wallet uses its own thing, recovery using mnemonic (which was supposed to be easy) becomes hard.
the word-lists and their inconsistency is mainly because over the years new lists were added and over the years the rules for new ones were improved requiring more unique lists with distinct words.

pseudo_geek

newbie

Activity: 21

Merit: 10

Quote from: NotATether on September 20, 2020, 07:08:45 AM

This is not correct. As someone who's busy developing a BIP39 checker, this is only a recommended guideline. It is not strictly required to make every word have 4 unique leading letters, but it's highly discouraged not to because the more characters you need to iterate in a word to tell it apart from other words, the more likely someone's going to type the wrong word in their seed phrase.

It is definitely possible to create and use a wordlist that breaks this rule, but such a wordlist has no chance of getting merged into the BIP39's official github repository.

TheDigitalMan

jr. member

Activity: 45

Merit: 35

Hey thanks! I appreciate the confirmation. And the extra information regarding how it works. Much appreciated!

o_e_l_e_o

legendary

Activity: 2268

Merit: 18711

Quote from: TheDigitalMan on September 20, 2020, 06:33:42 AM

And I was thinking the numbering should be offset by 1 so that it was numbered beginning with ZERO and ending with 2047 = zoo.

This is correct.

You first generate 256 bits of entropy, then use SHA256 to calculate and append the 8 bit checksum. You then split the resulting 264 bits in to 24 chunks of 11 bits each. These can range as follows:

Code:

00000000000
00000000001
00000000010
00000000011
00000000100
00000000101
00000000110
00000000111
00000001000
.....
11111111111

00000000000 converted to decimal is 0 - abandon.
11111111111 converted to decimal is 2047 - zoo.

Quote from: TheDigitalMan on September 20, 2020, 06:33:42 AM

I'm surprised the word list got published like it did... but I guess their thinking was, it was a list of 2048 words and they numbered them accordingly.

The wordlist (https://github.com/bitcoin/bips/blob/master/bip-0039/english.txt) was published as a list of words without associated numbers. It is only numbered because GitHub uses line numbering starting from 1.

NotATether

legendary

Activity: 1568

Merit: 6660

bitcoincleanup.com / bitmixlist.org

Quote from: pseudo_geek on June 21, 2020, 07:40:52 PM

Quote

Only seeing leading 4 letters of each word? There's no problem, BIP39 was designed in the way that only leading 4 letters can already uniquely represent a word.

Quote from: TheDigitalMan on September 20, 2020, 06:33:42 AM

The word list that this thread refers to should be numbered 0 thru 2047. Correct?

If you're just printing out a list of words, it shouldn't matter how you number your words as long as you do it consistently in your project. If this is supposed to be fed into a machine, 0-based numbering, the number can be directly converted to a binary value. But if it's supposed to be read by humans, we find it a lot less confusing to remember numbers of words if the words use 1-based numbering.

TheDigitalMan

jr. member

Activity: 45

Merit: 35

I was going to start a new thread but this is EXACTLY what I was wanting to discuss!

The word list that this thread refers to should be numbered 0 thru 2047. Correct?

That is why you say 1 would actually refer to ABILITY rather then ABANDON.

I am working on a project that will involve a printed copy of this mnemonic word list. And I was thinking the numbering should be offset by 1 so that it was numbered beginning with ZERO and ending with 2047 = zoo.

Can anyone confirm this? I'm doing final proofing on my project and I started scratching my head over the numbering. Because I originally just took a copy of the word list and used it verbatim. But I'm realizing it is numbered incorrectly.

I'm already 99.9 percent certain that I need to go back and revise my numbering but just wondered if anyone else had any opinions?

I DO want the number associated with the word to match up with the number being used by the BIP39 protocol when creating the addresses etc. I understand the last word is a checksum in the mnemonic word list etc. But I still think "Abandon" should be numbered 0 and not 1. I'm not wrong in my thinking on this am I? I'm surprised the word list got published like it did... but I guess their thinking was, it was a list of 2048 words and they numbered them accordingly.

Thanks for reading and any feed back you might have. I'd like this printed list to be numbered in the appropriate manner and even though the list on github is numbered 1-2048 I'm thinking I should number mine 0-2047.

Kresp.

pooya87

legendary

Activity: 3472

Merit: 10611

Quote from: o_e_l_e_o on June 22, 2020, 03:49:53 AM

then map to the word list direct from GitHub (https://github.com/bitcoin/bips/blob/master/bip-0039/english.txt).

extreme care must be taken when things are done manually, specifically in this case because converting the entropy (coin flips) to mnemonic is done based on index of each word and the numbers beside each word on github is the line number.
in other words when you get 1 (00000000001) then your word is "ability" and NOT "abandon".
if the line numbers are used the end result will not be the same as what a BIP39 tool would generate from the same entropy and also you will be using a 2047 word long list instead of 2048 since you'll be deleting the last word (2048=zoo).

pseudo_geek

newbie

Activity: 21

Merit: 10

Quote from: webtricks on June 22, 2020, 01:14:11 PM

Is this your original work?

Yes. But I think such idea should not be so fresh.

I posted this table on another forum first.

webtricks

legendary

Activity: 1918

Merit: 1728

Is this your original work? Impressive!

Quote from: o_e_l_e_o on June 22, 2020, 03:49:53 AM

Further, if you are going to create the full seed yourself, then you need to calculate the checksum yourself, so you still need the 128 or 256 bits in binary to plug in to a SHA256 function. My method has always been to simply write down 0 for heads and 1 for tails (or vice versa), convert each 11 bits to decimal, and then map to the word list direct from GitHub (https://github.com/bitcoin/bips/blob/master/bip-0039/english.txt). You don't risk the mistake of losing your place, you have everything written down so you can double check it, and you can easily use the number to calculate the checksum.

Sure thing! There are better ways in which entropy could be created off-system and then used with precision in system but OP's solution is unique. It's far from perfect and I doubt anybody will use it for production but still I admire unique thinking and that's why I merited the thread.

pseudo_geek

newbie

Activity: 21

Merit: 10

Quote from: ?? on ??

If I set the reverse problem for myself, i.e. to find the random number that "correspond" to SEED I have, it could be revealed with use of that table , couldn't it? If that's true would be nice to have automated mode for such table which in the long run means the software development .

I'm not sure what did you mean. If you worried about potential info leak by moving mouse pointer on this image, I think it should be better to print out this lookup table, so that no electronic device would be required at all... (although this is true only for cross-checking purposes)

pseudo_geek

newbie

Activity: 21

Merit: 10

Quote from: o_e_l_e_o on June 22, 2020, 06:29:17 AM

I can do it quicker with less chance of making an error by thinking of 11001011101 (for example) as 1024 + 512 + 64 + 16 + 8 + 4 + 1

Yeah, it's nice for different people to have different preferences.

Quote from: o_e_l_e_o on June 22, 2020, 06:29:17 AM

"below the red line, below the orange line, above the yellow line, above the green line, below the blue line, left of the red line, right of the orange line, right of yellow line, right of green line, left of blue line, right of the purple line."

In my opinion, the point of making a table or a diagram is to illustrate something that's not easy to describe with words.

To me it's actually "find out which line the word lies, then find out the column in that line". Also, it's not only "above/below/left of/right of" a colored line (which really sounds confusing), I've already said it's a process of narrowing down the range. Each line would further shrink the range by half.

Quote from: o_e_l_e_o on June 22, 2020, 06:29:17 AM

you can use an open source SHA256 implementation on an airgapped device to calculate the necessary 4 or 8 bits and then work out the checksum word yourself, ....

The last 4 or 8 bits doesn't really matter. It's meaningless for an attacker to manipulate it. Even if it's manipulated, it costs almost nothing to scan through all the 2^4 or 2^8 possible "mnemonics with valid or mismatched checksum".

Quote from: o_e_l_e_o on June 22, 2020, 06:29:17 AM

... which is superior to trusting your wallet software.

According to my understanding, this lookup table helps cross-checking in two cases:

(1) An open-source mnemonic-processing software like Ian Coleman's BIP39 tool still requires an entropy source, which could be suspicious to paranoids - then this lookup table can eliminate the possibility/risk of rigged/flawed random generator.

(2) A backdoored wallet software (or firmware of a hardware wallet) can display attacker-controlled receiving addresses which are unrelated to the mnemonic phrase at all - then a paranoid can compare addresses displayed by the wallet and the mnemonic-processing software. In this case the lookup table doesn't really participate, however without the above first step this might not be meaningful.

However to my best knowledge such cross-checking can't provide absolute security. One of the possible reasons is that ECDSA has an inherent side-channel infoleak issue that a maliciously manipulated k-value can generate a signature which stealthily leaks secret data to the attacker.

o_e_l_e_o

legendary

Activity: 2268

Merit: 18711

Quote from: pseudo_geek on June 22, 2020, 05:02:47 AM

That's actually the sole purpose of this table. A human can do this without any electronic device or calculation skills.

That's kind of my point. I can do it quicker with less chance of making an error by thinking of 11001011101 (for example) as 1024 + 512 + 64 + 16 + 8 + 4 + 1, than I can by working out "below the red line, below the orange line, above the yellow line, above the green line, below the blue line, left of the red line, right of the orange line, right of yellow line, right of green line, left of blue line, right of the purple line."

Quote from: pseudo_geek on June 22, 2020, 05:02:47 AM

Then it doesn't really matter. A human (almostly) cannot calculate the checksum bits without electronic device. This table only helps a paranoid to cross-check, not generating.

This is true, but provided you have written down your coin tosses as I said above, you can use an open source SHA256 implementation on an airgapped device to calculate the necessary 4 or 8 bits and then work out the checksum word yourself, which is superior to trusting your wallet software.