Pages:
Author

Topic: FRAGMENTED BACKUPS VULNERABILITY!! IF YOU USE THEM, READ THIS!! (Read 32255 times)

legendary
Activity: 3640
Merit: 1345
Armory Developer
Not sure if this is worth even worth a mention, but I was playing around with fragmented backups to test and found something.

I figured I would try to make a backup with a mix of everything. First paper, w/o secureprint, then paper w secureprint, then file w/o secureprint and finally file with securerint. As this was only a test, I didn't take a very close look other than seeing the wallet name (obviously) and the secureprint code staying the same after toggling the latter on/off. After saving and printing the backups, I deleted the wallet and tried to restore them. When I did, the message "If any of the fragments require a SecurePrint code, you will only have to enter it once" (emphasis mine) made me confident the mix would not be a problem.

When I realized none of the backups fragment matched what was stated on the paper/file I realized something was wrong and went back to create a new one. Toggling secureprint on/off shows that this creates a completely new set. However, 3/4 fragmented backups I made have the same fragment-ID (not the 4th), and all 4 obviously the same wallet ID (this was with 0.96.3).

This was just me playing around, and I would have been a lot more careful before depositing anything. Still, there could perhaps be a warning that:
1. you can't mix and match secureprint
2. each time you toggle on/off you create a new set of fragments.

With 0.96.3.99, none of the fragments got the same ID, but the SecurePrint code stayed the same through each toggle.

Based on the initial text of the previous SSS being deterministic, I'm guessing this wasn't a problem before this fix was made?

I see what you mean, toggling secureprint cycles the fragments. I'll look into it.
newbie
Activity: 7
Merit: 0
Not sure if this is worth even worth a mention, but I was playing around with fragmented backups to test and found something.

I figured I would try to make a backup with a mix of everything. First paper, w/o secureprint, then paper w secureprint, then file w/o secureprint and finally file with securerint. As this was only a test, I didn't take a very close look other than seeing the wallet name (obviously) and the secureprint code staying the same after toggling the latter on/off. After saving and printing the backups, I deleted the wallet and tried to restore them. When I did, the message "If any of the fragments require a SecurePrint code, you will only have to enter it once" (emphasis mine) made me confident the mix would not be a problem.

When I realized none of the backups fragment matched what was stated on the paper/file I realized something was wrong and went back to create a new one. Toggling secureprint on/off shows that this creates a completely new set. However, 3/4 fragmented backups I made have the same fragment-ID (not the 4th), and all 4 obviously the same wallet ID (this was with 0.96.3).

This was just me playing around, and I would have been a lot more careful before depositing anything. Still, there could perhaps be a warning that:
1. you can't mix and match secureprint
2. each time you toggle on/off you create a new set of fragments.

With 0.96.3.99, none of the fragments got the same ID, but the SecurePrint code stayed the same through each toggle.

Based on the initial text of the previous SSS being deterministic, I'm guessing this wasn't a problem before this fix was made?
legendary
Activity: 3640
Merit: 1345
Armory Developer
as long as the paper fragments have been secure, if i destroy the paper fragment backups while retaining a copy of the full original root seed, i should be ok, right?

It's more cautious the cycle the wallets.
member
Activity: 178
Merit: 10
as long as the paper fragments have been secure, if i destroy the paper fragment backups while retaining a copy of the full original root seed, i should be ok, right?
legendary
Activity: 3640
Merit: 1345
Armory Developer
I doubt that side-channel attacks are at all relevant for paper backups.  That normally requires statistical data on the timing or the amount of power it takes to do the operation.  It might be a worry that a compromized computer can gain information from a hardware wallet through side channels, but not when restoring a wallet.

My guess is that the main problem with SSS is that it is one of the few cryptographic operations that are simple enough that people implement it themselves, instead of getting it from a peer-reviewed and well-debugged library.

If you are using constant time AES and ECDSA, the only time to perform a timing attack is at restore time, which only applies to SSS in this case (assuming it's not in constant time).

Quote
SSS does not just have a plausible deniability edge over multisig scripts (I am sure it does, although I cannot see how).

1) You have assume any skilled/well equipped attacker will always get access to your watching only wallet (think law enforcement raiding your home).

2) This means an attacker will know not only of all your coins on chain, but also have access to all the script hash preimage. Therefor, if you used multisig, they will know of this as well.

3) On the other hand, SSS allows you to split your backups without reflecting that on chain, i.e. you could have all your coins in single sig scripts and there is no way for the attacked to know this just with your WO wallet.
full member
Activity: 159
Merit: 100
I think you're reading too much into gmax's words. His general concern with SSS implementations is that they are basically all done over prime fields, which the easier implementation, but introduces side channel attacks cause it relies on bignum operations.

I doubt that side-channel attacks are at all relevant for paper backups.  That normally requires statistical data on the timing or the amount of power it takes to do the operation.  It might be a worry that a compromized computer can gain information from a hardware wallet through side channels, but not when restoring a wallet.

My guess is that the main problem with SSS is that it is one of the few cryptographic operations that are simple enough that people implement it themselves, instead of getting it from a peer-reviewed and well-debugged library.

Quote
A GF(256) implementation would be in constant time, but that's harder to pull and therefor brings in question whether it's worth the effort at all, considering multisig covers a lot of what SSS does. I argued that SSS still has an edge over multisig scripts (plausible deniability), therefor I'll consider implementing SSS over GF(256) for the new wallets.

SSS does not just have a plausible deniability edge over multisig scripts (I am sure it does, although I cannot see how).  It solves a different problem: that of safely keeping backups.  Multisig of course gives the same security to your backup, but it also makes spending from the wallet on a day-to-day basis significantly more cumbersome.  And in times with high pressure on the blockchain, it also adds to the fee.

legendary
Activity: 994
Merit: 1034
The SSS implementation in Armory is completely unrelated to that. It also predates that by a few years.

Since Greg Has concerns about every SSS version he has come across -

https://np.reddit.com/r/Bitcoin/comments/72dfy1/armory_wallet_fragmented_backups_may_be/dnho2w6/

I think we should be highly skeptical about entropy wallets until more peer review is done as well.

I think you're reading too much into gmax's words. His general concern with SSS implementations is that they are basically all done over prime fields, which the easier implementation, but introduces side channel attacks cause it relies on bignum operations.

A GF(256) implementation would be in constant time, but that's harder to pull and therefor brings in question whether it's worth the effort at all, considering multisig covers a lot of what SSS does. I argued that SSS still has an edge over multisig scripts (plausible deniability), therefor I'll consider implementing SSS over GF(256) for the new wallets.

Well said . couldn't hurt for more peer review regardless.
legendary
Activity: 3640
Merit: 1345
Armory Developer
In case I am 100% sure that the fragments have not been compromised (sealed envelopes, under the custody of people whom I trust), would it be possible to :
- install Armory 0.96.3 on a fresh machine,
- restore the current wallet here (originally generated with Armory 0.93.3)
- print new "secure" fragments of the same wallet,
- destroy the old fragments and the machine ?

You should cycle the wallets if you're going to bother printing new fragments. Better safe that sorry. Who knows where sha256 will be 30 years from now.

Quote
Would Armory 0.93.3 be able to restore a newly printed wallet in case of need ?

The restoration code is the same, but the fragment IDs are not deterministic anymore, so it's possible the GUI will refuse to proceed further with newly generated fragments until you comment out that check from the Python code. In other words, it can work if you're willing to deal with a little Python.
legendary
Activity: 3640
Merit: 1345
Armory Developer
Is it fine if I don't care 1 sheet can now recover my Bitcoin? And just keep them as a paper backup? There's no actual leak right?

I'd rather you don't confuse the 2 for the sake of convenience, but that's a way to look at it.

I'll consider it 1 of 1 for now. Thanks.

That's a way to look at the security of the fragment. There is no code allowing to go from 1 fragment to your secret atm, and doing this off of the second version of the SSS scheme is non trivial, just so we are clear.
legendary
Activity: 2912
Merit: 1060
Is it fine if I don't care 1 sheet can now recover my Bitcoin? And just keep them as a paper backup? There's no actual leak right?

I'd rather you don't confuse the 2 for the sake of convenience, but that's a way to look at it.

