Bitcoin Forum

 I wonder if there should be a forum dedicated just to security...

I'm sure you're all familiar with
http://imgs.xkcd.com/comics/security.png

 How to deter?

Idea 1) Steganography

Idea 2) Additional factor: Share the private key between 4 execs. 2 of the group are required to decrypt the code. 4 not 2 in case one of the pair dies.

Idea 3) Time based auth. Have a factor that only becomes clear when a certain time happens. Hard to implement in practice? Could it be something such as how light falls on the earth or something stranger? How could this work in practice?

Idea 4) p2p auth. Need a peer to peer network agree and get concensus to decrypt the key.

Idea 5) Deniable encryption. Like carrying 2 wallets, one low value. Can't see this workingm they might be able to tell you are lying.

Idea 6) Do something funny with public key encryption?

Idea 7) Just bury half of the key somewhere awkward to get to. In another country perhaps. If you had a yacht and got captured would this deter or would you really want access to that for a bribe?


Anything else? How to make these things more workable? Is there a way to give a 3rd party access to a wallet in such a way that they can only pay out to an address you hold? That way you could give grandma/wife half the savings and get an allowance so you can't go gambling.

Shamir's Secret Sharing Scheme (http://point-at-infinity.org/ssss/ (http://point-at-infinity.org/ssss/)) can do this.  You can split the private key into N encrypted secret strings and give them to different people.  The original private key can only be reconstructed if X secrets are combined.


The closest thing I can think of to what you describe is having some third party only give you what you ask for at a certain time.

Another option that might be somewhat applicable is Encryption based on Time Reversal Transformations (http://comjnl.oxfordjournals.org/content/32/3/241.full.pdf (http://comjnl.oxfordjournals.org/content/32/3/241.full.pdf) (Skip to the Discussion section)).  It's where you have some data, apply some rule to it to change it, and do that over and over again for X steps.  There's no easy shortcut to skip steps.  To decrypt it you would have to apply the rules in reverse and go through each step backwards until you got to your original data.  This isn't measured in time exactly, because if you encrypt something on a slow computer, a fast computer would be able to reverse it quicker.

Regulate rubber hoses?

Store the private key in a microcontroller that won't release it until a certain time using only the internal oscillator, enable code-protect so it can't be read or reprogrammed. Not 100% secure, but certainly significantly more difficult than any software-only solution to break.

On #3 there are timelock encryption algorithms.  Methods that even given the "secret" it will take hours or even years to produce the key.  Most timelock encryption algorithms can be parallized in encrypting but not in decrypting.  So you could create a problem which takes 1 CPU year to complete and then rent 365 Amazon instances and produced the encrypted output for storage in just a day.  However decryption would require 1 CPU year to complete (well maybe single core get a little faster and overlocked so someone can "brute force" it in 6 months).

Cool, SSSS takes BTC donations at 1BWary.

Truecrypt can do this. 

http://www.truecrypt.org/docs/?s=plausible-deniability

See also http://marutukku.org/

Some more discussion about this topic here: http://bitcoin.stackexchange.com/questions/517/how-can-a-single-person-operation-keep-a-collection-of-online-wallets-secure (http://bitcoin.stackexchange.com/questions/517/how-can-a-single-person-operation-keep-a-collection-of-online-wallets-secure)

And on the crypto site here: http://crypto.stackexchange.com/questions/746/how-should-one-implement-a-delegated-shared-trust-protocol (http://crypto.stackexchange.com/questions/746/how-should-one-implement-a-delegated-shared-trust-protocol)

I think SSS with the keys given to individuals spread over a large geographic location (multiple countries), their real identities need to be secret.

In some situations this might result in you getting killed, so you need to have deniable encyption as well.

You forgot an important thing: privacy.

Many of the techniques you mention become useless if your attacker is really evil and knows for sure that you have or control at least X amount of money hidden somewhere. If he also happens to know the habits of your family members, things may get ugly.

A hardware problem can be solved with a hardware solution and I believe there's an invention that deals with the problem presented in the OP..

Just use one of these:
http://thinkprogress.org/wp-content/uploads/2012/07/Guns_1000.jpg

... and don't let them catch you. I believe it's also possible to hire people who will carry those for you and protect you if necessary.

Safes have time controls where only certain times of day you can open it.

Same could be done for a wallet.

Have You ever tried to change time in BIOS?

Probably best hardware against rubber-hose cryptanalysis is a AK-74 and RGD grenade.

nLockTime should handle this: https://en.bitcoin.it/wiki/Contracts

What about writing down the secret (with archival quality materials) and storing it in a safe deposit box?

There a lot of good ideas here but they seem a bit hard work for the average person, especially if you're trying to avoid keyloggers. Truecrypt and deniability is a good step but you might cave under pressure.

I'd like to see the ability to use one time paper passwords and Google Authenticator as a second factor. You can already do this at blockchain mywallet.

SSSS sounds good. I guess that is 2x better than splitting the key in half between 2+ people?

I guess time delay could be done by block discovery.

Open-Transactions is intended exactly for this situation afaik.

Offline wallets sound great for this problem but they're stuck in set amounts. I guess you could always make a lot of small offline wallets... I wonder if subdivisions are possible mathematically via a third party in the calculation. That is, you could have another p2p system for subdivisions i.e. trading Bitcoin for 2 Litecoin keys in a p2p way...

nLockTime sounds interesting. Kinda treads on OpenTransaction's toes a bit but I really didn't know we had that - good news

"Imagine that you open an account on a website (eg, a forum or wiki) and wish to establish your trustworthiness with the operators, but you don't have any pre-existing reputation to leverage. One solution is to buy trust by paying the website some money. But if at some point you close your account, you'd probably like that money back"

^ why not have this on direct exchange networks? hmm... I guess it's a form of debt though which is exactly what Bitcoin is against... ?

Establish a resource based economy that provides all people with their basic needs, allows for a safe and high standard of living and encourages all people to meet their highest potential. No longer need to protect or hide irrelevant money.

Are you being encouraged to meet your highest potential? If so, why would you engage in mind numbing and boring activities that do not provide any longterm fulfillment?

I'm more concerned about Devil's Breath (http://www.dailymail.co.uk/news/article-2143584/Scopolamine-Powerful-drug-growing-forests-Colombia-ELIMINATES-free-will.html) (scopolamine) that cause you to willingly give up your brain wallet. There must be a way to defeat the state of mind it puts you in with a brain wallet device you won't recall while drugged.

This is one of my favorite trolls ever.

What are your basest desires and are you doing them now? If not, why not?

That was the best solution I could come up with.  An attacker could not get they keys out of me because I simply don't know them.  They could escort me to the bank, but that's a risky proposition since I will likely be able to conjure up some help in addition to whatever key material happens to be at that particular locale.

Problems:

 - An attacker could still torture the shit out of me trying to get the keys which I cannot give him/her.

 - An authority could (potentially) raid my safe deposit box and deny me the information I might have stored there.

One way or another, an attacker should hope they get all of my BTC (which is somewhat unlikely) because whatever I have left would be dedicated to extracting revenge.  I cannot honestly say that I have in place a solution to effect this outcome in the event of my being no longer among the living, but it's something I've mused about.

Interesting thought here, with multisig, it may be secure enough to store your bitcoins on several VPSes. A 5-of-6 address would make it so that 5 different hosts would have to collude or be hacked in order to steal your coins, and gives some insurance against a server going down. Program these servers to send all coins to an address if you do not log in once every certain number of days.

Perfection is impossible but to specifically beat the rubber hose, I like SSSS plus multiple safe deposit boxes. At somewhere between free and $40/yr you can get one at each of your banks.

Suppose you have 2 safety deposit boxes.  Each box has half your key.  That helps solve problem #1.

Suppose you have 3 safety deposit boxes.  Box A and B has half your key.  Box C contains the sum the keys stored in A and B (which are both numbers).  You can recover with any 2 out of 3, because if you lose either A or B, you can recover it by taking C minus whichever one you have.  That helps solve problem #2.

Why not use a 2-of-3 multisig address?

You have that working already?

-MarkM-

The problem I see with trying to defeat Rubber-Hose Cryptanalysis is that if the attacker is wiling to torture you to get access to your data (this is the premise of this thread), but you cannot give him access, then he might torture you anyway just in case. I would not rely on an attacker being reasonable.

So if you actually are at the mercy of the attacker in such a situation, then it seems you better be able to give the attacker access to your information. That is, unless you would actually prefer to suffer torture or die than give up your data.

It goes without saying but it's good to say it.

I think it's less applicable for a company though, or shared assets.

Also, perhaps it's a deterrent. If they cut off one finger and you still can't give them what they want, are they going to cut the rest off? What if they know before all this that you don't have access?

I agree that it might not be a solution, but, like a burglar alarm, it can be a deterrent.

An attacker willing to rubber-hose someone probably plans to kill them in the end one way or another.  So the choice comes down to:

  1) A shorter less painful death with the attacker getting the BTC (or whatever he/she's looking for.)

  2) A longer more painful death with the attacker coming away empty-handed.

A practical advantage of #2 is that there would be more opportunity to convince the attacker that they may be able to end up with something by keeping you alive longer.

The best solution in my mind is to arrange a credible deterrence solution.  Something akin Assange's 'insurance.aes256' file perhaps.  I think that Dr. Strangelove defined deterrence best to my way of thinking:

  "Deterrence is the art of producing in the mind of the enemy... the fear to attack" (55:09)