<unnamed>

Public Key

npub1umcywfan64dcuxeycrujenkhh3n3yutyc3x5ewprtjr0c7a7kxqsgk2hgv

Profile Code

nprofile1qqswduz8y7ea2kuwrvjvp7fvemtmcecjw9jvgn2vhq34ephu0wltrqgpz4mhxue69uhhyetvv9ujumn0wd68ytnwv46qzrthwden5te0dehhxtnvdakqtj483a

Publishing to

relay.nostr.net

nos.lol

Last Notes

2023-06-07 20:09:43 CEST

- reply

📅 Original date posted:2018-01-12
📝 Original message:On 2018-01-12 at 09:50:58 +0000, Peter Todd <pete at petertodd.org> wrote:
>On Tue, Jan 09, 2018 at 12:43:48PM +0000, Perry Gibson wrote:
>>>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.
>>The passphrase scheme as I understand it allows a maximum of 50
>>characters to be used. Surely even with the HD seed, that search
>>space is too large to brute force. Or is there a weakness in the
>>scheme I haven't clocked?
>
>While passphrases *can* be long, most user's aren't going to understand
>the risk. For example, Trezors blog(1) doesn't make it clear that the
>passphrases could be bruteforced and used as evidence against you, and
>even suggests the contrary: [...quote...]
I despise the term “plausible deniability”; and that’s really the wrong
term to use in this discussion.
“Plausible deniability” is a transparent excuse for explaining away an
indisputable fact which arouses suspicion—when you got some serious
’splain’ to do. This is usually used in the context of some pseudolegal
argument about introducing “reasonable doubt”, or even making “probable
cause” a wee bit less probable.
“Why yes, officer: I was seen carrying an axe down the street near the
site of an axe murder, at approximately the time of said axe murder.
But I do have a fireplace; so it is plausible that I was simply out
gathering wood.”
I rather suspect the concept of “plausible deniability” of having been
invented by a detective or agent provocateur. There are few concepts
more useful for helping suspects shoot themselves in the foot, or
frankly, for entrapping people.
One of the worst examples I have seen is in discussions of Monero,
whereby I’ve seen proponents claim that even under the worst known
active attacks, their mix scheme reduces transaction linking to a
maximum of 20–40% probability. “That’s not good enough to convince a
jury!” No, but it is certainly adequate for investigators to identify
you as a person of interest. Then, your (mis)deeds can be subjected to
powerful confirmation attacks based on other data; blockchains do not
exist in isolation. I usually stay out of such discussions; for I have
no interest in helping the sorts of people whose greatest concern in
life is what story to foist on a jury.
In the context of devices such as Trezor, what is needed is not
“plausible deniability”, but rather the ability to obviate any need to
deny anything at all. I must repeat, information does not exist in
isolation.
If you are publicly known to be deepy involved in Bitcoin, then nobody
will believe that your one-and-only wallet contains only 0.01 BTC.
That’s not even “plausible”. But if you have overall privacy practices
which leave nobody knowing or suspecting that you have any Bitcoin at
all, then there is nothing to “deny”; and should a Trezor with
(supposedly) 0.01 BTC be found in your possession, that’s much better
than “plausible”. It’s completely unremarkable.
Whereas if you are known or believed to own large amounts of BTC, a
realistic bad guy’s response to your “decoy” wallet could be, “I don’t
believe you; and it costs me nothing to keep beating you with rubber
hose until you tell me the *real* password.”
It could be worse, too. In a kidnapping scenario, the bad guys could
say, “I don’t believe you. Hey, I also read Trezor’s website about
‘plausible deniability’. Now, I will maim your kid for life just to
test whether you told me the *real* password. And if you still don’t
tell me the real password after you see that little Johnny can no longer
walk, then I will kill him.”
The worst part is that you have no means of proving that you really
*did* give the real password. Indeed, it can be proved if you’re lying
by finding a password which reveals a hidden wallet—but *you* have no
means of affirmatively proving that you are telling the truth! If the
bad guys overestimated your riches (or if they’re in a bad mood), then
little Johnny is dead either way.
In a legalistic scenario, if “authorities” believe you have 1000 BTC and
you only reveal a password for 0.01 BTC, the likely response will not be
to let you go. Rather, “You will now sit in jail until you tell the
*real* password.” And again: You have no means of proving that you did
give the real password!
“Plausible deniability” schemes can backfire quite badly.
>Also note how this blog doesn't mention anti-forensics: the wallet
>software itself may leave traces of the other wallets on the computer.
>Have they really audited it sufficiently to be sure this isn't the
>case?
What about data obtained via the network? I don’t *only* refer to
dragnet surveillance. See for but one e.g., Goldfelder, et al., “When
the cookie meets the blockchain: Privacy risks of web payments via
cryptocurrencies” https://arxiv.org/abs/1708.04748 Your identity can be
tied to your wallet all sorts of ways, any of which could be used to
prove that you have more Bitcoin than you’re revealing. Do you know
what databases of cross-correlated analysis data customs agents have
immediate access to nowadays—or will, tomorrow? I don’t.
In the scenario under discussion, that may not immediately prove “beyond
a reasonable doubt” that you lied specifically about your Trezor. But
it could give plenty of cause to keep you locked up in a small room
while your hard drive is examined for evidence that Trezor apps handled
*addresses already known to be linked to you*. Why even bother with
bruteforce? Low-hanging fruit abound.
>1) https://blog.trezor.io/hide-your-trezor-wallets-with-multiple-passphrases-f2e0834026eb
--
nullius at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180112/862e70b3/attachment.sig>

