Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id E80BEC0001 for ; Thu, 6 May 2021 14:10:50 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id C2EDF405CF for ; Thu, 6 May 2021 14:10:50 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001] autolearn=ham autolearn_force=no Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iObjLfwc1fhC for ; Thu, 6 May 2021 14:10:48 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from mail.worldserver.net (mail.worldserver.net [217.13.200.37]) by smtp4.osuosl.org (Postfix) with ESMTPS id A530F40597 for ; Thu, 6 May 2021 14:10:48 +0000 (UTC) Received: from mail-qk1-f176.google.com (mail-qk1-f176.google.com [209.85.222.176]) (Authenticated sender: tobias@kaupat-hh.de) by mail.worldserver.net (Postfix) with ESMTPSA id 4BB4F26CA7 for ; Thu, 6 May 2021 16:10:44 +0200 (CEST) Received: by mail-qk1-f176.google.com with SMTP id 76so4974447qkn.13 for ; Thu, 06 May 2021 07:10:44 -0700 (PDT) X-Gm-Message-State: AOAM530gDO7uq3scveBnA8fXFSbfjrHVoKWo2wRmHr7W3vs1FN+Gl3Cp 24Yfu2rxZhm2hAX36TIVp+yP9aA1HhcvB0Q9mtg= X-Google-Smtp-Source: ABdhPJxHsgo/QK+h9BC9ikDHCMSpQO5Fa4wBEq2Sg6ln6V1E4UAdSIopVrcF4uVilDutFUcoXN/DSOdRXqkGLzaoju4= X-Received: by 2002:a37:394:: with SMTP id 142mr4098344qkd.347.1620310243574; Thu, 06 May 2021 07:10:43 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Tobias Kaupat Date: Thu, 6 May 2021 16:10:31 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Erik Aronesty Content-Type: multipart/alternative; boundary="0000000000007e896f05c1a9e0d0" X-Mailman-Approved-At: Thu, 06 May 2021 15:48:29 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Encryption of an existing BIP39 mnemonic without changing the seed X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2021 14:10:51 -0000 --0000000000007e896f05c1a9e0d0 Content-Type: text/plain; charset="UTF-8" Hello Erik, Thanks for your reply. After a little research I came to the same conclusion. PDKDF2 makes sense, since it is already used in BIP39. I will update my code. Regarding SeedXOR: That's at least a similar solution, but than I have to store 2 phrases, I really like to keep one part in my head, which is only possible with a password. Plus for anyone who want to use two seeds my proposal also works - it just needs software to be applied. Kind regards Tobias Kaupat Erik Aronesty schrieb am Do., 6. Mai 2021, 15:19: > i would stretch the password, with pbkdf2 or argon2 with like 30k > rounds or something first, rather than "just hashing it". remember, > it's pretty easy to validate these seeds - not like you lock someone > out after 9 guesses! > > On Wed, May 5, 2021 at 3:38 PM Tobias Kaupat via bitcoin-dev > wrote: > > > > Hi all, > > I want to start a discussion about a use case I have and a possible > solution. I have not found any satisfying solution to this use case yet. > > > > Use case: > > An existing mnemonic (e.g. for a hardware wallet) should be saved on a > paper backup in a password encrypted form. The encrypted form should be a > mnemonic itself to keep all backup properties like error correction. > > > > Suggested solution: > > 1) Take the existing mnemonic and extract the related entropy > > 2) Create a SHA526 hash (key) from a user defined password > > 3) Use the key as input for an AES CTR (empty IV) to encrypt the entropy > > 4) Derive a new mnemonic from the encrypted entropy to be stored on a > paper backup > > > > We can add some hints to the paper backp that the mnemonic is encrypted, > or prefix it with "*" to make clear it's not usable without applying the > password via the algorithm above. > > > > To restore the original mnemonic, one must know the password and need to > follow the process above again. > > > > An example implementation in GoLang can be found here: > > https://github.com/Niondir/go-bip39/blob/master/encyrption_test.go > > > > Why not use the existing BIP-39 Passphrase? > > When generating a mnemonic with passphrase, the entropy is derived from > the passphrase. When you have an existing mnemonic without a passphrase, > any attempt to add a passphrase will end up in a different seed and thus a > different private key. What we actually need is to encrypt the entropy. > > > > I'm open for your feedback. All encryption parameters are up to > discussion and the whole proposal needs a security review. It's just the > first draft. > > > > Existing solutions > > One solution I found is "Seedshift" which can be found here: > https://github.com/mifunetoshiro/Seedshift > > > > But I consider it less secure and I would like to suggest a solution > based on provably secure algorithms rather than a "rot23 derivation". Also > using a date as password seems not very clever to me. > > > > Kind regards > > Tobias > > _______________________________________________ > > bitcoin-dev mailing list > > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --0000000000007e896f05c1a9e0d0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Erik,
Thanks for your r= eply.
After a little research I came to the same concl= usion. PDKDF2 makes sense, since it is already used in BIP39.
I will update my code.



Regarding= SeedXOR:
That's at least a similar solution, bu= t than I have to store 2 phrases, I really like to keep one part in my head= , which is only possible with a password.=C2=A0
Plus= for anyone who want to use two seeds my proposal also works - it just need= s software to be applied.

Kind regards
Tobias Kaupat
=


Erik Aronesty <erik@q32.com> schrieb am Do., 6. Ma= i 2021, 15:19:
i would stretch the = password, with pbkdf2 or argon2 with like 30k
rounds or something first, rather than "just hashing it".=C2=A0 r= emember,
it's pretty easy to validate these seeds - not like you lock someone out after 9 guesses!

On Wed, May 5, 2021 at 3:38 PM Tobias Kaupat via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org= > wrote:
>
> Hi all,
> I want to start a discussion about a use case I have and a possible so= lution. I have not found any satisfying solution to this use case yet.
>
> Use case:
> An existing mnemonic (e.g. for a hardware wallet) should be saved on a= paper backup in a password encrypted form. The encrypted form should be a = mnemonic itself to keep all backup properties like error correction.
>
> Suggested solution:
> 1) Take the existing mnemonic and extract the related entropy
> 2) Create a SHA526 hash (key) from a user defined password
> 3) Use the key as input for an AES CTR (empty IV) to encrypt the entro= py
> 4) Derive a new mnemonic from the encrypted entropy to be stored on a = paper backup
>
> We can add some hints to the paper backp that the mnemonic is encrypte= d, or prefix it with "*" to make clear it's not usable withou= t applying the password via the algorithm above.
>
> To restore the original mnemonic, one must know the password and need = to follow the process above again.
>
> An example implementation in GoLang can be found here:
> https:/= /github.com/Niondir/go-bip39/blob/master/encyrption_test.go
>
> Why not use the existing BIP-39 Passphrase?
> When generating a mnemonic with passphrase, the entropy is derived fro= m the passphrase. When you have an existing mnemonic without a passphrase, = any attempt to add a passphrase will end up in a different seed and thus a = different private key. What we actually need is to encrypt the entropy.
>
> I'm open for your feedback. All encryption parameters are up to di= scussion and the whole proposal needs a security review. It's just the = first draft.
>
> Existing solutions
> One solution I found is "Seedshift" which can be found here:= https://github.com/mifunetoshiro/Se= edshift
>
> But I consider it less secure and I would like to suggest a solution b= ased on provably secure algorithms rather than a "rot23 derivation&quo= t;. Also using a date as password seems not very clever to me.
>
> Kind regards
> Tobias
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lis= ts.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--0000000000007e896f05c1a9e0d0--