Question

Is there an (easy) way to encrypt data so that it takes a certain amount of cpu hours to decrypt it? Maybe a series of encryptions with short key lengths, a variable one-way function or anything?

It's probably not of great use, but how would this encryption scheme be called and are there tools for it?

edit:

To get no varying results for the brute force break time, shouldn't I use many rounds with an xor-feedback?

I just came up with this algo (for a symmetric block cipher with equal value and key length)... maybe it's non-sense

round 1

create a zero-block
create a random-block-1
encipher value:zero-block with key:random-block1    => gives lock-output-1

round 2

create a zero-block
create a random-block-2
encipher value:zero-block with key:random-block2    => gives temp
xor temp with random-block-1                        => gives lock-output-2

and so on

The xor operation with random-block-1 would be there so that the unlock routine will have to find random-block-1 before it can start brute forcing on lock-output-2.

lock-output-1 + lock-output-2 .. lock-output-N would be the complete lock-output. When the unlock routine has found N key-blocks that each give zero on all lock-output blocks, it can use the N key-blocks as a whole to decipher the actual data.

Then I'd also need a formula to calculate how many rounds would give a maximum variation of e.g. 10% for the wanted amount of CPU hours.

I guess there must exist a simmilar algorithm out there.

Was it helpful?

Solution

The concept is called timed commitment, as defined by Boneh and Naor. The data you want to encrypt is said to be committed by one party (which I call the sender), such that another party (the receiver) may, at some tunable cost, recover the data.

The method described by Boneh and Naor is quite more advanced than what you suggest. Their timed commitment scheme has the three following properties:

  • Verifiable recovery: the sender is able to convince the receiver that he really did commit a proper value which the receiver will be able to recover by applying a substantial but feasible amount of CPU muscle to it.

  • Recovery with proof: once the recovery has been done, it is verifiable efficiently: a third party wishing to verify that the recovered value is indeed the one which was committed, can do so efficiently (without applying hours of CPU to it).

  • Immunity against parallel attacks: the recovery process cannot benefit from having access to a thousand PC: one cannot go much faster than what can be done with a single CPU.

With these properties, a timed commitment becomes a worthwhile tool in some situations; Boneh and Naor mainly discuss contract signing, but also honesty preserving auctions and a few other applications.

I am not aware of any actual implementation or even a defined protocol for timed commitments, beyond the mathematical description by Boneh and Naor.

OTHER TIPS

You can encrypt it normally, and release just enough information about the key such that a brute force attack will take X CPU hours.

No, you can't do that reliably, because

  • the attacker could rent a powerful computer (a computing cloud for example) and use it for highly parsllel much faster attack
  • so far computers become faster and faster as time passes - what took a day yesterday might take one minute in two years

Well, to know the amount of CPU hours for any kind of decryption, it does not really matter how the encryption takes place. Instead you would have to make sure

  • what decryption algorithm the decrypter will use (perhaps a non-so-far invented one?)
  • which implementation of that algorithm he will use
  • which CPU/hardware he will use.

Each of these 3 parameters can make a difference in speed of at least a factor 1000 or more.

A cryption algorithm is considered as cracked when someone found a way to get the password faster than a brute force attack (in average).

It's the case for some algorithms like MD5 so make sure you pick one algorithm that isn't cracked (yet)

For other algorithms, even if they are not cracked, they are still vulnerable to brute force attacks... it might take a while but everything that is crypted might be decrypted... it's only a question of time and resources.

If a guy have a huge zombie computer farm working for him around the world, it might take few hours to crack something that would take years for a guy with a single laptop.

If you want a maximum of security, you can mix a couple of existing cryption algoritm with custom algorithm of your own. Someone can still try to crack your data, but most likely, unless you are dealing with national top secret data, it will probably never append.

It is relative, a computer is going to decrypt fast depending on its computing power, and the selected algorithm to encrypt depends on the data you want to protect, so with a normal computer a good encryption algorithm an average computer takes its time to decrypt cause there always is a price for good things, but i recommend you Elliptic curve cryptography cause it has power to encrypt and its time to be decrypted is very good, you can take a look on it.

that is what i can say about it.-

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top