Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am using ruby and have the following encryption algorithm:

 @@secret_key = Digest::SHA256.hexdigest(key)
 encrypted = Encryptor.encrypt("encrypt this", key: @@secret_key)
 encoded = Base64.encode64(encrypted).encode('utf-8')

The problem I am trying to solve: If a hacker gets a hold of my database they will not be able to reverse engineer the stored 'encoded' column.

Is this strong enough? Essentially, encoded column is a user_id.

share|improve this question
Hmm, ECB mode? Awful. – rook Sep 6 '12 at 0:32
What algorithm(s) does Encryptor.encrypt() implement? Do you have a pointer to documentation for it? How is the key chosen, stored, and managed? – D.W. Sep 6 '12 at 5:53
The weakest part of any "strong" encryption algorithm is the key. Secure key generation and storage is ... Key. Choose a strong encryption algorithm (AES is a good one). Then protect the key. That's your best bet. – ZnArK Sep 6 '12 at 13:32
The encryptor uses 'aes-256-cbc'. Right now the key is manually generated by me, and stored in a system variable depending on whether it's in production/dev or integration env. – Kamilski81 Sep 6 '12 at 15:10
If you store the key in roughly the same place you store the encrypted data, what's the point? – David Schwartz Sep 8 '12 at 3:32

When the question is:

How do I know if my encryption algorithm is strong enough?

then the probable short answer is:

  • It is not strong.
  • It is strong enough.
  • It misses the point.

When professional cryptographers design an algorithm, they always assume that what they produced is weak. They will not trust it until it has been seriously looked at by their "fellow" cryptographers (who are actually their competitors, and a rather fierce bunch, though generally good humoured). It would not be wise, for a non cryptographer, to be less cautious than that.

Your algorithm is probably strong enough, where "enough" means "enough not to be the weakest point in your system". It takes really special effort to make a cryptographic algorithm which is so pathetically weak that attackers find it worthwhile to break it upfront (an example is CSS used on DVD, but that's still quite rare).

Your algorithm probably misses the point because most of security is not about cryptography ; cryptographic algorithms fulfill an important role, but with a narrow scope. I spend my days explaining to people that the magic crypto dust they sprinkled all over their systems is not as magic as they assumed (e.g. no, encrypting a SQL database does not prevent an attacker from successfully altering its contents by modifying the files on the disk).

It is possible that your algorithm (about which you give no detail at all) is actually strong, and fulfills a point which is relevant to your situation. Possible, but, as experience shows, not probable.

share|improve this answer

OK - so first it sounds odd that you are encoding a "user_id" (which sounds to me like a username) which I would think of as a relatively public peice of information - and not a password or something similarly secret - but the question is really about encryption, so I digress...

"Strong enough" for any encryption algorithm is rated by how long will it take to decrypt the text without having the key (presuming that you've hidden away your secret key in a good way). No algorithm is "perfect" except the classic One Time Password - which is a fine academic example, but not so useable in 99% of cases, as it requires the same size key space as the data encrypted, and so you will be constantly generating and storing new key - which raises its own security concerns.

So.. any realistic algorithm is considered "strong enough" if it will take longer to decrypt the material w/out the key than the information is worth. So - if the information is my lunch plans for tomorrow, it's likely that my encryption algorithm may only need to delay an attacker 24 hours by which time, the event will be over, and it wouldn't matter cause you can't find me there anymore... but it may matter for years, if my lunch was some historic event or something.

So the factors of encryption cracking calculation include: - what are the weaknesses of the algorithm - some algorithms can have weak key sets that are eaiser to decrypt, others can get proved to add little value (some forms of DES)

  • what is the size of the key space - if all keys are equally secure, then the obvious way to crack the algorithm is to try every possible key of the given size - how many keys is a factor of storage size and the nature of how keys are chosen (for example, prime numbers are used in assymetric encryption)

  • how hard is testing a decryption - how long will it take to try a test with a given key choice?

So... in a simple algorithm, time to crack can be:

# of keys in key space X time to test a key

That is usually factored over how many resources can you reasonably expect a hacker to have? A small organization may have 10-50 machines. A nation state may have millions. What is the nature of the threat - how much computational power can they resonably have? You don't necessarily assume its limited by thier purchasing power at Best Buy - if they are technically sophistcated, they have a massively parellel botnet of malicious software on innocent user machines doing their computation.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.