2023-06-07 20:09:26 CEST

- reply

📅 Original date posted:2018-01-08
📝 Original message:On 2018-01-08 at 04:22:43 +0000 Gregory Maxwell <greg at xiph.org> 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.
--
nullius at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180108/1992463a/attachment-0001.sig>

2023-06-07 20:09:15 CEST

- reply

📅 Original date posted:2018-01-05
📝 Original message:On 2018-01-05 at 16:04:10 +0000, Sjors Provoost <sjors at sprovoost.nl>
wrote:
>I’m not a fan of language specific word lists within the current BIP-39
>standard. Very few wallets support anything other than English, which
>can lead to vendor lock-in and long term loss of funds if a rare
>non-English wallet disappears.
>
>However, because people can memorize things better in their native
>tongue, supporting multiple languages seems quite useful.
>
>I would prefer a new standard [...] A replacement for BIP-39 [...]
>
>[snip]
>For my above point and some related ideas, see:
>https://github.com/satoshilabs/slips/issues/103
You present some interesting ideas; and I will be much interested in the
Github issue you referenced—thanks for that. However, this discussion
is *far* beyond the scope of my simple proposal and request to add
standardized native language and short-ASCII identifier strings to the
BIP repository. I suggest that readers solely interested in the
existing BIP 39 standard and its direct application to Bitcoin should
stop reading right here.
----
That being said, I should briefly address some of the issues you raise
(with further discussion best continued elsewhere):
I *strongly* urge the importance of language-specific standardized
wordlists. Even an individual who has secondarily acquired reasonable
fluency in English will most likely have the least difficulty
memorizing, transcribing, and otherwise handling a “mother-tongue”
mnemonic. Such an advantage is important in applications whereby even
slight errors can be fatal, and every bit counts. This is to say
nothing of persons who have limited or no English-language knowledge.
Yet for multiple reasons, multilanguage support is only feasible with
standardization. Wordlist creation is a highly specialized task.
Independent implementation of standards is imperative for avoiding
implementation lock-in; and independent implementors (such as I) would
be unable to create sets multi-language wordlists on their own, anyway.
For a view of the language-specific process involved in creating a
wordlist, I invite everybody following this discussion to review BIP
repository PRs #92, #130 (Japanese); #100 (Spanish); #114 (Chinese, both
variants); #152 (French); #306 (Italian); #544 (Korean, rejected); and
#570 (Korean). The rejection of #544 for Korean, and its superseding
with #570 is particularly instructive.
With standardized wordlists, independent implementation is easy. In my
own implementation, the language switching backend (excluding the UI[1])
for multilingual mnemonic generation required only relatively small C
code changes, as seen here[0]:
[0] https://github.com/nym-zone/easyseed/commit/5b6a6668458d96d6ccc4bf19e4fd40fe6ea72fec#diff-20dcf1782b7568b85ea01ed695abeb02
[1] https://github.com/nym-zone/easyseed/commit/1a6e48bbdac9366d9d5d1912dc062dfc3f0db2c6#diff-20dcf1782b7568b85ea01ed695abeb02
Admittedly, the multilingual requirements for seed generation will take
a bit more; and my nonstandard, non-BIP39 ideas which require decoding
words directly back to bits will take yet more. But it is still not
problematic.
I only began writing this tool one week ago, as of today; and it has
been a side project requiring small amounts of time, not a full-time
dedicated task. When I fully complete all aspects of seed generation,
then users will have the option of another simple open-source tool which
*will* be able to output a binary or BIP-32-formatted (“xprv”) 512-bit
seed, given input of an existing mnemonic in any language supported by
official BIP 39 wordlists. Output can then be imported to any wallet
software which supports BIP 32, regardless of the wallet’s langauge
support (and whether or not the wallet supports BIP 39 at all).
**The ease of creating such tools squarely answers your concerns about
vendor lock-in.** And yes, it’s easy. I can attest as a lone coder,
it’s easy for me to create “easyseed” as a side project!
Finally, aside: In the discussion at SLIP repository issue #103, I see
mention of m-of-n SSSS. I have been mentally whiteboarding just such an
application involving mnemonics. Watch for it. <g> It is likely that
I will crib the BIP 39 wordlists, given the impossibility that I could
create my own set of wordlists in many languages. I only wish that the
BIP repository had support for more languages. More! Adding each new
language to my implementation(s) will require approximately one-line
code changes for me.
(Aside further: Why is there not a Dutch wordlist? I should like to
add that, please—meneer Provoost. More wordlists!)
Aside still yet further: Should you be interested in more general
applications of mnemonic phrases for pseudorandom strings, I think you
will like this future feature which currently exists only as an Easter
egg, (un)documented in my commit log:
https://github.com/nym-zone/easyseed/commit/ba77be1b1a1f0c6af50ceba5c89f4adece7e5dff
Further discussion is invited by private mail, in an appropriate public
venue, or otherwise not on a bitcoin-dev thread which makes a simple
request and proposal as to the existing BIP 39 standard—thanks.
--
nullius at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180105/7673c033/attachment.sig>

