Question

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??)

Was it helpful?

Solution

Use AES. Speed was a major consideration in its selection to replace DESEDE. On modern PC hardware, it tends to be faster than Blowfish, and as a standard, it's more likely to have specialized hardware support.

By the way, all ciphers encrypt long integers—every stream of bytes is an integer, represented in base-256.

OTHER TIPS

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?

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.

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,

simple symmetric encryption of long to String (and back) in java

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