I'll consider it 1 of 1 for now. Thanks.
legendary
Activity: 3640
Merit: 1345
Armory Developer
Is it fine if I don't care 1 sheet can now recover my Bitcoin? And just keep them as a paper backup? There's no actual leak right?

I'd rather you don't confuse the 2 for the sake of convenience, but that's a way to look at it.
legendary
Activity: 2912
Merit: 1060
Is it fine if I don't care 1 sheet can now recover my Bitcoin? And just keep them as a paper backup? There's no actual leak right?
legendary
Activity: 3640
Merit: 1345
Armory Developer
The SSS implementation in Armory is completely unrelated to that. It also predates that by a few years.

Since Greg Has concerns about every SSS version he has come across -

https://np.reddit.com/r/Bitcoin/comments/72dfy1/armory_wallet_fragmented_backups_may_be/dnho2w6/

I think we should be highly skeptical about entropy wallets until more peer review is done as well.

I think you're reading too much into gmax's words. His general concern with SSS implementations is that they are basically all done over prime fields, which the easier implementation, but introduces side channel attacks cause it relies on bignum operations.

A GF(256) implementation would be in constant time, but that's harder to pull and therefor brings in question whether it's worth the effort at all, considering multisig covers a lot of what SSS does. I argued that SSS still has an edge over multisig scripts (plausible deniability), therefor I'll consider implementing SSS over GF(256) for the new wallets.
legendary
Activity: 994
Merit: 1034
The SSS implementation in Armory is completely unrelated to that. It also predates that by a few years.

Since Greg Has concerns about every SSS version he has come across -

https://np.reddit.com/r/Bitcoin/comments/72dfy1/armory_wallet_fragmented_backups_may_be/dnho2w6/

I think we should be highly skeptical about entropy wallets until more peer review is done as well.
staff
Activity: 3332
Merit: 6433
Just writing some code
Entropy , used by many to create SSS fragments for cold storage uses a similar scheme -

https://github.com/mycelium-com/entropy

Specification -

https://github.com/cetuscetus/btctool/blob/bip/bip-xxxx.mediawiki
The SSS implementation in Armory is completely unrelated to that. It also predates that by a few years.
legendary
Activity: 994
Merit: 1034
Does this effect SSS with mycelium entropy?

I'm don't know what you are referring to.

Entropy , used by many to create SSS fragments for cold storage uses a similar scheme -

https://github.com/mycelium-com/entropy

Specification -

https://github.com/cetuscetus/btctool/blob/bip/bip-xxxx.mediawiki
legendary
Activity: 3640
Merit: 1345
Armory Developer
Does this effect SSS with mycelium entropy?

I'm don't know what you are referring to.
legendary
Activity: 994
Merit: 1034
Does this effect SSS with mycelium entropy?
full member
Activity: 179
Merit: 151
-
There are two things should be random in SSS.  The coefficients of the polynomial.  And the x-values where the polynomial is evaluated.

This is false. Where did this idea come from?

Quote
Non-random x values is probably relatively benign, since all information about the polynomial is in the f(x) values.  Wikipedia does not even mention that the x values should be random.

What does "probably relatively benign" mean in cryptographic terms?

Quote
Pseudo-random coefficients is certainly a bad idea.

Why is this?
full member
Activity: 159
Merit: 100
You can choose any x as long as the coefficients are random. I don't quite see how randomizing x achieves anything, as you have to provide entire points (x, f(x)) as fragments, therefor x is public information. Maybe you were trying to say that the x values should be chosen at random, instead of say, as part of a sequence? I don't think that's relevant at all for SSS, since all operation are performed on a finite field.

I had misunderstood your post.  My bad.


Quote
The coefficients are 32bytes, therefor your backup would have 5 lines (1 header line + 4 * (16bytes of data + 2bytes of checksum) lines) per fragment. If the fragment only has 1 header and 2 data lines, it's using implicit [1,...,N] for x.
Mine has a header line, and two data lines.  I am not completely pwned then, but only has a slightly reduced security.  Ah, well.


Quote
It's far worse than that. Look at how the coefficients are constructed, they're hashes of the previous coefficient. Whatever fragment the attacker gets access to, he will be able to compute all following coefficients just by hashing x once.

Oh my god!  It must be one of the worst security f*ckups in a bitcoin wallet!

Pages:
Jump to: