Re: [bitcoin-dev] Encryption of an existing BIP39 mnemonic without changing the seed

[Erik Aronesty via bitcoin-dev]

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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Encryption of an existing BIP39 mnemonic without changing the seed

[Peter D. Gray via bitcoin-dev]

Hi Tobias.

The most recent release of Coldcard now offers "Seed XOR" to solve
similar problems. It allows any numbers of standard BIP-39
compatible seed phrases to be bitwise XOR'ed together to make a new seed.

Coldcard can split an existing seed into 2, 3 or 4 new phrases, or
you can take your existing seed phrase, and XOR-in a new seed phrase
to arrive at a new random seed phrase (and wallet).

More details about this feature at: 

Best part is XOR is simple enough that the split or combine operation can
be worked out by hand on paper. (We even made a worksheet for this.)
The checksums on each of the XOR parts protects the final result, and
each "part" is a fully functional decoy wallet.

Hope that helps!

On Wed, May 05, 2021 at 07:32:05PM +0200, Tobias Kaupat 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
...
> *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

---
@DocHEX  ||  Coinkite  ||  PGP: A3A31BAD 5A2A5B10



signature.asc
Description: PGP signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Full Disclosure: CVE-2021-31876 Defect in Bitcoin Core's bip125 logic

[Antoine Riard via bitcoin-dev]

Hi,

I'm writing to report a defect in Bitcoin Core bip125 logic with minor
security and operational implications for downstream projects. Though this
defect grieves Bitcoin Core nodes 0.12.0 and above, base layer safety isn't
impacted.

# Problem

Bip 125 specification describes the following signalling mechanism :

"
This policy specifies two ways a transaction can signal that it is
replaceable.

* Explicit signaling: A transaction is considered to have opted in to
allowing replacement of itself if any of its inputs have an nSequence
number less than (0x - 1).

* Inherited signaling: Transactions that don't explicitly signal
replaceability are replaceable under this policy for as long as any one of
their ancestors signals replaceability and remains unconfirmed.

One or more transactions currently in the mempool (original transactions)
will be replaced by a new transaction (replacement transaction) that spends
one or more of the same inputs if,

# The original transactions signal replaceability explicitly or through
inheritance as described in the above Summary section.
"

An unconfirmed child transaction with nSequence = 0xff_ff_ff_ff spending an
unconfirmed parent with nSequence <= 0xff_ff_ff_fd should be replaceable as
the child transaction signals "through inheritance". However, the
replacement code as implemented in Core's `PreChecks()` shows that this
behavior isn't  enforced and Core's mempool rejects replacement attempts of
an unconfirmed child transaction.

Branch asserting the behavior is here :
https://github.com/ariard/bitcoin/commits/2021-03-test-rbf

# Solution

The defect has not been patched.

# Downstream Projects Affected

* LN : State-of-the-art pinning attacks against second-stage HTLCs
transactions were thought to be only possible by exploiting RBF rule 3 on
the necessity of a higher absolute fee [0]. However, this replacement
defect opens the way for an attacker to only pin with an opt-out child
without a higher fee than the honest competing transaction. This lowers the
cost of attack as the malicious pinning transaction only has to be above
mempools'min feerate. This also increases odds of attack success for a
reduced feerate diminishes odds of confirmation ending the pinning.

A functional test demo illustrating cases is available on this branch:
https://github.com/ariard/bitcoin/commits/2021-05-htlc-preimage-pinnings

LN nodes operators concerned by this defect might favor anchor outputs
channels, fully mitigating this specific pinning vector.

* Onchain DLC/Coinswap/Vault : Those contract protocols have also multiple
stages of execution with time-sensitive transactions opening the way to
pinning attacks. Those protocols being non-deployed or in early phase, I
would recommend that any in-protocol competing transactions explicitly
signal RBF.

* Coinjoin/Cut-Through : if CPFP is employed as a fee-bumping strategy, if
the coinjoin transaction is still laying in network mempools, if a
fee-bumping output is spendable by any protocol participant, this
fee-bumping mechanism might be halted by a malicious protocol participant
broadcasting an low-feerate opt-out child. According to bip125, if the
coinjoin parent tx signals replaceability, the child transaction should be
replaceable, whatever its signaling. However Core doesn't apply this
policy. RBF of the coinjoin transaction itself should be used as a
fallback. I'm not aware of any deployed coinjoin using such
"anyone-can-bump" fee-bumping strategy.

