okay I have to say BIP39 is a horrible fucking standard
first of all implementing it in any way violates the principle of “don’t do secret based memory accesses”
second of all fuck you because you need to run PBKDF on the seedphrase itself and not the entropy bits
cc nostr:npub1fjqqy4a93z5zsjwsfxqhc2764kvykfdyttvldkkkdera8dr78vhsmmleku
did I fucking tell you that you always leak some bits of information because the execution time will never be constant due to varying seedphrase lengths? fuck this shit
haha, yeah, pbkdf tho lol
it kinda kills the use case of a low power device
there is no reason why a 24 word key should need any hashing tho, and a 12 word key should only need one hash operation...
but adding a password on top then you start to talk about why pbkdf and argon 2 and whatnot
maybe we should devise a word key scheme for nostr because nobody is using nip-06 anyway, and maybe the different key type has some ways to benefit this
also, you gotta have secret in memory somewhere, it's just about isolating it from a leaky execution environment, i'm pretty sure there is very little risk of losing an nsec from a browser signer or amber or whatever
don't put the signer in the same app that can spend money or spam messages anyhow
was doing some research into having BIP-39 on environments like SEs and my conclusion is fuck this shit
always has been
“a trie can be used for prefix compression” holy fuck let’s throw constant time out of the window
“run seeds through PBKDF2” if you want to slow down passphrase brute forcing then run the PW through PBKDF2
Comments-Summary: Unanimously Discourage for implementation
https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki
fucking deserved
For some reason this remind me when WEP WiFi was hacked by just watching enough traffic. 😂
Though not really sure if that’s similar what you are referring to.
the problem is basically that someone can figure out information about the length of each word in the seedphrase just from looking at the execution time or power consumption of a device
Clever. Like say it takes less time this means it’s a shorter word, if it takes more time then it’s a long one, and from there randomness is reduced significantly.
But you still have to brute force after that, no?
Also, isn’t transaction signing typically done offline? How can a hacker monitor the time of a chip they can’t even see.
that reduces the security of a 12 word phrase from 128 bits to 100 bits
also about the power consumption, the device in question is a little battery powered ARM system on chip board that you use airgapped, like a jade or a seed signer, i don't understand what you are talking about at all
EMF leaks and the likes
this kind of thing is extremely marginal risk, compared to not having your keys backed up
yeah, I was trying to make a resistant implementation but due to the stupidity of the people that wrote BIP39 it is 1. very space inefficient 2. not constant time
you can always just transcribe hex, or bech32 - for hex you might want to add a CRC32 suffix check string, bech32 includes one
I’m considering doing xprvs
so, a HD seed
i still think you should use a crc32 check, and hex, to make the decoder simple as possible... base32 and base64 are shit in this respect
you could make a simpified 256 word dictionary mnemonic key scheme too, that would be 32 words, plus another 4 for your CRC check or 36 words, they could all be precisely 4 letters long to make storage neat
xprvs are neat but they use the crappy base58check encoding
in the end it’s 64 bytes, so why not bech32m
constant time doesn't matter without an interactive protocol where timing can be observed
you don't keep the words in memory all the time, that's just as retarded as keeping the hex encoding in memory all the time when you need to constantly generate signatures with the secret it encodes... yes, you store the damn bits of the secret
the decoding from the word key is human input and then generate the secret and encrypt with a password and voila
the password encryption is literally just hashing the literal password a shitload of times ind some funny complex pattern like in pbkdf or argon/2 and then XORing that with the secret bytes and it's done
you don't decode the damn word key in a way that leaks any timing information because humans are so slow there's no way the nanoseconds of decoding are going to be a part of any side channel of timing
and btw, keeping the hex encoding in memory is what go-nostr library does, that's been a very big and difficult refactor to do, but the performance increase is outstanding
I'll tell the CEO. He'll be mad.
nobody even implements nip-06 except in a few libraries but no apps i know of
cc: nostr:nprofile1qyt8wumn8ghj7etyv4hzumn0wd68ytnvv9hxgtcppemhxue69uhkummn9ekx7mp0qy08wumn8ghj7mn0wd68yttsw43zuam9d3kx7unyv4ezumn9wshszythwden5te0dehhxarj9emkjmn99uq3xamnwvaz7tmsw4e8qmr9wpskwtn9wvhsz9thwden5te0wfjkccte9ejxzmt4wvhxjme0qythwumn8ghj7un9d3shjtnwdaehgu3wvfskuep0qqsrxra3gv0lnkxz2pcxh0xuq9k4f9dr7azwq3aypqtnay4w0mjzmtq8hdu63 would be cool if you supported BIP-39 nip-06 keys so people can more easily back them up offline
they are supported in the alby hub, and yes btw i am now using it
actually the alby extension does that. there you have a master key from which the nostr key is derived.
i didn't say HD key i said BIP-39 word-mnemonic-key
reminds me, i should actually revise my key miner to print out the 24 word BIP39 with the keys
i was gonna play games this evening but games bore me far more than writing code
this all made me realise there isn't a deterministic encoding scheme
24 words from 2048 word dictionary is actually 264 bits which is a full key plus a byte of check
i'm going to draft a scheme based on the bip39, this is an easy implementation and try to get some traction on it
no cold backup for nostr keys is wrawwwngg
