Pages:
Author

Topic: Defeating Rubber-Hose Cryptanalysis - page 2. (Read 3903 times)

hero member
Activity: 630
Merit: 500
July 31, 2012, 07:50:38 AM
#10
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.
hero member
Activity: 602
Merit: 513
GLBSE Support [email protected]
July 31, 2012, 07:30:00 AM
#9
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.
newbie
Activity: 25
Merit: 0
July 30, 2012, 02:43:59 PM
#7
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.

Truecrypt can do this. 

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

See also http://marutukku.org/
hero member
Activity: 784
Merit: 1000
0xFB0D8D1534241423
July 30, 2012, 12:14:55 AM
#6
Cool, SSSS takes BTC donations at 1BWary.
sr. member
Activity: 476
Merit: 250
Tangible Cryptography LLC
July 29, 2012, 11:56:36 PM
#5
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).
legendary
Activity: 1260
Merit: 1000
Drunk Posts
July 29, 2012, 11:53:26 PM
#4
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.
legendary
Activity: 1246
Merit: 1016
Strength in numbers
July 29, 2012, 11:50:01 PM
#3
Regulate rubber hoses?
sr. member
Activity: 658
Merit: 250
July 29, 2012, 11:29:54 PM
#2
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.

Shamir's Secret Sharing Scheme (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.

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?

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 (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.

hero member
Activity: 900
Merit: 1000
Crypto Geek
July 29, 2012, 10:28:14 PM
#1
 I wonder if there should be a forum dedicated just to security...

I'm sure you're all familiar with


 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.
Pages:
Jump to: