easyseed(1) secure, multilanguage tool for BIP 39 mnemonic & seed, BIP 32 xprv

[nullius]

I have released an initial version of the easyseed(1) utility for secure generation of BIP 39 mnemonic phrases, BIP 39 seeds, and BIP 32 master extended private keys (“xprv”).  As any worthwhile software, it comes replete with a manpage, q.v.  It generates mnemonic phrases in these languages and writing systems:

• Chinese (Simplified) (汉语)
• Chinese (Traditional) (漢語)
• English [default]
• French (Français)
• Italian (Italiano)
• Japanese (日本語)
• Korean (한국어)
• Spanish (Español)

My original motivation for writing this was that I needed a lightweight, reliable BIP 39 mnemonic phrase generator with easily auditable sources and minimal dependencies for use on a stripped-down airgap machine.  The source code is concise, easy to read, and lovingly commented; it can be readily understood by anybody with a basic knowledge of the C programming language.  Its only external dependencies are cc(1), make(1), and libcrypto.

Now that it’s written, easyseed(1) is also the first necessary component for my campaign to urge that users stop using saved webpages to generate their Bitcoin magic bits.  What kind of an airgap machine has a web browser installed, anyway?  But most importantly, as a rule of thumb, Javascript code cannot reliably acquire proper entropy for generating random numbers.  This is a persistent general problem, and specifically subject to extended fretting by the author[1] of the most popular BIP39 webpage.

easyseed(1) reads bits straight off /dev/urandom, or from user-provided keymat.  Gathering and processing of entropy is properly the kernel’s job.  My userland utility will let the kernel do its job.  Since it’s written in C, easyseed(1) can reliably obtain kernel-provided randomness on every Unix/Linux platform in about two lines of code (open(2), read(2), plus error checks)—rather than cooking up some tortuous “random” scheme which may or may not perhaps probably work sort-of.

This is a beta-quality initial release.  It is not yet feature-complete:  In particular, I have code partly written to add support for all languages which have wordlists in the Bitcoin BIP repository (currently Chinese (Simplified and Traditional), French, Italian, Japanese, Korean, and Spanish, in addition to the current English). — Done!  This is now approaching release candidate status, almost ready for Version 1.

Licensing includes a Bitcoin Consensus Clause, to prevent use by scamcoin pretenders.

I am here opening a Bitcoin Forum thread for discussion of this utility; over time, I will edit and update this post as appropriate.

1. Though that is not nearly in the same league as boneheaded absurdity from ignorant developers who confuse multiple distinct meanings of the word “entropy”.  pointbiz: “Perhaps more entropy can be gathered using techniques used on Panopticlick”.  #facepalm  cantonbecker: “I like this idea”.  pointbiz: “I used all the easy techniques from Panopticlick to gather entropy. [...] I added up the low and high entropy bits and my personal results are 34.3 to 42.8 bits of entropy.”  Oh dear heavens, are you using this to generate keymat for Bitcoin!?  Some people should be enjoined with a permanent restraining order forbidding that they ever approach within one hundred metres of crypto-related code.

[1714772307]

1714772307

[1714772307]

1714772307

[1714772307]

1714772307

[1714772307]

1714772307

[1714772307]

1714772307

[Spendulus]

I have released an initial version of the easyseed(1) utility for secure generation of BIP 39 mnemonic seed phrases.  As any worthwhile software, it comes replete with a manpage, q.v.

My original motivation for writing this was that I needed a lightweight, reliable BIP 39 seed phrase generator with easily auditable sources and minimal dependencies for use on a stripped-down airgap machine.  The source code is short, easy to read, and lovingly commented; it can be readily understood by anybody with a basic knowledge of the C programming language.  Its only dependencies are cc(1), make(1), and a library SHA256 implementation—available on most platforms via libcrypto or otherwise.

Now that it’s written, easyseed(1) is also the first necessary component for my campaign to urge that users stop using saved webpages to generate their Bitcoin magic bits.  What kind of an airgap machine has a web browser installed, anyway?  But most importantly, as a rule of thumb, Javascript code cannot reliably acquire proper entropy for generating random numbers.  This is a persistent general problem, and specifically subject to extended fretting by the author[1] of the most popular BIP39 webpage.

easyseed(1) reads bits straight off /dev/urandom, or from user-provided keymat.  Gathering and processing of entropy is properly the kernel’s job.  My userland utility will let the kernel do its job.  Since it’s written in C, easyseed(1) can reliably obtain kernel-provided randomness on every Unix/Linux platform in about two lines of code (open(2), read(2), plus error checks)—rather than cooking up some tortuous “random” scheme which may or may not perhaps probably work sort-of.

This is a beta-quality initial release.  It is not yet feature-complete:  In particular, I have code partly written to add support for all languages which have wordlists in the Bitcoin BIP repository (currently Chinese (Simplified and Traditional), French, Italian, Japanese, Korean, and Spanish, in addition to the current English).  easyseed(1) does have basic test vectors copied from the Trezor repository; and with those vectors, it runs a self-test on every usage.  However, more tests are desired.

Licensing includes a Bitcoin Consensus Clause, to prevent use by scamcoin pretenders.

I am here opening a Bitcoin Forum thread for discussion of this utility; over time, I will edit and update this post as appropriate.

1. Though that is not nearly in the same league as boneheaded absurdity from ignorant developers who confuse multiple distinct meanings of the word “entropy”.  pointbiz: “Perhaps more entropy can be gathered using techniques used on Panopticlick”.  #facepalm  cantonbecker: “I like this idea”.  pointbiz: “I used all the easy techniques from Panopticlick to gather entropy. [...] I added up the low and high entropy bits and my personal results are 34.3 to 42.8 bits of entropy.”  Oh dear heavens, are you using this to generate keymat for Bitcoin!?  Some people should be enjoined with a permanent restraining order forbidding that they ever approach within one hundred metres of crypto-related code.

I like this idea you have.

Personally I am a believer in the entropic properties of dice.

Also your comments lead me to point out a serious flaw in the use of off line web pages.

Namely, shouldn't such a web page (a computer program) not operate unless it was off line?

[nullius]

I like this idea you have.

Personally I am a believer in the entropic properties of dice.

Thanks.  I also like dice, especially via hardcoded output from a fair die roll of 4.  But after you have already gathered some random numbers, consider this food for thought:

If you’ve somehow managed to generate one secure 256-bit key then from that key you can derive all the ‘random’ numbers you’ll ever need for every cryptographic protocol...  (If you haven’t managed to generate one secure 256-bit key then you have much bigger problems.)

On the same principle, any kind of seed system and/or HD wallet will use a KDF to derive your actual private keys, anyway.  So if your kernel’s PRNG (or your dice) gathers at least 256 bits of “real” randomness, then think of it as if it runs that through a KDF to give you the seed which you will run through a KDF to generate your keys.  That is more or less what happens.

On the other hand, if you really like the idea of hardware randomness, then you may be interested in Turbid.  It generates high-entropy symbols using electrical noise (not acoustical noise) caused by thermodynamic processes in the analogue electronics of an ordinary computer sound card.  It still uses a hash to process its input.  As far as I can see, its main advantage is that it keeps no state; but then, if you can’t trust your computer to keep secret the state of your PRNG, then how can you trust it for whatever crypto you are doing with the output of your True Random Number Generator?

(Side note:  If you use dice, I hope that you know how to extract binary random numbers without the “modulo bias” which unthinking people tend to suffer in such situations.  Or that you have hexadecimal dice.)

Also your comments lead me to point out a serious flaw in the use of off line web pages.

Namely, shouldn't such a web page (a computer program) not operate unless it was off line?

But why would you trust a web page to verify that it was offline?  If you could trust it with that, then you could trust it to operate while you are online, also.

Part of why I wrote easyseed was to have code which can be easily read and compiled offline.  Then, you only need to worry about your compiler.  See, “On Trusting Trust”.

[nullius]

easyseed(1) now has support for multiple languages.

