public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Aymeric Vitte <vitteaymeric@gmail•com>
To: Alan Evans <thealanevans@gmail•com>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP39 seeds
Date: Tue, 1 Jan 2019 20:44:57 +0100	[thread overview]
Message-ID: <3ea2e92d-5be6-3331-5d6f-9c29d87e0546@gmail.com> (raw)
In-Reply-To: <CALPhJawf98+uqZXQRGH3Tjo1CnZJfE+CMw9J2ZqiHHmwDSdugQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 6074 bytes --]

You are simplifying too much what I am suggesting

What I am suggesting is: set a derivation method for BIP39 like for 
BIP32 (having the seed for BIP32 and not the derivation path is just 
like having nothing) and use this derivation method from a "book" (a 
"book" being a book, a document, a link, an image, whatever your secret 
can be), based on the fact that you will easily find from this 
derivation method "valid" BIP39 seeds (even if BIP39 does not enforce 
anything regarding valid phrases, everything can be valid as you 
mention, and this does not help in fact)

The derivation method will just define the way you select the words in 
the secret, and if everybody chooses the bible as the secret then this 
will not change the fact that it will be impossible to find the real 
seed without knowing the derivation path

Then you don't need to write the seed, you can easily plausible deny it, 
you can easily pass it to the family (using a passphrase does not say to 
them where they are supposed to use it)

"people lost"--> people think that there is some magic with BIP39 that 
will save them whatever they do (ie they don't even care of managing 
correctly the many easy to generate BIP39 seeds they are using) where 
they will always recover their seed and keys from BIP39/44/49, of course 
this does not work at all


Le 31/12/2018 à 17:52, Alan Evans a écrit :
> > Using some algorithm to take some input and generate a bip39 phrase 
> that you can use with any bip39 wallet sounds perfectly reasonable.
>
> I think any method that doesn't use real entropy, but some fake source 
> of randomness, such as a book is asking to be hacked and so is not a 
> reasonable idea.
>
> If an algorithm for book text to BIP39 sentence ever became well used, 
> common books will be systematically searched for accounts. People will 
> also choose their favourite passages, so I would expect to see collisions.
>
> You should also note that BIP39 does not need input that is from the 
> word list. You can use _any text as its input_, the word list and 
> checksum check is just recommended to be a warning, but again, text 
> chosen from public sources or common phrases is a bad idea for many 
> reasons.
>
> From BIP0039:
> /> The conversion of the mnemonic sentence to a binary seed is 
> completely independent from generating the sentence. This results in 
> rather simple code; *there are no constraints on sentence structure* 
> and clients are free to implement their own wordlists or even whole 
> sentence generators, allowing for flexibility in wordlists for typo 
> detection or other purposes./
> /> Although using a mnemonic not generated by the algorithm described 
> in "Generating the mnemonic" section is possible, this is not advised 
> and software must compute a checksum for the mnemonic sentence using a 
> wordlist and issue a warning if it is invalid./
>
> What you could do is use a regular true random BIP39 sentence in 
> conjunction with a phrase from a book as the "passphrase" giving you 
> that plausible deniability, right up to the point you put that in your 
> will or tell someone, i.e. for the "what if something happens to me" 
> case. Though I still think redirecting people to a book phase is risky 
> for this, e.g. books have editions, there may be a change in the key 
> place.
>
> From BIP0039:/
> /
> /> The described method also provides plausible deniability, because 
> every passphrase generates a valid seed (and thus a deterministic 
> wallet) but only the correct one will make the desired wallet available./
>
> Alan
>
> P.S. "I have seen many people completely lost with their wallets 
> because of [BIP39]": I would say "despite" not "because". These people 
> would have lost/miss recorded a BIP32 hex seed as well.
>
>
> On Thu, 27 Dec 2018 at 11:02, Aymeric Vitte via bitcoin-dev 
> <bitcoin-dev@lists•linuxfoundation.org 
> <mailto:bitcoin-dev@lists•linuxfoundation.org>> wrote:
>
>
>     Le 26/12/2018 à 19:54, James MacWhyte a écrit :
>>
>>     On Wed, Dec 26, 2018 at 11:33 AM Aymeric Vitte
>>     <vitteaymeric@gmail•com <mailto:vitteaymeric@gmail•com>> wrote:
>>
>>         so, even with a tool like yours, they can be misleaded, for
>>         example trying a few words to replace the missing/incorrect
>>         one, get a valid seed and stay stuck with it forever trying
>>         to play with BIP44/49 to find their keys
>>
>>
>>     Just a small detail, but my tool actually looks up all the
>>     possible combinations and then finds which one has been used
>>     before by looking for past transactions on the blockchain.
>>     Therefore, it won't tell you your phrase is correct unless it is
>>     a phrase that has actually been used before (preventing what you
>>     described).
>
>     I saw that your tool was querying blockchain.info
>     <http://blockchain.info>, but it cannot guess what derivation path
>     was used and if it is a standard one what addresses were used, and
>     even if successful it works only for bitcoin (so maybe it should
>     just output the ~1500 possible phrases and/or xprv, and be
>     completely offline, this is still doable for people)
>
>>
>>     Using some algorithm to take some input and generate a bip39
>>     phrase that you can use with any bip39 wallet sounds perfectly
>>     reasonable.
>
>     I forgot to mention that this can help also solving the "what if
>     something happens to me" case giving to the family the seed and
>     the parameter(s) for the derivation path, or an easy way to find
>     it (better than something like: remind this passphrase, take the
>     sha256 of it, then use some other stuff to find the encryption
>     algo, take n bytes of the hash, use it to decode my wallet or my
>     seed... and then everybody looking at you like crazy)
>
>     _______________________________________________
>     bitcoin-dev mailing list
>     bitcoin-dev@lists•linuxfoundation.org
>     <mailto:bitcoin-dev@lists•linuxfoundation.org>
>     https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>


[-- Attachment #2: Type: text/html, Size: 10313 bytes --]

  reply	other threads:[~2019-01-01 19:45 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-21 23:58 Aymeric Vitte
2018-12-23 18:46 ` Pavol Rusnak
2018-12-23 22:41   ` Aymeric Vitte
2018-12-25  0:30     ` James MacWhyte
2018-12-26 11:33       ` Aymeric Vitte
2018-12-26 18:54         ` James MacWhyte
2018-12-27 11:04           ` Aymeric Vitte
2018-12-31 16:52             ` Alan Evans
2019-01-01 19:44               ` Aymeric Vitte [this message]
2019-01-02 18:06               ` James MacWhyte
2019-01-04  0:02                 ` Aymeric Vitte
2018-12-24 14:58   ` Tiago Romagnani Silveira
2018-12-23 20:55 ` Eric Scrivner
2018-12-23 21:08 ` Jameson Lopp

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3ea2e92d-5be6-3331-5d6f-9c29d87e0546@gmail.com \
    --to=vitteaymeric@gmail$(echo .)com \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=thealanevans@gmail$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox