Adam Ficsor [ARCHIVE] on Nostr: 📅 Original date posted:2019-02-04 📝 Original message:Unlike mouse movement it ...
📅 Original date posted:2019-02-04
📝 Original message:Unlike mouse movement it works in a CLI software, which is great. However,
isn't there something else you can use instead of cards? Something with
invariant culture and maybe more common.
On Sun, Feb 3, 2019 at 7:27 PM Ryan Havar via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> More of a shower-thought than a BIP, but it's something I've long wish
> (hardware) wallets supported:
>
> ---
>
> Abstract: Bitcoin Wallets generally ask us to trust their seed generation
> is both correct and honest. Especially for hardware and air gapped wallets,
> this is both a big ask and more or less impossible to practically verify.
> So we propose a bring-your-own-entropy approach in which the wallet can
> function completely deterministically. Our method is based on shuffling
> physical deck of cards. There are 52! (2^219.88) different shuffle order,
> which is a big enough space to be secure against collision and brute force
> attacks. Conveniently a shuffled deck of cards also can serve as a physical
> backup which is easy to hide in plain sight with great plausible
> deniability.
>
>
> Representation:
>
> Each card has a suit which can be represented by one of SCHD (spades,
> clubs, hearts, diamonds) and a value of one of 23456789TJQKA where the
> numbers are obvious and (T=ten, J=jack, Q=queen, K=king, A=ace) so "7 of
> clubs" would be represented by "7C" and a "Ten of Hearts" would be
> represented with "TH".
>
> An deck of cards looks like:
>
>
> 2S,3S,4S,5S,6S,7S,8S,9S,TS,JS,QS,KS,AS,2C,3C,4C,5C,6C,7C,8C,9C,TC,JC,QC,KC,AC,2H,3H,4H,5H,6H,7H,8H,9H,TH,JH,QH,KH,AH,2D,3D,4D,5D,6D,7D,8D,9D,TD,JD,QD,KD,AD
>
> And can be verified by making sure that every one of the 52 cards appears
> exactly once.
>
>
> Step 1. Shuffle your deck of cards
>
> This is a lot harder than you'd imagine, so do it quite a few times, with
> quite a few different techniques. It is advised to do at *least* 7 good
> quality shuffles to achieve a true cryptographically secure shuffle. Do not
> look at the cards while shuffling (to avoid biasing) and don't be afraid to
> also shuffle them face down on the table. Err on the side over
> over-shuffling.
> See also:
> https://en.wikipedia.org/wiki/Shuffling#Sufficient_number_of_shuffles
>
> Step 2. Write out the order (comma separated)
>
> And example shuffle is:
>
>
> 5C,7C,4C,AS,3C,KC,AD,QS,7S,2S,5H,4D,AC,9C,3H,6H,9D,4S,8D,TD,2H,7H,JD,QD,2D,JC,KH,9S,9H,4H,6C,7D,3D,6S,2C,AH,QC,TH,TC,JS,6D,8H,8C,JH,8S,KD,QH,5D,5S,KS,TS,3S
>
> Step 3. Sha512 it to create a seed
>
> In the example above you should get:
>
> dc04e4c331b1bd347581d4361841335fe0b090d39dfe5e1c258c547255cd5cf1545e2387d8a7c4dc53e03cacca049a414a9269a2ac6954429955476c56038498
>
> Step 4. Interpret it
>
> e.g. For bip32 you would treat the first 32 bytes as the private key, and
> the second 32 bytes as as the extension code.
>
>
>
>
> -Ryan
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
Best,
Ádám
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190204/0bc324ae/attachment.html>;
📝 Original message:Unlike mouse movement it works in a CLI software, which is great. However,
isn't there something else you can use instead of cards? Something with
invariant culture and maybe more common.
On Sun, Feb 3, 2019 at 7:27 PM Ryan Havar via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> More of a shower-thought than a BIP, but it's something I've long wish
> (hardware) wallets supported:
>
> ---
>
> Abstract: Bitcoin Wallets generally ask us to trust their seed generation
> is both correct and honest. Especially for hardware and air gapped wallets,
> this is both a big ask and more or less impossible to practically verify.
> So we propose a bring-your-own-entropy approach in which the wallet can
> function completely deterministically. Our method is based on shuffling
> physical deck of cards. There are 52! (2^219.88) different shuffle order,
> which is a big enough space to be secure against collision and brute force
> attacks. Conveniently a shuffled deck of cards also can serve as a physical
> backup which is easy to hide in plain sight with great plausible
> deniability.
>
>
> Representation:
>
> Each card has a suit which can be represented by one of SCHD (spades,
> clubs, hearts, diamonds) and a value of one of 23456789TJQKA where the
> numbers are obvious and (T=ten, J=jack, Q=queen, K=king, A=ace) so "7 of
> clubs" would be represented by "7C" and a "Ten of Hearts" would be
> represented with "TH".
>
> An deck of cards looks like:
>
>
> 2S,3S,4S,5S,6S,7S,8S,9S,TS,JS,QS,KS,AS,2C,3C,4C,5C,6C,7C,8C,9C,TC,JC,QC,KC,AC,2H,3H,4H,5H,6H,7H,8H,9H,TH,JH,QH,KH,AH,2D,3D,4D,5D,6D,7D,8D,9D,TD,JD,QD,KD,AD
>
> And can be verified by making sure that every one of the 52 cards appears
> exactly once.
>
>
> Step 1. Shuffle your deck of cards
>
> This is a lot harder than you'd imagine, so do it quite a few times, with
> quite a few different techniques. It is advised to do at *least* 7 good
> quality shuffles to achieve a true cryptographically secure shuffle. Do not
> look at the cards while shuffling (to avoid biasing) and don't be afraid to
> also shuffle them face down on the table. Err on the side over
> over-shuffling.
> See also:
> https://en.wikipedia.org/wiki/Shuffling#Sufficient_number_of_shuffles
>
> Step 2. Write out the order (comma separated)
>
> And example shuffle is:
>
>
> 5C,7C,4C,AS,3C,KC,AD,QS,7S,2S,5H,4D,AC,9C,3H,6H,9D,4S,8D,TD,2H,7H,JD,QD,2D,JC,KH,9S,9H,4H,6C,7D,3D,6S,2C,AH,QC,TH,TC,JS,6D,8H,8C,JH,8S,KD,QH,5D,5S,KS,TS,3S
>
> Step 3. Sha512 it to create a seed
>
> In the example above you should get:
>
> dc04e4c331b1bd347581d4361841335fe0b090d39dfe5e1c258c547255cd5cf1545e2387d8a7c4dc53e03cacca049a414a9269a2ac6954429955476c56038498
>
> Step 4. Interpret it
>
> e.g. For bip32 you would treat the first 32 bytes as the private key, and
> the second 32 bytes as as the extension code.
>
>
>
>
> -Ryan
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
Best,
Ádám
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190204/0bc324ae/attachment.html>;