Comparison: complexity measures vs. security Assume that you want to compare several cryptographic primitives (say, encryption schemes), and choose one. You need to consider several complexity measures, such as the key length, encryption time, decryption time, etc. In order for the comparison to be fair, all primitives in question must provide the same level of security.

As an example, let us consider RSA, ECC, and NTRU. Assume that we want the cryptosystem to be secure against a passive adversary, whose computational power is limited to at most $2^{100}$ operations. By "passive adversary", we mean that the adversary is limited to chosen-plaintext attacks (since we are comparing public-key encryption schemes). Now, we want to know the key length to be chosen for each scheme.

To answer this question, we consider the complexity of the most efficient attacks against RSA, ECC, and NTRU, which in turn requires a great knowledge of the literature.


  Is there any resource/survey (website, paper, tool, etc.) which helps in such comparisons?


Note: The website keylength.com, while being a helpful tool in its own right, is not an answer to this question. The reason is that keylength.com merely recommends a minimum key length to be used in different scenarios (say symmetric or asymmetric encryption), but leaves out most of the concrete schemes (say, NTRU, twofish, serpent, etc.)
Not sure what you are trying to do but are you not approaching it the wrong way? 

NIST already recommends algoorithms/ciphers for use in their environments. This means they have vetted these and are deemed secure. Now you want performance as well. So use openssl and see which of the algorithms are of acceptable performance to you. Like you said choose key lengths that provide the same level security when comparing different algorithms. That way your performance numbers will be comparable.

Also I wouldn't try to go beyond any algorithms NIST recommends. For example AES is good for any application. There is no reason to use or try twofish. There are enough ways to shoot yourself in the foot just by using AES itself. Stick to one and that way even if you are creating some recommendations for your users/employees its less complicated.

Hope that helps.