Re: [bitcoin-dev] Satoshilabs secret shared private key scheme

[Peter Todd via bitcoin-dev]

On Mon, Jan 08, 2018 at 07:40:38PM -0500, Rhavar via bitcoin-dev wrote:
> I think you're under-appreciating how useful the "plausible deniability". 
> Someone I know was (solo) traveling to the United States when a border agent 
> asked her to unlocked her phone; thumbed through her apps, ended up finding 
> tinder and went through all her recent conversations to make sure she wasn't 
> involved in any "pay for sex things".
> 
> In the same light, I travel frequently and constantly have my trezor on me. 
> If I am asked to unlock it, I will have no problems doing so (as refusal will 
> no doubt lead to deportation) and showing my personal wallet (which sadly 
> hasn't had much use since fees became ridiculous).

Trezor's "plausible deniability" scheme could very well result in you going to
jail for lying to border security, because it's so easy for them to simply
brute force alternate passwords based on your seeds. With that, they have proof
that you lied to customs, a serious offense.

I would strongly advise you not to use it in that situation.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org


signature.asc
Description: Digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Satoshilabs secret shared private key scheme

[Rhavar via bitcoin-dev]

I think you're under-appreciating how useful the "plausible deniability". 
Someone I know was (solo) traveling to the United States when a border agent 
asked her to unlocked her phone; thumbed through her apps, ended up finding 
tinder and went through all her recent conversations to make sure she wasn't 
involved in any "pay for sex things".

In the same light, I travel frequently and constantly have my trezor on me. If 
I am asked to unlock it, I will have no problems doing so (as refusal will no 
doubt lead to deportation) and showing my personal wallet (which sadly hasn't 
had much use since fees became ridiculous).

And by doing so, I won't be revealing the half a dozen other accounts I keep. 
Which is the other big of such "plausible deniability" schemes, they make it 
trivial to create multiple wallets that are all firewalled away from each other.

I will hypothesize that if one of my wallets was for something like buying 
stuff on dark markets there's simply no way anyone is going to ever know way 
you're going to be to tell short of some movie-plot level police effort. 



​-Ryan

​

> Original Message 
>Subject: Re: [bitcoin-dev] Satoshilabs secret shared private key scheme
>Local Time: January 8, 2018 5:47 PM
>UTC Time: January 8, 2018 11:47 PM
>From: bitcoin-dev@lists.linuxfoundation.org
>To: Pavol Rusnak 
>Bitcoin Protocol Discussion 
>
>On Mon, Jan 8, 2018 at 12:39 PM, Pavol Rusnak st...@satoshilabs.com wrote:
>>On 08/01/18 05:22, Gregory Maxwell wrote:
https://github.com/satoshilabs/slips/blob/master/slip-0039.md
Hey Gregory!
>>Thanks for looking into the scheme. I appreciate your time!
>>>This specification forces the key being used through a one way
>>> function, -- so you cannot take a pre-existing key and encode it with
>>> this scheme.
>>>Originally, we used a bi-directional function to be able to encode and
>> decode the key in both directions using the passphrase. We stretched the
>> passphrase using KDF and then applied AES or other symmetric cipher
>>We found the following (theoretical) problem:
>>If an attacker has knowledge of few words from the beginning of shares,
>> they are able to reconstruct the beginning of the master secret and if
>> the size of the reconstruced master secret is bigger then the cipher
>> blocksize (for block ciphers; for stream ciphers 1 bit is enough), then
>> they can reconstruct the beginning of the seed.
>>Can you find a scheme which does not have this problem? Or you think
>> this problem is not worth solving?
>>
> You can use a large block cipher. E.g. CMC cipher mode.
>
> Though I am doubtful that this is a very relevant concern: What
> consequence is it if someone with partial access to more than a
> threshold of the shares can recover part of the seed?  This doesn't
> seem like a very interesting threat.   A large block mode would be
> more complete, but this isn't something that would keep me up at night
> in the slightest.
>
> Perhaps I'm missing something, -- but the only real attack I see here
> is that a enduser mistakenly shows the first or couple words of all
> their shares on national television or what not... but doing so would
> not really harm their security unless they showed almost all of them,
> and in that case an attacker could simply search the remaining couple
> words.
>
> Also, if we are going to assume that users will leak parts, the
> mnemonic encoding ends up being pretty bad... since just leaking a
> letter or two of each word would quite likely give the whole thing
> away.
>
> In any case, to whatever extent partial leaks are a concern, using a
> large block cipher would be the obvious approach.
>
>>Yes. We want this to be possible to be computed on TREZOR-like devices
>> on boot, similarly how we compute BIP39 on boot right now.
>>
> Under this constraint it might be arguably to just eliminate the KDF.
> I think it provides false security and makes the implementation much
> more complicated.
>
> Have you considered using blind host-delegated KDFs, where the KDF
> runs on the user's computer instead of the hardware wallet, but the
> computer doesn't learn anything about they keys?
>
>>Again, this is by design and it is main point why plausible deniability
>> is achieved both in BIP39 and SLIP39. If we used a different
>> construction we'd loose plausible deniability.
>>
> I don't believe you can justify this design decision with any kind of
> rigorous threat model.
>
> The probability that a user loses funds because they have at some
> point recovered with the wrong key and don't know it would almost
> certainly dwarf the probability that the user face some kind of
> movie-plot threat where someone is attempting to forcibly extract a
> key and yet somehow has no information about the user's actual
> wallet-- through, for example, leaked data on the users computers, the
> users past payments to online accounts, or through a compromise or

Re: [bitcoin-dev] Satoshilabs secret shared private key scheme

[Peter Todd via bitcoin-dev]

On Tue, Jan 09, 2018 at 09:26:17AM +1100, Ben Kloester wrote:
> > This sounds very dangerous. As Gregory Maxwell pointed out, the key
> derivation
> > function is weak enough that passphrases could be easily brute forced
> 
> So you are essentially imagining that a perpetrator will combine the
> crypto-nerd fantasy (brute forcing the passphrase) *with* the 5-dollar
> wrench attack, merging both panes of Randall Munroe's comic? Seems
> vanishingly unlikely to me - attackers are generally either the wrench
> type, or the crypto-nerd type.

We're talking about seeds here, not hardware wallets.

For a hardware wallet theft scenario, if you're worried about muggers you can
make the hardware have secret accounts with different seeds, *without* risking
user funds getting lost - a much more likely scenario - due to mistyped
passwords.

In any case, even if you were to do this type of design, a much better idea is
to use a checksum by default to reject invalid passwords, while having an
advanced-use-only option to override that checksum. The virtual file encryption
filesystem encfs does exactly this with its --anykey flag. This allows advanced
users to do their thing, while protecting the majority of users for whome this
feature is dangerous.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org


signature.asc
Description: Digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Satoshilabs secret shared private key scheme

[Gregory Maxwell via bitcoin-dev]

On Mon, Jan 8, 2018 at 12:39 PM, Pavol Rusnak  wrote:
> On 08/01/18 05:22, Gregory Maxwell wrote:
>>> https://github.com/satoshilabs/slips/blob/master/slip-0039.md
>
> Hey Gregory!
>
> Thanks for looking into the scheme. I appreciate your time!
>
>> This specification forces the key being used through a one way
>> function, -- so you cannot take a pre-existing key and encode it with
>> this scheme.
>
> Originally, we used a bi-directional function to be able to encode and
> decode the key in both directions using the passphrase. We stretched the
> passphrase using KDF and then applied AES or other symmetric cipher
>
> We found the following (theoretical) problem:
>
> If an attacker has knowledge of few words from the beginning of shares,
> they are able to reconstruct the beginning of the master secret and if
> the size of the reconstruced master secret is bigger then the cipher
> blocksize (for block ciphers; for stream ciphers 1 bit is enough), then
> they can reconstruct the beginning of the seed.
>
> Can you find a scheme which does not have this problem? Or you think
> this problem is not worth solving?

You can use a large block cipher. E.g. CMC cipher mode.

Though I am doubtful that this is a very relevant concern: What
consequence is it if someone with partial access to more than a
threshold of the shares can recover part of the seed?  This doesn't
seem like a very interesting threat.   A large block mode would be
more complete, but this isn't something that would keep me up at night
in the slightest.

Perhaps I'm missing something, -- but the only real attack I see here
is that a enduser mistakenly shows the first or couple words of all
their shares on national television or what not... but doing so would
not really harm their security unless they showed almost all of them,
and in that case an attacker could simply search the remaining couple
words.

Also, if we are going to assume that users will leak parts, the
mnemonic encoding ends up being pretty bad... since just leaking a
letter or two of each word would quite likely give the whole thing
away.

In any case, to whatever extent partial leaks are a concern, using a
large block cipher would be the obvious approach.

> Yes. We want this to be possible to be computed on TREZOR-like devices
> on boot, similarly how we compute BIP39 on boot right now.

Under this constraint it might be arguably to just eliminate the KDF.
I think it provides false security and makes the implementation much
more complicated.

Have you considered using blind host-delegated KDFs, where the KDF
runs on the user's computer instead of the hardware wallet, but the
computer doesn't learn anything about they keys?

> Again, this is by design and it is main point why plausible deniability
> is achieved both in BIP39 and SLIP39. If we used a different
> construction we'd loose plausible deniability.

I don't believe you can justify this design decision with any kind of
rigorous threat model.

The probability that a user loses funds because they have at some
point recovered with the wrong key and don't know it would almost
certainly dwarf the probability that the user face some kind of
movie-plot threat where someone is attempting to forcibly extract a
key and yet somehow has no information about the user's actual
wallet-- through, for example, leaked data on the users computers, the
users past payments to online accounts, or through a compromise or
lawful order to satoshilab's web service which the users send private
information to-- which would allow them to determine the key they were
given was not correct.

But even there, given the weak level of false input rejection that you
have used (16 bits), it would be fairly straight forward to grind out
an alternative passphrase that also passed the test.  Might that not
make for a better compromise?

Another thing to consider is that the main advantage of SSS over
ordinary computational secret sharing is that it's possible to
generate alternative shares to an sub-threshold set of primary shares
that decodes to arbitrarily selected alternative data-- but it seems
the proposal makes no use of this fact.

>> It
>> is again, unversioned-- so it kinda of seems like it is intentionally
>> constructed in a way that will prevent interoperable use, since the
>> lack of versioning was a primary complaint from other perspective
>> users.  Of course, it fine if you want to make a trezor only thing,
>> but why bother BIPing something that was not intended for
>> interoperability?  Even for a single vendor spec the lack of
>> versioning seems to make things harder to support new key-related
>> features such as segwit.
>
> This is argument I keep having all the time.
>
> Suppose we'd introduce a version to encode PBKDF2 rounds or even
> different KDFs. We'll end up with different SLIP39 mnemonics, but they
> will not be compatible among implementations (because TREZOR can only up
> to 100.000 rounds of PBKDF2 and does 

Re: [bitcoin-dev] Satoshilabs secret shared private key scheme

[Ben Kloester via bitcoin-dev]

> This sounds very dangerous. As Gregory Maxwell pointed out, the key
derivation
> function is weak enough that passphrases could be easily brute forced

So you are essentially imagining that a perpetrator will combine the
crypto-nerd fantasy (brute forcing the passphrase) *with* the 5-dollar
wrench attack, merging both panes of Randall Munroe's comic? Seems
vanishingly unlikely to me - attackers are generally either the wrench
type, or the crypto-nerd type.

This thread started by you asking Pavol to give an example of a real-life
scenario in which this functionality would be used, and your rebuttal is a
scenario that is even less likely to occur. "Very dangerous" is a huge
stretch.

When living in Brazil I often carried two (IRL) wallets - one a decoy to
give to muggers, the other with more value stored in it. I heard of plenty
of people getting mugged, but I never heard of anyone who gave a decoy
wallet getting more thoroughly searched and the second wallet found,
despite the relative ease with which a mugger could do this. I'm sure it
has happened, probably many times, but point is there is rarely time for
contemplation in a shakedown, and most perpetrators will take things at
face value and be satisfied with getting something. And searching a
physical person's body is a hell of a lot simpler than cracking a
passphrase.

Moreover, there's no limit to the number of passphrases you can use. If you
were an atttacker, at what point would you stop, satisfied? After the
first, second, third, fourth wallet that you find/they admit to owning?
Going beyond two is already Bond-supervillain level implausible.

*Ben Kloester*

On 9 January 2018 at 06:37, Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Mon, Jan 08, 2018 at 02:00:17PM +0100, Pavol Rusnak wrote:
> > On 08/01/18 13:45, Peter Todd wrote:
> > > Can you explain _exactly_ what scenario the "plausible deniability"
> feature
> > > refers to?
> >
> >
> > https://doc.satoshilabs.com/trezor-user/advanced_settings.
> html#multi-passphrase-encryption-hidden-wallets
>
> This sounds very dangerous. As Gregory Maxwell pointed out, the key
> derivation
> function is weak enough that passphrases could be easily brute forced, at
> which
> point the bad guys have cryptographic proof that you tried to lie to them
> and
> cover up funds.
>
>
> What model of human memory are you assuming here? What specifically are you
> assuming is easy to remember, and hard to remember? What psychology
> research
> backs up your assumptions?
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Satoshilabs secret shared private key scheme

[Peter Todd via bitcoin-dev]

On Mon, Jan 08, 2018 at 02:00:17PM +0100, Pavol Rusnak wrote:
> On 08/01/18 13:45, Peter Todd wrote:
> > Can you explain _exactly_ what scenario the "plausible deniability" feature
> > refers to?
> 
> 
> https://doc.satoshilabs.com/trezor-user/advanced_settings.html#multi-passphrase-encryption-hidden-wallets

This sounds very dangerous. As Gregory Maxwell pointed out, the key derivation
function is weak enough that passphrases could be easily brute forced, at which
point the bad guys have cryptographic proof that you tried to lie to them and
cover up funds.


What model of human memory are you assuming here? What specifically are you
assuming is easy to remember, and hard to remember? What psychology research
backs up your assumptions?

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org


signature.asc
Description: Digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP 39: Add language identifier strings for wordlists

[Aymeric Vitte via bitcoin-dev]

That's the point indeed and the scope is wider than XYZIP-39, even if
what I mean is the very contrary of your point (really bitcoin is
reserved to an elite understanding english/ascii letters?)

This proposal is tailor made for Trezor and does not simplify anything
for people, that's the contrary again

As I suggested in another response to this thread (which was moderated
due probably to some uninteresting parts of the discussion) it's time to
take a break and really make a survey worldwide of what people need,
what they understand and what they need to secure their coins, nobody
has any feedback about this (and maybe does not even care)

Wallets created a big mess implementing non standard things (or things
they thought standard but that are not), or things not intended for the
final use, or things that people can't understand, it's time to correct
this, unless wallets want to keep people tied forever to them (when I
read Trezor or other wallets docs, it's quite misleading, "sending coins
to your wallet", what does it mean? Nothing, and people think it means
something, this should stop now)

And again, I don't see the point of wordlist (in addition in a language
that they don't understand) compared to backing up a 32B hex string
(that you can encrypt different ways at different places), assuming that
the hex format can be made available in all languages

"yet I would not advise users to use a wordlist that might not have
support across multiple wallet implementations, resulting in lock-in or
worse"--> this single sentence shows how the whole model is wrong and
how you think that you can lock people

Le 08/01/2018 à 15:54, Greg Sanders via bitcoin-dev a écrit :
> Let me re-phrase: Is it a known thing for users to actually use it?
>
> On Mon, Jan 8, 2018 at 9:52 AM, Matias Alejo Garcia  > wrote:
>
>
>
> On Mon, Jan 8, 2018 at 11:34 AM, Greg Sanders via bitcoin-dev
>  > wrote:
>
> Has anyone actually used the multilingual support in bip39?
>
>
>
> Copay (and all its clones) use it. 
>
>
>
>  
>
>
> If a feature of the standard has not been(widely?) used in
> years, and isn't supported in any major wallet(?), it seems
> indicative it was a mistake to add it in the first place,
> since it's a footgun in the making for some poor sap who can't
> even read English letters when almost all documentation is
> written in English.
>
> On Mon, Jan 8, 2018 at 6:13 AM, nullius via bitcoin-dev
>  > wrote:
>
> On 2018-01-08 at 07:35:52 +, 木ノ下じょな
> >
> wrote:
>
> This is very sad.
>
> The number one problem in Japan with BIP39 seeds is
> with English words.
>
> I have seen a 60 year old Japanese man writing down
> his phrase (because he kept on failing recovery), and
> watched him write down "aneter" for "amateur"...
>
> [...]
>
> If you understand English and can spell, you read a
> word, your brain processes the word, and you can spell
> it on your own when writing down.  Not many Japanese
> people can do that, so they need to copy letter for
> letter, taking a long time, and still messing up on
> occasion.
>
> [...]
>
> Defining "everyone should only use English, because
> ASCII is easier to plan for" is not a good way to move
> forward as a currency.
>
>
> Well said.  Thank you for telling of these experiences. 
> Now please, let’s put the shoe on the other foot.
>
> I ask everybody who wants an English-only mnemonic
> standard to entrust *their own money* to their abilities
> to very, very carefully write this down—then later, type
> it back in:
>
> すさん　たんろ　りゆう　しもん　ていおん　しとう
> とこや　はやい　おうさま　ほくろ　けちゃっふ　たもつ
>
> (Approximate translation:  “Whatever would you do if
> Bitcoin had been invented by somebody named Satoshi
> Nakamoto?”)
>
> No, wait:  That is only a 12-word mnemonic.  We are
> probably talking about a Trezor; so now, hey you there,
> stake the backup of your life’s savings on your ability to
> handwrite *this*:
>
> にあう　しひょう　にんすう　ひえる　かいこう　いのる　ねんし　はあさん　ひこく
> とうく　きもためし　そなた　こなこな　にさんかたんそ　ろんき　めいあん　みわく
> へこむ　すひょう　おやゆひ　ふせく　けさき　めいきょく　こんまけ
>
> Ready to bet your money on *that* as a backup phrase in
> your own 

Re: [bitcoin-dev] BIP 39: Add language identifier strings for wordlists

[Greg Sanders via bitcoin-dev]

>I'm shocked that so many people are resisting the idea that just *maybe* there
could be people in other parts of the world who do not want to use or
cannot use the strict set of latin characters and words from the English
language.


You're mistaking concern for users potentially losing money with disdain
for them. I can read a few languages, yet I would not advise users to use a
wordlist that might not have support across multiple wallet
implementations, resulting in lock-in or worse.

If I'm wrong, great, more people can use software strictly in their native
language in a safe manner!

On Mon, Jan 8, 2018 at 10:26 AM, AJ West  wrote:

> Greg yes, there were already examples in this very thread of people
> explaining how they use languages other than English. I'm shocked that so
> many people are resisting the idea that just *maybe* there could be
> people in other parts of the world who do not want to use or cannot use the
> strict set of latin characters and words from the English language.
>
> I agree with Sjors and maybe I'm simplifying too much, but can't we just
> map an existing ISO/UTF language character standard to the seeds? Why is
> there a word list at all? Choose a flexible encoding standard, create a
> clever map to the bytes, make sure to include a checksum.
>
> As an aside, I know there are some conventions which add space for error
> correction but I personally don't love the idea of somebody inputting what
> they think is the proper seed, only to have it auto-corrected and thus
> reinforcing their erroneously saved/written seed backup.
>
> Pavol, why do you say "I learned that it was something I should've been
> more persistently against?" I still can't see any good arguments as to why
> we should limit this to English other than "It's easier to support a single
> language" which comes at the cost of "It's hard for me to backup my seed"
> for those who don't speak English.
>
> On Mon, Jan 8, 2018 at 10:23 AM, Matias Alejo Garcia via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> > Let me re-phrase: Is it a known thing for users to actually use it?
>>
>> yes. Based on language stats from the app stores, roughly 30% to 40% of
>> Copay users have their backup on a language
>> other than English, and we constantly get requests to support new
>> languages in BIP39.
>>
>> On Mon, Jan 8, 2018 at 11:54 AM, Greg Sanders 
>> wrote:
>>
>>> Let me re-phrase: Is it a known thing for users to actually use it?
>>>
>>> On Mon, Jan 8, 2018 at 9:52 AM, Matias Alejo Garcia 
>>> wrote:
>>>


 On Mon, Jan 8, 2018 at 11:34 AM, Greg Sanders via bitcoin-dev <
 bitcoin-dev@lists.linuxfoundation.org> wrote:

> Has anyone actually used the multilingual support in bip39?
>


 Copay (and all its clones) use it.





>
> If a feature of the standard has not been(widely?) used in years, and
> isn't supported in any major wallet(?), it seems indicative it was a
> mistake to add it in the first place, since it's a footgun in the making
> for some poor sap who can't even read English letters when almost all
> documentation is written in English.
>
> On Mon, Jan 8, 2018 at 6:13 AM, nullius via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> On 2018-01-08 at 07:35:52 +, 木ノ下じょな 
>> wrote:
>>
>>> This is very sad.
>>>
>>> The number one problem in Japan with BIP39 seeds is with English
>>> words.
>>>
>>> I have seen a 60 year old Japanese man writing down his phrase
>>> (because he kept on failing recovery), and watched him write down 
>>> "aneter"
>>> for "amateur"...
>>>
>>> [...]
>>>
>>> If you understand English and can spell, you read a word, your brain
>>> processes the word, and you can spell it on your own when writing down.
>>> Not many Japanese people can do that, so they need to copy letter for
>>> letter, taking a long time, and still messing up on occasion.
>>>
>>> [...]
>>>
>>> Defining "everyone should only use English, because ASCII is easier
>>> to plan for" is not a good way to move forward as a currency.
>>>
>>
>> Well said.  Thank you for telling of these experiences.  Now please,
>> let’s put the shoe on the other foot.
>>
>> I ask everybody who wants an English-only mnemonic standard to
>> entrust *their own money* to their abilities to very, very carefully 
>> write
>> this down—then later, type it back in:
>>
>> すさん たんろ りゆう しもん ていおん しとう
>> とこや はやい おうさま ほくろ けちゃっふ たもつ
>>
>> (Approximate translation:  “Whatever would you do if Bitcoin had been
>> invented by somebody named Satoshi Nakamoto?”)
>>
>> No, wait:  That is only a 12-word mnemonic.  We are probably talking
>> about a Trezor; so now, hey you there, stake 

Re: [bitcoin-dev] BIP 39: Add language identifier strings for wordlists

[AJ West via bitcoin-dev]

Greg yes, there were already examples in this very thread of people
explaining how they use languages other than English. I'm shocked that so
many people are resisting the idea that just *maybe* there could be people
in other parts of the world who do not want to use or cannot use the strict
set of latin characters and words from the English language.

I agree with Sjors and maybe I'm simplifying too much, but can't we just
map an existing ISO/UTF language character standard to the seeds? Why is
there a word list at all? Choose a flexible encoding standard, create a
clever map to the bytes, make sure to include a checksum.

As an aside, I know there are some conventions which add space for error
correction but I personally don't love the idea of somebody inputting what
they think is the proper seed, only to have it auto-corrected and thus
reinforcing their erroneously saved/written seed backup.

Pavol, why do you say "I learned that it was something I should've been
more persistently against?" I still can't see any good arguments as to why
we should limit this to English other than "It's easier to support a single
language" which comes at the cost of "It's hard for me to backup my seed"
for those who don't speak English.

On Mon, Jan 8, 2018 at 10:23 AM, Matias Alejo Garcia via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> > Let me re-phrase: Is it a known thing for users to actually use it?
>
> yes. Based on language stats from the app stores, roughly 30% to 40% of
> Copay users have their backup on a language
> other than English, and we constantly get requests to support new
> languages in BIP39.
>
> On Mon, Jan 8, 2018 at 11:54 AM, Greg Sanders 
> wrote:
>
>> Let me re-phrase: Is it a known thing for users to actually use it?
>>
>> On Mon, Jan 8, 2018 at 9:52 AM, Matias Alejo Garcia 
>> wrote:
>>
>>>
>>>
>>> On Mon, Jan 8, 2018 at 11:34 AM, Greg Sanders via bitcoin-dev <
>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>
 Has anyone actually used the multilingual support in bip39?

>>>
>>>
>>> Copay (and all its clones) use it.
>>>
>>>
>>>
>>>
>>>

 If a feature of the standard has not been(widely?) used in years, and
 isn't supported in any major wallet(?), it seems indicative it was a
 mistake to add it in the first place, since it's a footgun in the making
 for some poor sap who can't even read English letters when almost all
 documentation is written in English.

 On Mon, Jan 8, 2018 at 6:13 AM, nullius via bitcoin-dev <
 bitcoin-dev@lists.linuxfoundation.org> wrote:

> On 2018-01-08 at 07:35:52 +, 木ノ下じょな 
> wrote:
>
>> This is very sad.
>>
>> The number one problem in Japan with BIP39 seeds is with English
>> words.
>>
>> I have seen a 60 year old Japanese man writing down his phrase
>> (because he kept on failing recovery), and watched him write down 
>> "aneter"
>> for "amateur"...
>>
>> [...]
>>
>> If you understand English and can spell, you read a word, your brain
>> processes the word, and you can spell it on your own when writing down.
>> Not many Japanese people can do that, so they need to copy letter for
>> letter, taking a long time, and still messing up on occasion.
>>
>> [...]
>>
>> Defining "everyone should only use English, because ASCII is easier
>> to plan for" is not a good way to move forward as a currency.
>>
>
> Well said.  Thank you for telling of these experiences.  Now please,
> let’s put the shoe on the other foot.
>
> I ask everybody who wants an English-only mnemonic standard to entrust
> *their own money* to their abilities to very, very carefully write this
> down—then later, type it back in:
>
> すさん たんろ りゆう しもん ていおん しとう
> とこや はやい おうさま ほくろ けちゃっふ たもつ
>
> (Approximate translation:  “Whatever would you do if Bitcoin had been
> invented by somebody named Satoshi Nakamoto?”)
>
> No, wait:  That is only a 12-word mnemonic.  We are probably talking
> about a Trezor; so now, hey you there, stake the backup of your life’s
> savings on your ability to handwrite *this*:
>
> にあう しひょう にんすう ひえる かいこう いのる ねんし はあさん ひこく
> とうく きもためし そなた こなこな にさんかたんそ ろんき めいあん みわく
> へこむ すひょう おやゆひ ふせく けさき めいきょく こんまけ
>
> Ready to bet your money on *that* as a backup phrase in your own
> hands?  No?  Then please, stop demanding that others risk *their* money on
> the inverse case.
>
> 
>
> If you cheat here by having studied Japanese, then remember that many
> Japanese people know English and other European languages, too.  Then 
> think
> of how much money would be lost by your non-Japanese-literate family and
> friends—if BIP 39 had only Japanese wordlists, and your folks needed to
> wrestle with the above phrases as their “mnemonics”.

Re: [bitcoin-dev] BIP 39: Add language identifier strings for wordlists

[Matias Alejo Garcia via bitcoin-dev]

> Let me re-phrase: Is it a known thing for users to actually use it?

yes. Based on language stats from the app stores, roughly 30% to 40% of
Copay users have their backup on a language
other than English, and we constantly get requests to support new languages
in BIP39.

On Mon, Jan 8, 2018 at 11:54 AM, Greg Sanders  wrote:

> Let me re-phrase: Is it a known thing for users to actually use it?
>
> On Mon, Jan 8, 2018 at 9:52 AM, Matias Alejo Garcia 
> wrote:
>
>>
>>
>> On Mon, Jan 8, 2018 at 11:34 AM, Greg Sanders via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> Has anyone actually used the multilingual support in bip39?
>>>
>>
>>
>> Copay (and all its clones) use it.
>>
>>
>>
>>
>>
>>>
>>> If a feature of the standard has not been(widely?) used in years, and
>>> isn't supported in any major wallet(?), it seems indicative it was a
>>> mistake to add it in the first place, since it's a footgun in the making
>>> for some poor sap who can't even read English letters when almost all
>>> documentation is written in English.
>>>
>>> On Mon, Jan 8, 2018 at 6:13 AM, nullius via bitcoin-dev <
>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>
 On 2018-01-08 at 07:35:52 +, 木ノ下じょな 
 wrote:

> This is very sad.
>
> The number one problem in Japan with BIP39 seeds is with English words.
>
> I have seen a 60 year old Japanese man writing down his phrase
> (because he kept on failing recovery), and watched him write down "aneter"
> for "amateur"...
>
> [...]
>
> If you understand English and can spell, you read a word, your brain
> processes the word, and you can spell it on your own when writing down.
> Not many Japanese people can do that, so they need to copy letter for
> letter, taking a long time, and still messing up on occasion.
>
> [...]
>
> Defining "everyone should only use English, because ASCII is easier to
> plan for" is not a good way to move forward as a currency.
>

 Well said.  Thank you for telling of these experiences.  Now please,
 let’s put the shoe on the other foot.

 I ask everybody who wants an English-only mnemonic standard to entrust
 *their own money* to their abilities to very, very carefully write this
 down—then later, type it back in:

 すさん たんろ りゆう しもん ていおん しとう
 とこや はやい おうさま ほくろ けちゃっふ たもつ

 (Approximate translation:  “Whatever would you do if Bitcoin had been
 invented by somebody named Satoshi Nakamoto?”)

 No, wait:  That is only a 12-word mnemonic.  We are probably talking
 about a Trezor; so now, hey you there, stake the backup of your life’s
 savings on your ability to handwrite *this*:

 にあう しひょう にんすう ひえる かいこう いのる ねんし はあさん ひこく
 とうく きもためし そなた こなこな にさんかたんそ ろんき めいあん みわく
 へこむ すひょう おやゆひ ふせく けさき めいきょく こんまけ

 Ready to bet your money on *that* as a backup phrase in your own
 hands?  No?  Then please, stop demanding that others risk *their* money on
 the inverse case.

 

 If you cheat here by having studied Japanese, then remember that many
 Japanese people know English and other European languages, too.  Then think
 of how much money would be lost by your non-Japanese-literate family and
 friends—if BIP 39 had only Japanese wordlists, and your folks needed to
 wrestle with the above phrases as their “mnemonics”.

 In such cases, the phrases cannot be called “mnemonics” at all.  A
 “mnemonic” implies aid to memory.  Gibberish in a wholly alien writing
 system is much worse even than transcribing pseudorandom hex strings.  The
 Japanese man in the quoted story, who wrote “aneter” for “amateur”, was not
 dealing with a *mnemonic*:  He was using the world’s most inefficient means
 of making cryptic bitstrings *less* userfriendly.

 

 I began this thread with a quite simple request:  Is “日本語” an
 appropriate string for identifying the Japanese language to Japanese
 users?  And what of the other strings I posted for other languages?

 I asked this as an implementer working on my own instance of the
 greatest guard against vendor lock-in and stale software:  Independent
 implementations.  —  I asked, because obviously, I myself do not speak all
 these different languages; and I want to implement them all.  *All.*

 Some replies have been interesting in their own right; but thus far,
 nobody has squarely addressed the substance of my question.

 Most worrisome is that much of the discussion has veered into criticism
 of multi-language support.  I opened with a question about other languages,
 and I am getting replies which raise a hue and cry of “English only!”

 Though I am fluent and literate in English, I am uninterested in ever
 implementing any standard of 

Re: [bitcoin-dev] BIP 39: Add language identifier strings for wordlists

[Matias Alejo Garcia via bitcoin-dev]

On Mon, Jan 8, 2018 at 11:34 AM, Greg Sanders via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Has anyone actually used the multilingual support in bip39?
>


Copay (and all its clones) use it.





>
> If a feature of the standard has not been(widely?) used in years, and
> isn't supported in any major wallet(?), it seems indicative it was a
> mistake to add it in the first place, since it's a footgun in the making
> for some poor sap who can't even read English letters when almost all
> documentation is written in English.
>
> On Mon, Jan 8, 2018 at 6:13 AM, nullius via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> On 2018-01-08 at 07:35:52 +, 木ノ下じょな  wrote:
>>
>>> This is very sad.
>>>
>>> The number one problem in Japan with BIP39 seeds is with English words.
>>>
>>> I have seen a 60 year old Japanese man writing down his phrase (because
>>> he kept on failing recovery), and watched him write down "aneter" for
>>> "amateur"...
>>>
>>> [...]
>>>
>>> If you understand English and can spell, you read a word, your brain
>>> processes the word, and you can spell it on your own when writing down.
>>> Not many Japanese people can do that, so they need to copy letter for
>>> letter, taking a long time, and still messing up on occasion.
>>>
>>> [...]
>>>
>>> Defining "everyone should only use English, because ASCII is easier to
>>> plan for" is not a good way to move forward as a currency.
>>>
>>
>> Well said.  Thank you for telling of these experiences.  Now please,
>> let’s put the shoe on the other foot.
>>
>> I ask everybody who wants an English-only mnemonic standard to entrust
>> *their own money* to their abilities to very, very carefully write this
>> down—then later, type it back in:
>>
>> すさん たんろ りゆう しもん ていおん しとう
>> とこや はやい おうさま ほくろ けちゃっふ たもつ
>>
>> (Approximate translation:  “Whatever would you do if Bitcoin had been
>> invented by somebody named Satoshi Nakamoto?”)
>>
>> No, wait:  That is only a 12-word mnemonic.  We are probably talking
>> about a Trezor; so now, hey you there, stake the backup of your life’s
>> savings on your ability to handwrite *this*:
>>
>> にあう しひょう にんすう ひえる かいこう いのる ねんし はあさん ひこく
>> とうく きもためし そなた こなこな にさんかたんそ ろんき めいあん みわく
>> へこむ すひょう おやゆひ ふせく けさき めいきょく こんまけ
>>
>> Ready to bet your money on *that* as a backup phrase in your own hands?
>> No?  Then please, stop demanding that others risk *their* money on the
>> inverse case.
>>
>> 
>>
>> If you cheat here by having studied Japanese, then remember that many
>> Japanese people know English and other European languages, too.  Then think
>> of how much money would be lost by your non-Japanese-literate family and
>> friends—if BIP 39 had only Japanese wordlists, and your folks needed to
>> wrestle with the above phrases as their “mnemonics”.
>>
>> In such cases, the phrases cannot be called “mnemonics” at all.  A
>> “mnemonic” implies aid to memory.  Gibberish in a wholly alien writing
>> system is much worse even than transcribing pseudorandom hex strings.  The
>> Japanese man in the quoted story, who wrote “aneter” for “amateur”, was not
>> dealing with a *mnemonic*:  He was using the world’s most inefficient means
>> of making cryptic bitstrings *less* userfriendly.
>>
>> 
>>
>> I began this thread with a quite simple request:  Is “日本語” an appropriate
>> string for identifying the Japanese language to Japanese users?  And what
>> of the other strings I posted for other languages?
>>
>> I asked this as an implementer working on my own instance of the greatest
>> guard against vendor lock-in and stale software:  Independent
>> implementations.  —  I asked, because obviously, I myself do not speak all
>> these different languages; and I want to implement them all.  *All.*
>>
>> Some replies have been interesting in their own right; but thus far,
>> nobody has squarely addressed the substance of my question.
>>
>> Most worrisome is that much of the discussion has veered into criticism
>> of multi-language support.  I opened with a question about other languages,
>> and I am getting replies which raise a hue and cry of “English only!”
>>
>> Though I am fluent and literate in English, I am uninterested in ever
>> implementing any standard of this nature which is artificially restricted
>> to English.  I am fortunate; for as of this moment, we have a standard
>> called “BIP 39” which has seven non-English wordlists, and four more
>> pending in open pull requests (#432, #442, #493, #621).
>>
>> I request discussion of language identification strings appropriate for
>> use with that standard.
>>
>> (P.S., I hope that my system did not mangle anything in the foregoing.  I
>> have seen weird copypaste behaviour mess up decomposed characters.  I
>> thought of this after I searched for and collected some visually
>> fascinating phrases; so I tried to normalize these to NFC...  It should go
>> without saying, easyseed output the Japanese perfectly!)
>>
>>
>> --
>> 

Re: [bitcoin-dev] BIP 39: Add language identifier strings for wordlists

[Greg Sanders via bitcoin-dev]

Let me re-phrase: Is it a known thing for users to actually use it?

On Mon, Jan 8, 2018 at 9:52 AM, Matias Alejo Garcia 
wrote:

>
>
> On Mon, Jan 8, 2018 at 11:34 AM, Greg Sanders via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Has anyone actually used the multilingual support in bip39?
>>
>
>
> Copay (and all its clones) use it.
>
>
>
>
>
>>
>> If a feature of the standard has not been(widely?) used in years, and
>> isn't supported in any major wallet(?), it seems indicative it was a
>> mistake to add it in the first place, since it's a footgun in the making
>> for some poor sap who can't even read English letters when almost all
>> documentation is written in English.
>>
>> On Mon, Jan 8, 2018 at 6:13 AM, nullius via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> On 2018-01-08 at 07:35:52 +, 木ノ下じょな  wrote:
>>>
 This is very sad.

 The number one problem in Japan with BIP39 seeds is with English words.

 I have seen a 60 year old Japanese man writing down his phrase (because
 he kept on failing recovery), and watched him write down "aneter" for
 "amateur"...

 [...]

 If you understand English and can spell, you read a word, your brain
 processes the word, and you can spell it on your own when writing down.
 Not many Japanese people can do that, so they need to copy letter for
 letter, taking a long time, and still messing up on occasion.

 [...]

 Defining "everyone should only use English, because ASCII is easier to
 plan for" is not a good way to move forward as a currency.

>>>
>>> Well said.  Thank you for telling of these experiences.  Now please,
>>> let’s put the shoe on the other foot.
>>>
>>> I ask everybody who wants an English-only mnemonic standard to entrust
>>> *their own money* to their abilities to very, very carefully write this
>>> down—then later, type it back in:
>>>
>>> すさん たんろ りゆう しもん ていおん しとう
>>> とこや はやい おうさま ほくろ けちゃっふ たもつ
>>>
>>> (Approximate translation:  “Whatever would you do if Bitcoin had been
>>> invented by somebody named Satoshi Nakamoto?”)
>>>
>>> No, wait:  That is only a 12-word mnemonic.  We are probably talking
>>> about a Trezor; so now, hey you there, stake the backup of your life’s
>>> savings on your ability to handwrite *this*:
>>>
>>> にあう しひょう にんすう ひえる かいこう いのる ねんし はあさん ひこく
>>> とうく きもためし そなた こなこな にさんかたんそ ろんき めいあん みわく
>>> へこむ すひょう おやゆひ ふせく けさき めいきょく こんまけ
>>>
>>> Ready to bet your money on *that* as a backup phrase in your own hands?
>>> No?  Then please, stop demanding that others risk *their* money on the
>>> inverse case.
>>>
>>> 
>>>
>>> If you cheat here by having studied Japanese, then remember that many
>>> Japanese people know English and other European languages, too.  Then think
>>> of how much money would be lost by your non-Japanese-literate family and
>>> friends—if BIP 39 had only Japanese wordlists, and your folks needed to
>>> wrestle with the above phrases as their “mnemonics”.
>>>
>>> In such cases, the phrases cannot be called “mnemonics” at all.  A
>>> “mnemonic” implies aid to memory.  Gibberish in a wholly alien writing
>>> system is much worse even than transcribing pseudorandom hex strings.  The
>>> Japanese man in the quoted story, who wrote “aneter” for “amateur”, was not
>>> dealing with a *mnemonic*:  He was using the world’s most inefficient means
>>> of making cryptic bitstrings *less* userfriendly.
>>>
>>> 
>>>
>>> I began this thread with a quite simple request:  Is “日本語” an
>>> appropriate string for identifying the Japanese language to Japanese
>>> users?  And what of the other strings I posted for other languages?
>>>
>>> I asked this as an implementer working on my own instance of the
>>> greatest guard against vendor lock-in and stale software:  Independent
>>> implementations.  —  I asked, because obviously, I myself do not speak all
>>> these different languages; and I want to implement them all.  *All.*
>>>
>>> Some replies have been interesting in their own right; but thus far,
>>> nobody has squarely addressed the substance of my question.
>>>
>>> Most worrisome is that much of the discussion has veered into criticism
>>> of multi-language support.  I opened with a question about other languages,
>>> and I am getting replies which raise a hue and cry of “English only!”
>>>
>>> Though I am fluent and literate in English, I am uninterested in ever
>>> implementing any standard of this nature which is artificially restricted
>>> to English.  I am fortunate; for as of this moment, we have a standard
>>> called “BIP 39” which has seven non-English wordlists, and four more
>>> pending in open pull requests (#432, #442, #493, #621).
>>>
>>> I request discussion of language identification strings appropriate for
>>> use with that standard.
>>>
>>> (P.S., I hope that my system did not mangle anything in the foregoing.
>>> I have seen weird copypaste 

Re: [bitcoin-dev] BIP 39: Add language identifier strings for wordlists

[Greg Sanders via bitcoin-dev]

Has anyone actually used the multilingual support in bip39?

If a feature of the standard has not been(widely?) used in years, and isn't
supported in any major wallet(?), it seems indicative it was a mistake to
add it in the first place, since it's a footgun in the making for some poor
sap who can't even read English letters when almost all documentation is
written in English.

On Mon, Jan 8, 2018 at 6:13 AM, nullius via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On 2018-01-08 at 07:35:52 +, 木ノ下じょな  wrote:
>
>> This is very sad.
>>
>> The number one problem in Japan with BIP39 seeds is with English words.
>>
>> I have seen a 60 year old Japanese man writing down his phrase (because
>> he kept on failing recovery), and watched him write down "aneter" for
>> "amateur"...
>>
>> [...]
>>
>> If you understand English and can spell, you read a word, your brain
>> processes the word, and you can spell it on your own when writing down.
>> Not many Japanese people can do that, so they need to copy letter for
>> letter, taking a long time, and still messing up on occasion.
>>
>> [...]
>>
>> Defining "everyone should only use English, because ASCII is easier to
>> plan for" is not a good way to move forward as a currency.
>>
>
> Well said.  Thank you for telling of these experiences.  Now please, let’s
> put the shoe on the other foot.
>
> I ask everybody who wants an English-only mnemonic standard to entrust
> *their own money* to their abilities to very, very carefully write this
> down—then later, type it back in:
>
> すさん たんろ りゆう しもん ていおん しとう
> とこや はやい おうさま ほくろ けちゃっふ たもつ
>
> (Approximate translation:  “Whatever would you do if Bitcoin had been
> invented by somebody named Satoshi Nakamoto?”)
>
> No, wait:  That is only a 12-word mnemonic.  We are probably talking about
> a Trezor; so now, hey you there, stake the backup of your life’s savings on
> your ability to handwrite *this*:
>
> にあう しひょう にんすう ひえる かいこう いのる ねんし はあさん ひこく
> とうく きもためし そなた こなこな にさんかたんそ ろんき めいあん みわく
> へこむ すひょう おやゆひ ふせく けさき めいきょく こんまけ
>
> Ready to bet your money on *that* as a backup phrase in your own hands?
> No?  Then please, stop demanding that others risk *their* money on the
> inverse case.
>
> 
>
> If you cheat here by having studied Japanese, then remember that many
> Japanese people know English and other European languages, too.  Then think
> of how much money would be lost by your non-Japanese-literate family and
> friends—if BIP 39 had only Japanese wordlists, and your folks needed to
> wrestle with the above phrases as their “mnemonics”.
>
> In such cases, the phrases cannot be called “mnemonics” at all.  A
> “mnemonic” implies aid to memory.  Gibberish in a wholly alien writing
> system is much worse even than transcribing pseudorandom hex strings.  The
> Japanese man in the quoted story, who wrote “aneter” for “amateur”, was not
> dealing with a *mnemonic*:  He was using the world’s most inefficient means
> of making cryptic bitstrings *less* userfriendly.
>
> 
>
> I began this thread with a quite simple request:  Is “日本語” an appropriate
> string for identifying the Japanese language to Japanese users?  And what
> of the other strings I posted for other languages?
>
> I asked this as an implementer working on my own instance of the greatest
> guard against vendor lock-in and stale software:  Independent
> implementations.  —  I asked, because obviously, I myself do not speak all
> these different languages; and I want to implement them all.  *All.*
>
> Some replies have been interesting in their own right; but thus far,
> nobody has squarely addressed the substance of my question.
>
> Most worrisome is that much of the discussion has veered into criticism of
> multi-language support.  I opened with a question about other languages,
> and I am getting replies which raise a hue and cry of “English only!”
>
> Though I am fluent and literate in English, I am uninterested in ever
> implementing any standard of this nature which is artificially restricted
> to English.  I am fortunate; for as of this moment, we have a standard
> called “BIP 39” which has seven non-English wordlists, and four more
> pending in open pull requests (#432, #442, #493, #621).
>
> I request discussion of language identification strings appropriate for
> use with that standard.
>
> (P.S., I hope that my system did not mangle anything in the foregoing.  I
> have seen weird copypaste behaviour mess up decomposed characters.  I
> thought of this after I searched for and collected some visually
> fascinating phrases; so I tried to normalize these to NFC...  It should go
> without saying, easyseed output the Japanese perfectly!)
>
>
> --
> null...@nym.zone | PGP ECC: 0xC2E91CD74A4C57A105F6C21B5A00591B2F307E0C
> Bitcoin: bc1qcash96s5jqppzsp8hy8swkggf7f6agex98an7h | (Segwit nested:
> 3NULL3ZCUXr7RDLxXeLPDMZDZYxuaYkCnG)  (PGP RSA: 0x36EBB4AB699A10EE)
> “‘If you’re not doing anything wrong, you have nothing to hide.’

Re: [bitcoin-dev] Satoshilabs secret shared private key scheme

[nullius via bitcoin-dev]

On 2018-01-08 at 04:22:43 + Gregory Maxwell  wrote:
I'm happy to see that there is no obvious way to abuse this one as a 
brainwallet scheme!


BIP 39 was designed to make brainwallets secure!  If a user generates a 
weakling 12-word mnemonic from 16 tiny octets of entropy drawn off the 
non-artistic /dev/urandom, then protects its seed with a creative 
passphrase haiku about the power of human stupidity, then the result 
will have a 128-bit security level.  PROVE ME WRONG.


--
null...@nym.zone | PGP ECC: 0xC2E91CD74A4C57A105F6C21B5A00591B2F307E0C
BIP 39 tool in progress, currently growing brainw^H^H^H^H^Hpassphrase 
support to help poor /dev/urandom: https://github.com/nym-zone/easyseed

Bitcoin: bc1qcash96s5jqppzsp8hy8swkggf7f6agex98an7h


signature.asc
Description: PGP signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP 39: Add language identifier strings for wordlists

[nullius via bitcoin-dev]

On 2018-01-08 at 07:35:52 +, 木ノ下じょな  
wrote:

This is very sad.

The number one problem in Japan with BIP39 seeds is with English words.

I have seen a 60 year old Japanese man writing down his phrase (because 
he kept on failing recovery), and watched him write down "aneter" for 
"amateur"...


[...]

If you understand English and can spell, you read a word, your brain 
processes the word, and you can spell it on your own when writing down.  
Not many Japanese people can do that, so they need to copy letter for 
letter, taking a long time, and still messing up on occasion.


[...]

Defining "everyone should only use English, because ASCII is easier to 
plan for" is not a good way to move forward as a currency.


Well said.  Thank you for telling of these experiences.  Now please, 
let’s put the shoe on the other foot.


I ask everybody who wants an English-only mnemonic standard to entrust 
*their own money* to their abilities to very, very carefully write this 
down—then later, type it back in:


すさん　たんろ　りゆう　しもん　ていおん　しとう
とこや　はやい　おうさま　ほくろ　けちゃっふ　たもつ

(Approximate translation:  “Whatever would you do if Bitcoin had been 
invented by somebody named Satoshi Nakamoto?”)


No, wait:  That is only a 12-word mnemonic.  We are probably talking 
about a Trezor; so now, hey you there, stake the backup of your life’s 
savings on your ability to handwrite *this*:


にあう　しひょう　にんすう　ひえる　かいこう　いのる　ねんし　はあさん　ひこく
とうく　きもためし　そなた　こなこな　にさんかたんそ　ろんき　めいあん　みわく
へこむ　すひょう　おやゆひ　ふせく　けさき　めいきょく　こんまけ

Ready to bet your money on *that* as a backup phrase in your own hands?  
No?  Then please, stop demanding that others risk *their* money on the 
inverse case.




If you cheat here by having studied Japanese, then remember that many 
Japanese people know English and other European languages, too.  Then 
think of how much money would be lost by your non-Japanese-literate 
family and friends—if BIP 39 had only Japanese wordlists, and your folks 
needed to wrestle with the above phrases as their “mnemonics”.


In such cases, the phrases cannot be called “mnemonics” at all.  A 
“mnemonic” implies aid to memory.  Gibberish in a wholly alien writing 
system is much worse even than transcribing pseudorandom hex strings.  
The Japanese man in the quoted story, who wrote “aneter” for “amateur”, 
was not dealing with a *mnemonic*:  He was using the world’s most 
inefficient means of making cryptic bitstrings *less* userfriendly.




I began this thread with a quite simple request:  Is “日本語” an 
appropriate string for identifying the Japanese language to Japanese 
users?  And what of the other strings I posted for other languages?


I asked this as an implementer working on my own instance of the 
greatest guard against vendor lock-in and stale software:  Independent 
implementations.  —  I asked, because obviously, I myself do not speak 
all these different languages; and I want to implement them all.  *All.*


Some replies have been interesting in their own right; but thus far, 
nobody has squarely addressed the substance of my question.


Most worrisome is that much of the discussion has veered into criticism 
of multi-language support.  I opened with a question about other 
languages, and I am getting replies which raise a hue and cry of 
“English only!”


Though I am fluent and literate in English, I am uninterested in ever 
implementing any standard of this nature which is artificially 
restricted to English.  I am fortunate; for as of this moment, we have a 
standard called “BIP 39” which has seven non-English wordlists, and four 
more pending in open pull requests (#432, #442, #493, #621).


I request discussion of language identification strings appropriate for 
use with that standard.


(P.S., I hope that my system did not mangle anything in the foregoing.  
I have seen weird copypaste behaviour mess up decomposed characters.  I 
thought of this after I searched for and collected some visually 
fascinating phrases; so I tried to normalize these to NFC...  It should 
go without saying, easyseed output the Japanese perfectly!)


--
null...@nym.zone | PGP ECC: 0xC2E91CD74A4C57A105F6C21B5A00591B2F307E0C
Bitcoin: bc1qcash96s5jqppzsp8hy8swkggf7f6agex98an7h | (Segwit nested:
3NULL3ZCUXr7RDLxXeLPDMZDZYxuaYkCnG)  (PGP RSA: 0x36EBB4AB699A10EE)
“‘If you’re not doing anything wrong, you have nothing to hide.’
No!  Because I do nothing wrong, I have nothing to show.” — nullius


signature.asc
Description: PGP signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Satoshilabs secret shared private key scheme

[Pavol Rusnak via bitcoin-dev]

On 08/01/18 13:45, Peter Todd wrote:
> Can you explain _exactly_ what scenario the "plausible deniability" feature
> refers to?


https://doc.satoshilabs.com/trezor-user/advanced_settings.html#multi-passphrase-encryption-hidden-wallets


-- 
Best Regards / S pozdravom,

Pavol "stick" Rusnak
CTO, SatoshiLabs



signature.asc
Description: OpenPGP digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Satoshilabs secret shared private key scheme

[Peter Todd via bitcoin-dev]

On Mon, Jan 08, 2018 at 01:39:20PM +0100, Pavol Rusnak via bitcoin-dev wrote:
> > The construction also
> > will silently result in the user getting a different private key if
> > they enter the wrong passphrase-- which could lead to funds loss.
> 
> Again, this is by design and it is main point why plausible deniability
> is achieved both in BIP39 and SLIP39. If we used a different
> construction we'd loose plausible deniability.

Can you explain _exactly_ what scenario the "plausible deniability" feature
refers to?

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org


signature.asc
Description: Digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Satoshilabs secret shared private key scheme

[Pavol Rusnak via bitcoin-dev]

On 08/01/18 05:22, Gregory Maxwell wrote:
>> https://github.com/satoshilabs/slips/blob/master/slip-0039.md

Hey Gregory!

Thanks for looking into the scheme. I appreciate your time!

> This specification forces the key being used through a one way
> function, -- so you cannot take a pre-existing key and encode it with
> this scheme.

Originally, we used a bi-directional function to be able to encode and
decode the key in both directions using the passphrase. We stretched the
passphrase using KDF and then applied AES or other symmetric cipher

We found the following (theoretical) problem:

If an attacker has knowledge of few words from the beginning of shares,
they are able to reconstruct the beginning of the master secret and if
the size of the reconstruced master secret is bigger then the cipher
blocksize (for block ciphers; for stream ciphers 1 bit is enough), then
they can reconstruct the beginning of the seed.

Can you find a scheme which does not have this problem? Or you think
this problem is not worth solving?

> The KDF it specifies is unconfigurable and fairly weak
> (2xhmac-sha2-- which can be cracked at about 0.7M passwords a
> second on a single motherboard GPU cracker).

Yes. We want this to be possible to be computed on TREZOR-like devices
on boot, similarly how we compute BIP39 on boot right now.

> The construction also
> will silently result in the user getting a different private key if
> they enter the wrong passphrase-- which could lead to funds loss.

Again, this is by design and it is main point why plausible deniability
is achieved both in BIP39 and SLIP39. If we used a different
construction we'd loose plausible deniability.

> It
> is again, unversioned-- so it kinda of seems like it is intentionally
> constructed in a way that will prevent interoperable use, since the
> lack of versioning was a primary complaint from other perspective
> users.  Of course, it fine if you want to make a trezor only thing,
> but why bother BIPing something that was not intended for
> interoperability?  Even for a single vendor spec the lack of
> versioning seems to make things harder to support new key-related
> features such as segwit.

This is argument I keep having all the time.

Suppose we'd introduce a version to encode PBKDF2 rounds or even
different KDFs. We'll end up with different SLIP39 mnemonics, but they
will not be compatible among implementations (because TREZOR can only up
to 100.000 rounds of PBKDF2 and does not support Argon2 at all, while
other desktop implementation would rather use memory-hard Argon2).

My gut feeling is that this would lead to WORSE interoperability, not
better. Look at BIP32 for example. There are lots of wallet that claim
they are BIP32 compatible, but in reality they use different paths, so
they are not compatible. BIP32 is a good standard, but in reality
"BIP32-compatible" does not mean anything, whereas when you say the
wallet is "BIP44-compatible" you can be sure the migration path works.

> The 16-bit "checksum" based on sha2 seems pretty poor since basing
> small checksums on a cryptographic hash results in a fairly poor
> checksum that is surprisingly likely to accept an errored string. Your
> wordlist is 10 bits and you have much less than 1023*10 bits of input,
> so you could easily have a 20 bit code (two words) which guaranteed
> that up to two errored words would always be detected, and probably
> could choose one which catches three words much more often 1:2^20
> (sipa's crc tools can help find codes like this).

Originally, we wanted to use 16-bit of CRC32 for checksum, but after the
discussion with Daan Sprenkels we were suggested to change this for
cryptographically strong function. The argument was that CRC32 contains
less entropy and mixing high-entropy data (secret) with low-entropy data
(checksum) is not a good idea.

Also, there is an argument between a checksum and ECC. We discussed that
ECC might not be a good idea, because it helps the attacker to compute
missing information, while we only want to check for integrity. Also the
word mnemonic is itself a ECC, because if you see the word "acadornic"
it is probably the word "academic".

> The metadata seems to make fairly little affordance to help users
> avoid accidentally mixing shares from distinct sharings of the same
> key. Is it the idea that this is the only likely cause of a checksum
> error? (1:2^16 chance of silently returning the wrong key seems kinda
> bad). -- I'm not sure much could be done here, though, since
> additional payload is precious.

Yes, checksum is supposed to prevent that.

> As an aside, your specification might want to give some better advice
> about the SSS since my experience virtually everyone gets it wrong in
> ways that degrade or destroy its properties e.g. many fail to generate
> the additional coefficients of the polynominal randomly which results
> in insecurity (see armory for an example).   Oh, also, I believe it is
> normally refereed to as