views:

81

answers:

4

Can someone suggest a fast 2 way encryption algorithm for long ints?

My candidates are:

  • AES: the Advanced Encryption Standard specified by NIST FIPS-197.
  • BLOWFISH: the Blowfish algorithm defined by Bruce Schneier.
  • DES: the Data Encryption Standard algorithm defined by NIST FIPS-46-3.
  • DESEDE: the "Triple DES" algorithm defined by NIST FIPS-46-3.

Edit -

Speed is more of a factor than security. The actual request was to "obfuscate" ids being passed over internal web services so in the event that an id is ever exposed one could not guess other ids by adding 1. (an argument for UUID keys over auto-increment longs??)

+1  A: 

I don't need a public key. The requirement is to encrypt ids in a database as they pass between machines. Both machines will have the salt

Then, XOR?

a paid nerd
On of the environments will be ColdFusion which does not have built in support for XOR although this is about right. Quick and simple.
Nick
No, absolutely not! If the threat model is that an attacker will add 1 to an ID to get the next ID, then he can take (ID XOR key), flip the last bit, and have a 50% chance that the result is ((ID+1) XOR key). So if all you've done is XOR, then he can still spoof messages as if he knew that next ID, even though he doesn't know it.
Steve Jessop
+1  A: 

What is your primary criterion for selection? Speed or security? That's the fundamental trade-off in the cryptography business. Here's a set of benchmark results for Crypto++. They won't tell you everything, but you will be able to tell which algorithms are generally faster than others. Here's a whitepaper discussing the relative strengths of some popular algorithms. Determining strength is a very hard thing to do in the general case, although some algorithms have been given enough attention that their strengths and weaknesses are fairly well known (DES, RSA, etc). A conventional rule of thumb is that longer keys imply greater strengths, but you gotta be very careful with that. I suspect that in your case, either AES or Blowfish will be fine. AES will probably be somewhat more widely supported, but really - either would probably do. Stay away from DES unless speed is a critical factor.

Ben Collins
+2  A: 
erickson
+1  A: 

If security is your main concern, I would go with AES.

However, the ciphertext may be too big for your database. If you add IV, padding, it's 64 chars in hex at least. You can use the algorithm I posted here if you ran into such limit,

http://stackoverflow.com/questions/1403785/simple-symmetric-encryption-of-long-to-string-and-back-in-java/1408070#1408070

ZZ Coder