2023-06-07 20:09:15 CEST

- reply

📅 Original date posted:2018-01-05
📝 Original message:I propose and request as an enhancement that the BIP 39 wordlist set
should specify canonical native language strings to identify each
wordlist, as well as short ASCII language codes. At present, the
languages are identified only by their names in English.
Strings properly vetted and recommended by native speakers should
facilitate language identification in user interface options or menus.
Specification of language identifier strings would also promote
interface consistency between implementations; this may be important if
a user creates a mnemonic in Implementation A, then restores a wallet
using that mnemonic in Implementation B.
As an independent implementer who does not know *all* these different
languages, I monkey-pasted language-native strings from a popular wiki
site. I cannot guarantee that they be all accurate, sensible, or even
non-embarrassing.
https://github.com/nym-zone/easyseed/blob/1a6e48bbdac9366d9d5d1912dc062dfc3f0db2c6/easyseed.c#L99
```
LANG(english, u8"English", "en", ascii_space ),
LANG(chinese_simplified, u8"汉语", "zh-CN",ascii_space ),
LANG(chinese_traditional, u8"漢語", "zh-TW",ascii_space ),
LANG(french, u8"Français", "fr", ascii_space ),
LANG(italian, u8"Italiano", "it", ascii_space ),
LANG(japanese, u8"日本語", "ja", u8"\u3000" ),
LANG(korean, u8"한국어", "ko", ascii_space ),
LANG(spanish, u8"Español", "es", ascii_space )
```
Per the comment at #L85 of the quoted file, I also know that for my
short identifiers for Chinese, “zh-CN” and “zh-TW”, are imprecise at
best—insofar as Hong Kong uses Traditional; and overseas Chinese may use
either. For differentiating the two Chinese writing variants, are there
any appropriate standardized or customary short ASCII language IDs
similar to ISO 3166-1 alpha-2 which are purely linguistic, and not fit
to present-day political boundaries?
My general suggestion is that the specification of appropriate strings
in bitcoin:bips/bip-0039/bip-0039-wordlists.md be made part of the
process for accepting new wordlists. My specific request is that such
strings be ascertained for the wordlists already existing, preferably
from the persons involved in the original pull requests therefor.
Should this proposal be “concept ACKed” by appropriate parties, then I
may open a pull request suggesting an appropriate format for specifying
this information in the repository. However, I will must needs leave
the vetting of appropriate strings to native speakers or experts in the
respective languages.
Prior references: The wordlist additions at PRs #92, #130 (Japanese);
#100 (Spanish); #114 (Chinese, both variants); #152 (French); #306
(Italian); #570 (Korean); #621 (Indonesian, *proposed*, open).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180105/c0a9128b/attachment.sig>