* Simple wallets : RBF engines' behaviors might be altered in ways not
matching the intent of their developers. I invite RBF engines dev to verify
what those components are doing in the light of disclosed information.

# Discovery

While reviewing the LN dual-funding flow, I inquired on potential new DoS
vectors introduced by relying on counterparty utxos in this following
analysis [1]. The second DoS issue "RBF opt-out by a Counterparty
Double-Spend" is relying on a malicious chain of transactions where the
parent is signaling RBF opt-in through nSequence<=0xff_ff_ff_ff-1 but the
child, servicing as a pinning transaction, opt-out from the RBF policy.
This pinning trick conception was matching my understanding of Core code
but while reading again the specification, I observed that it was
inconsistent from the inherited signaling mechanism as described in the
bip's "Summary" section.

After exercising the logic, I did submit the defect to Dave Harding, asking
confirmation of divergence between Bitcoin Core and BIP 125. Soon after, he
did confirm it and pointed that the defect has been there since the 2015's
PR introducing the opt-in RBF, advicing to to consider security
implications for deployed second-layer protocols. After noticing the minor
implications for pinning attacks on second-stage LN transactions while
talking with Matt Corallo, I did disclose to the Bitcoin Core security list.

My initial report was recommending avoiding a covert patch in the mempool
as risks of 

Re: [bitcoin-dev] Encryption of an existing BIP39 mnemonic without changing the seed

[Tobias Kaupat via bitcoin-dev]

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
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Fee estimates and RBF

[Prayank via bitcoin-dev]

Good morning ZmnSCPxj,

Thanks for your response. I agree there are few exceptions: 

1.Unconfirmed output can be spent resulting in conflict with RBF
2.Race condition and mining pool may include old transaction with low fee
I am trying few things related to RBF and handling such exceptions, will share 
if I find anything interesting.
-- 
Prayank

May 3, 2021, 09:32 by zmnsc...@protonmail.com:

> Good morning Prayank,
>
> I believe a "true" full-RBF wallet should be what every onchain wallet 
> aspires to.
>
> However, I think a lot of the effort necessary here has to do with sheer 
> engineering issues.
>
> For example, if you think "RBF does not exist", you can do things like:
>
> * Spend an unconfirmed input from a third party.
>  * This is not actually safe since an unconfirmed tx might have a conflicting 
> transaction get confirmed, but a lot of onchain wallets support this for 
> non-RBF unconfirmed inputs because 99.9% of the time this never happens.
> * When you spend from a (confirmed or unconfirmed) input, delete it from your 
> db forever (because you do not have to worry about alternate transactions 
> spending the same input).
>  * This simplifies db design, you do not have to keep track of states like 
> "has been spent but tx is not confirmed yet", "has two different alternate 
> transactions spending it that have not confirmed", "is on a transaction that 
> is not confirmed and therefore this input might disappear completely" etc.
>
> In particular, if we want a "true" full-RBF wallet:
>
> * Suppose the user wants to spend some amount to address A.
>  * The user imposes a limit on up to how much to spend on fees to have this 
> spend happen.
> * The wallet optimistically creates a low-fee send transaction.
> * After some time, the wallet bumps up the fee by creating a new transaction.
>  * The wallet keeps bumping up, up to the designated limit, the longer the 
> transaction is not confirmed.
>
> Of note is that there is a *race condition* in the above case.
> When the wallet is bumping up and constructing a new transaction with higher 
> fee, a miner could find a new block that has the old transaction with lower 
> fee.
>
> Now consider the subsequent user story.
>
> * After some time, the user wants to spend another amount to address B.
>  * Again the user imposes a limit on how much to spend on fees to have this 
> spend happen.
> * The wallet RBFs the existing transaction to include the spend to address B.
>
> Again, a race condition can occur --- while the wallet is feebumping a new 
> transaction that includes the new output, a random miner can find a new block 
> that includes the old transaction.
>
> Thus, the wallet really needs to keep track of any "pending spends" and 
> correlate them with actual transactions.
>
> Further, of course it is convenient to be able to spend money even while it 
> is unconfirmed.
> But the sender of the unconfirmed input might be using the same software as 
> this wallet as well, meaning that the actual transaction output might change 
> as the original spender keeps fee-bumping it over time.
>
> I confess I have not been thinking of this as well as I should have.
>
> Regards,
> ZmnSCPxj
>___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev