High cost encryption but less cost decryption

Question

I want that user/attacker to encrypt the data and send to server. Now I want an algorithm that is completely opposite to standard algorithms (fast to use, hard to decrypt), i.e it is very hard to encrypt the data like passwords using a key send by the server, to protect against random attacks, but very easy to decrypt so server consumes very less time in validating the user, but it becomes very hard for attacker, to every time encrypt new trial password with the key send by server.

Once again I am not talking about SSL.

If you have a trusted channel, like SSL, then you can just send the password, and use something like PBKDF2 to store the data to verify against. In all other scenarios, you need to take care of man in the middle attacks, and no scheme will comply with that, unless you have some kind of trust system (e.g. PKI). — Maarten Bodewes, Mar 19 '12 at 11:15
Hi owlstead, I honestly don't get how SSL will protect against dictionary attacks. Also AFAIK about PBKDF2, the salt resides on server only, so how that helps, unless the server is not compromised, which is hard. — Priyank Bolia, Mar 19 '12 at 11:50
PBKDF2 is used to protect against dictionary attacks, SSL is used to protect data (the password) in transit. You are trying to create your own authentication scheme, which **will** have significant shortcomings. — Maarten Bodewes, Mar 19 '12 at 13:40
I still not get, PBKDF2 is for hashing. Hash is in DB. Dictionary attack is from web interface/form. Attacker might not be aware of the hashes, then how comes PBKDF2 comes into picture. Isn't PBKDF2 is done on server. — Priyank Bolia, Mar 19 '12 at 16:50
Dictionary attack is from stolen DB, and that's what you protect against with PBKDF2. You protect against online dictionary attacks by allowing a certain number of incorrect logins, or by adding some kind of delay between logins. The only real way to protect against eavesdropping/man-in-the-middle is some kind of PKI, normally SSL. — Maarten Bodewes, Mar 19 '12 at 20:32

score 5 · Answer 1 · answered Mar 19 '12 at 07:50

5

One silly idea that might work really well is to attach a "puzzle" to the encryption scheme. Make it so that in order to post encrypted data to the server, you have to solve some known NP-hard problem (for example, finding a satisfying assignment to a large Boolean formula) and send the answer along with. The server can then easily verify the solution, but under the assumption that P ≠ NP, clients trying to post data have to do a superpolynomial amount of extra work, preventing them from flooding your server.

Hope this helps!

answered Mar 19 '12 at 07:50

templatetypedef

362,284
104
897
1,065

sound interesting, but I am weak in mathematics, do you have some examples of what kinds of problems or some links like Martin B gave the proof-of-work scheme. – Priyank Bolia Mar 19 '12 at 09:00
If you do a search for "NP-complete problem," you'll find a huge array of problems that are conjectured to be fundamentally hard to solve. There are all sorts of problems in this vein, and I'm sure that you'll be able to find something simple that you can implement. – templatetypedef Mar 19 '12 at 17:11

score 5 · Accepted Answer · answered Mar 19 '12 at 08:33

5

It sounds as if you're looking for a proof-of-work scheme -- one of the applications for such a scheme is just what you describe: To force a client to do a certain amount of work and so prevent it from flooding a server with requests.

answered Mar 19 '12 at 08:33

Martin B

23,670
6
53
72

Thanks for the link, this looks somewhat I am looking for. – Priyank Bolia Mar 19 '12 at 08:58
So, I read about hashcash, and it looks to do the job, also there are already implementation available https://github.com/007/hashcash-js – Priyank Bolia Mar 19 '12 at 09:23

score 0 · Answer 3 · answered Mar 19 '12 at 08:08

You can use RSA signatures (e.g. PKCS#1).

Your server may accept answers only if they are signed with a certain RSA key whose private part you distributed earlier. The server uses the public part.

RSA has the property that verification is much quicker than signing when you select a small public exponent (typically called e, for instance e=3) by a factor or x10 or x100, depending on the key length and on whether your clients are smart enough to use CRT.

RSA key generation is extremely slow, but it is probably sufficient to use one key for all clients, as long as you include a challenge in your protocol to foil replay attacks.

Finally, RSA signing does not give you confidentiality.

High cost encryption but less cost decryption

3 Answers3

Linked