To celebrate the New Year, I have the gift of a hidden unstable, unsupported feature for you .onion-lovers.  Here is the address of Wikileaks (http://wlupld3ptjvsgwqw.onion/) encoded as an 8-word mnemonic phrase in 8 languages or writing systems:

English	real element glow tennis pluck museum hair shuffle
Chinese (Simplified)	洁 爱 唱 仰 泪 吴 乎 怒
Chinese (Traditional)	潔 愛 唱 仰 淚 吳 乎 怒
French	parole distance fautif sombre notoire loyal flairer ratisser
Italian	retina erba idillio suonare potassio opposto india scuderia
Japanese	にもつ　けろけろ　しちりん　ほめる　とかす　たんまつ　しゃうん　はんしゃ
Korean	잠자리 반죽 상품 큰딸 이불 열차 선풍기 중반
Spanish	pie dulce gimnasio tabla oscuro molde guerra repetir

Cheers!

[nullius]

Edit: 404 from Github apparently resolved by support.  It appears that you can access my repositories now; please tell me if you have any problems.

Sorry about that. Sometimes our spam-detecting systems miss the mark and you were accidentally flagged in the process. I've gone ahead and removed the flag and you shouldn't see that message again.

I’ve requested further info, in hope that I could avoid this happening ever again.  I will edit or post with further info, if and as appropriate.  Regardless—if things are indeed working now, I apologize to the forum for the noise.  You may well understand how I reacted when I saw my public source code repositories suddenly go 404.

Aside, n.b. that I habitually PGP-sign my commits using the ECC key with fingerprint 0xC2E91CD74A4C57A105F6C21B5A00591B2F307E0C.

Notice:  The Github repositories for easyseed(1) and bech32(1) have suddenly gone 404.  Little remains of me on Github but for my open pull request to the BIP repository (archive.org, archive.is).

I saw that, before I saw this:

Here is the message I sent to Github support via their web form after I saw the latter:

Code:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Immediately upon sending my last support message, whereby I requested
support with my profile and projects being 404, I received for the first
time the following message:

![github_flagged_nym-zone](https://user-images.githubusercontent.com/33915087/34474941-ffa49fc4-ef7d-11e7-8c9c-e87fa7c498ae.png)

Image SHA-256:
4be910e882cd68b62bf1390c608f8407070e43a9d5c4f040e31a8a2e56e2df6d  github_flagged_nym-zone.png

Quote:
>Your account has been flagged.
>Because of that, your profile is hidden from the public. If you believe
>this is a mistake, contact support to have your account status reviewed.

This was on the same page as displayed the following message:

>Thanks for getting in touch with us!
>We’ll get back to you shortly.

I did *not* see the flagged notice before.  I also have not received
any other notification, by e-mail or otherwise.

Obviously, I must request that you review and undo this forthwith.
I must also inquire as to the ostensible grounds for this action.
There is *no* legitimate reason for my account to be “flagged”.

For the record:

 - All the code I have published to the Github account “nym-zone”
 was either written by me, or used under an open-source license.

 - I have not engaged in any abusive behaviour.

 - I have done nothing wrong.

 - I have absolutely no idea what this is about.  Nobody has even
 complained to me; and Github did not give me the courtesy of so much
 as an e-mail to advise that I’d been suddenly 404ed.  I was lucky to
 have caught this when I did; and I am blindsided here.

This message is signed with the PGP key I have registered in my
Github account, and have used to sign my commits.  Its fingerprint is
0xC2E91CD74A4C57A105F6C21B5A00591B2F307E0C.

~ Signed, ~

nullius@nym.zone
2018-01-02
-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQSNOMR84IlYpr/EF5vEJ5MVn575SQUCWksc4wAKCRDEJ5MVn575
SY3NAQC3otsvONLOxDI/C20CqKUFzy9WH+SkQOewA/aqAq/mVQD/cNQxKcHjyhhO
GRajS4PH+Gy1PstnoZ5JalIfIZJI3gM=
=BDZi
-----END PGP SIGNATURE-----

The text of my prior message, which I had saved before sending (that’s my habit on the forum, too!):

Subject: 404 on my profile and projects!

In a non-logged-in browser, I am receiving a 404 “Page not found” error for my own profile and projects!  In a logged-in browser, I can see my profile and projects; but a project with 10 total open/closed issues shows 0 issues, total.


- 404: https://github.com/nym-zone

- 404: My projects pages, under that URL

I checked status.github.com “All systems reporting at 100%”) and the @githubstatus Twitter feed (last update 2017-11-27, “Everything operating normally.”).

Please fix this.  Thanks.

nullius@nym.zone

And just when I’d been contemplating my next improvements and little projects....

Persons interested in my code are invited to contact me directly, via e-mail (preferred) or PM.

However this resolves, I will also must needs seek more reliable means of publishing my source code.

[Carlton Banks]

To celebrate the New Year, I have the gift of a hidden unstable, unsupported feature for you .onion-lovers.  Here is the address of Wikileaks (http://wlupld3ptjvsgwqw.onion/) encoded as an 8-word mnemonic phrase in 8 languages or writing systems:

English	real element glow tennis pluck museum hair shuffle
Chinese (Simplified)	洁 爱 唱 仰 泪 吴 乎 怒
Chinese (Traditional)	潔 愛 唱 仰 淚 吳 乎 怒
French	parole distance fautif sombre notoire loyal flairer ratisser
Italian	retina erba idillio suonare potassio opposto india scuderia
Japanese	にもつ　けろけろ　しちりん　ほめる　とかす　たんまつ　しゃうん　はんしゃ
Korean	잠자리 반죽 상품 큰딸 이불 열차 선풍기 중반
Spanish	pie dulce gimnasio tabla oscuro molde guerra repetir

What's the purpose of this feature? It seems (superficially) that there's no real-world use case.

[nullius]

To celebrate the New Year, I have the gift of a hidden unstable, unsupported feature for you .onion-lovers.  Here is the address of Wikileaks (http://wlupld3ptjvsgwqw.onion/) encoded as an 8-word mnemonic phrase in 8 languages or writing systems:

English	real element glow tennis pluck museum hair shuffle
Chinese (Simplified)	洁 爱 唱 仰 泪 吴 乎 怒
Chinese (Traditional)	潔 愛 唱 仰 淚 吳 乎 怒
French	parole distance fautif sombre notoire loyal flairer ratisser
Italian	retina erba idillio suonare potassio opposto india scuderia
Japanese	にもつ　けろけろ　しちりん　ほめる　とかす　たんまつ　しゃうん　はんしゃ
Korean	잠자리 반죽 상품 큰딸 이불 열차 선풍기 중반
Spanish	pie dulce gimnasio tabla oscuro molde guerra repetir

What's the purpose of this feature? It seems (superficially) that there's no real-world use case.

Why, what’s the real-world use case of BIP 39?  To ease human memorization, transcription, and communication of pseudorandom strings!

Bitcoin has been a leading innovator in the development of better ways for humans to interact with cryptographic gibberish.  With BIP 39 mnemonics, a mere mortal human can memorize a pseudorandom string, write it into a sealed Last Will and Testament in a manner easy to transcribe back into a computer—or if necessary, whisper it into somebody’s ear...

I should think that people may want to memorize, transcribe, speak, or whisper .onion addresses, too.

As an English speaker, which would you prefer to deal with in your capacity as not being carved out of silicon:  “wlupld3ptjvsgwqw” (ouch!), or “real element glow tennis pluck museum hair shuffle”?  Chinese people may prefer “潔 愛 唱 仰 淚 吳 乎 怒”.

For overlapping reasons, I have also been working on the application of BIP 173 Bech32 encoding for .onion address data (more).  That has the advantage of error correction, and a more compact format; different tools apply to distinct use cases.  Again, Bitcoin technical innovation opens new possibilities in other applications of cryptography.

I am also using these methods with PGP.  I’ve seen PGP mnemonics before, of course—but the mnemonic standard I recollect having seen many years ago used a 256-word (8-bit) alphabet, rather than the 2048-word (11-bit) alphabets from BIP 39.  Thus, unnecessarily long word strings.  I am also working on a spec for what I call Bech32 “PGP Descriptors” to encode key fingerprint plus metadata.  See those ugly hexadecimal strings in my signature?  Bitcoin will provide a better way.

Meanwhile, for use in Bitcoin, I have almost completed full BIP 39 implementation in easyseed(1).  It would have been done yesterday; but for the missing final piece, generation of the output seed, I need means to perform the specified Unicode NFKD normalization without dragging in ugly dependencies.  The rest is trivial.

[Andre_Goldman]

To celebrate the New Year, I have the gift of a hidden unstable, unsupported feature for you .onion-lovers.  Here is the address of Wikileaks (http://wlupld3ptjvsgwqw.onion/) encoded as an 8-word mnemonic phrase in 8 languages or writing systems:

English	real element glow tennis pluck museum hair shuffle
Chinese (Simplified)	洁 爱 唱 仰 泪 吴 乎 怒
Chinese (Traditional)	潔 愛 唱 仰 淚 吳 乎 怒
French	parole distance fautif sombre notoire loyal flairer ratisser
Italian	retina erba idillio suonare potassio opposto india scuderia
Japanese	にもつ　けろけろ　しちりん　ほめる　とかす　たんまつ　しゃうん　はんしゃ
Korean	잠자리 반죽 상품 큰딸 이불 열차 선풍기 중반
Spanish	pie dulce gimnasio tabla oscuro molde guerra repetir

What's the purpose of this feature? It seems (superficially) that there's no real-world use case.

Why, what’s the real-world use case of BIP 39<1>?  To ease human memorization, transcription, and communication of pseudorandom strings!

Bitcoin has been a leading innovator in the development of better ways for humans to interact with cryptographic gibberish.  With BIP 39 mnemonics, a mere mortal human can memorize a pseudorandom string, write it into a sealed Last Will and Testament in a manner easy to transcribe back into a computer—or if necessary, whisper it into somebody’s ear...

I should think that people may want to memorize, transcribe, speak, or whisper .onion addresses, too.

As an English speaker, which would you prefer to deal with in your capacity as not being carved out of silicon:  “wlupld3ptjvsgwqw” (ouch!), or “real element glow tennis pluck museum hair shuffle”?  Chinese people may prefer “潔 愛 唱 仰 淚 吳 乎 怒”.

For overlapping reasons, I have also been working on the application of BIP 173 Bech32 encoding for .onion address data (more).  That has the advantage of error correction, and a more compact format; different tools apply to distinct use cases.  Again, Bitcoin technical innovation opens new possibilities in other applications of cryptography.

I am also using these methods with PGP.  I’ve seen PGP mnemonics before, of course—but the mnemonic standard I recollect having seen many years ago used a 256-word (8-bit) alphabet<2>, rather than the 2048-word (11-bit) alphabets from BIP 39.  Thus, unnecessarily long word strings.  I am also working on a spec for what I call Bech32 “PGP Descriptors” to encode key fingerprint plus metadata.  See those ugly hexadecimal strings in my signature?  Bitcoin will provide a better way.

Meanwhile, for use in Bitcoin, I have almost completed full BIP 39 implementation in easyseed(1).  It would have been done yesterday; but for the missing final piece, generation of the output seed, I need means to perform the specified Unicode NFKD normalization without dragging in ugly dependencies.  The rest is trivial.

<1> It remeber me vaguely on some debate while the implementation of UTF-8 ( Ken Thompson and Rob Pike ) maybe there are some valuable lessons in computing history to remember...
<2> Regards to Bech32 I am trying to compile it on Visual Studio 2017 community edition using c +1+(https://i.imgur.com/yo5J4Q6.jpg jargon ... hang on (I am running out time) going to ed; this post again ... So I am not sure if it going to compile or not ...since there are some barvarian char set and maybe I only will see the out put at Oktoberfest. (pls relax this is a joke, when we'serious we ARE serious)

[nullius]

<1> It remeber me vaguely on some debate while the implementation of UTF-8 ( Ken Thompson and Rob Pike ) maybe there are some valuable lessons in computing history to remember...

That’s funny.  UTF-8 is my pet analogy for Segwit; I have been intending to post about this.  UTF-8 is a brilliant, elegant hack which expands chars [:blocks] from 1 to 4 [:million] bytes, while maintaining backward compatibility with old-style 1-byte ASCII.  It has a theoretical upper limit of a 32-bit codespace (with 6 bytes), but we really get a 21-bit codespace.

Sorry, Core:  Segwit is not as awe-inspiring as UTF-8.  UTF-8 is one of my favourite all-time most brilliant hacks ever.  But Segwit deserves to be compared.

IIRC, Pike (or was it Thompson?) sketched the original UTF-8 spec on a restaurant napkin.

<2> Regards to Bech32 I am trying to compile it on Visual Studio 2017 community edition

bech32 compilation/porting discussion is continued on its thread.  The MSVC compile should mostly but not entirely work, I think.

As for easyseed:  In addition to the POSIX getopt(3) interface and BSD-style <err.h> (also available on Linux), easyseed needs random numbers.  It read(2)s off /dev/urandom.  So it would need a suitable replacement from Microsoft CryptoAPI/CNG.  A quick search reveals CryptGenRandom() or BCryptGenRandom()?  If you use Windows Vista (and others?), just make sure you don’t inadvertently get bits from Dual_EC_DRBG. <g>