views:

262

answers:

9

I am just wondering if you are supposed to write a sort of really secure application with data being transmitted over insecure networks, what kind of encryption algorithm will you use it in order to make it safe ? I know several c++ libraries for encryption providing nice functions with different algorithms, but i'm not quite sure which cipher to use - AES, DES, RSA, Blowfish or maybe something more different ?

Please provide your ideas and suggestions. Thank you.

A: 

Actually, we may not need to know all the details. But, IMHO, cascade these algorithms with Chain Of Responsibility Pattern, or Composite + Strategy.

baris_a
Is this a joke?
MK
+1  A: 

You have listed too few requirements for your encryption needs. It depends on circumstances.

For example, if both end-points of the communication link are trusted, you could just worry about encryption and have both of them produce public-keys for the other end to encrypt information with. In this case, RSA would be my personal choice.

However, if you do not trust the other end-point, and am using the encryption to determine whether it "has the key", then you would be counting on preset keys, rather than private/public encryption. In this case, Triple DES (DES is considered a little weak these days) may be a good choice.

Hope this helps!

Etamar L.
I agree with your first paragraph - use of RSA. Your second paragraph is out of date. Triple DES is considered a little weak these days. AES is a better choice, or Serpent, or Blowfish, the other two AES finalists.
Ninefingers
@Ninefingers: Blowfish wasn't an AES finalist. Twofish was -- if I recall correctly. Blowfish is an older cipher that was intended to be a good DES alternative.
sellibitze
+5  A: 

While some encryption algorithms are easier to break then others, the weak spot is more about key generation. If your key generation algorithm is predictable, it will be easier to figure out your key and decrypt the packet.

So, I wouldn't sweat which encryption algorithm (AES is fine). But make sure you have a good source of real randomness to generate your keys.

If you are on any of the common POSIX OS, look into using /dev/random to generate your key.

R Samuel Klatchko
and storage. You can use all the crypto in the world, but if I can get hold of your key, it is wasted effort.
Ninefingers
+4  A: 

use AES for data encryption and use RSA to exchange AES key between parties

Wajdy Essam
+1 this is how ssl works in simple terms. RSA is considered too "time expensive" for all of the data (whereas AES is much more efficient) but the public private key interface is needed for security / transfer of the AES key.
Ninefingers
+1 @op: if, when asking, you include AES and RSA in the same list of ciphers then you really need to go and study some more
Patrick
or use DH for key exchange (saves you having to create certs or key pairs etc) and then AES in chaining mode. Of course use certs if you want end point authentication
pm100
+1  A: 

Any of the well know ciphers have well understood levels of security so that part is easy. I'd be more concerned about the quality and trust level of the library you use and bugs in your use of it. Have you considered using external programs like ssh to do the key gen and handle the connection, and drive that with an API library?

justinhj
+1  A: 

Crypto++, perhaps the best known, largest, and best crypto library for C++, contains several algorithms you can use. It can also give you a good cryptographically secure random library for use with these algorithms.

According to their FAQ, that depends quite a bit on what you want to do. From their recommended list of algorithms:

block cipher: DES-EDE3, AES, Serpent (Serpent is slower than AES but has a larger security margin and is not vulnerable to timing attacks.)
stream cipher: any of the above block ciphers in CTR mode
fast stream cipher: Salsa20, Panama, Sosemanuk (available in version 5.5)
hash function: SHA-256, SHA-512, Whirlpool
message authentication code: HMAC/SHA1 or HMAC with one of the above hash functions
public key encryption: RSA/OAEP/SHA1, ECIES
signature: RSA/PSS/H, ECDSA/H, which H one of the above hash functions
key agreement: DH, ECDH
random number generator: RandomPool, AutoSeededRandomPool

We can't give an exact answer because there isn't one without knowing more about what you're trying to accomplish.

Billy ONeal
A: 

First of all you have to split up symmetric block ciphers with public key ciphers:

  • they have really different performances
  • their implementation is really different
  • their strenghts/weaknesses are based upon different factors

By the way:

  • DES is not considered secure anymore, you should always avoid using it
  • AES is still considered safe (you could use 256 bits keys)
  • RSA's (and other public key algorithms like ElGamal, Ellipctic Curve) security is based on the hardness of the mathematical problems on which these algorithms are based. For example: number factorization. If the number of bits you use to store the keys are big enough you can consider them enough safe.

However things can change according to the power of CPUs in few years so you shouldn't consider them safe forever..

One thing to consider is that public key ciphers are usually slower than block ciphers, that's why commong protocols usually use the first ones to exchange a simmetric key that then is used with an algorithm like AES.

Jack
3DES is still considered secure.
Billy ONeal
+2  A: 

The answer is: don't. If it has to be secure and you ask this question it means that you need to find a security expert to do it. You are not going to design a secure protocol by asking for help on SO. You can [maybe] use an existing protocol such as ssh or TLS, but if you roll your own you will fail.

MK
+1  A: 

If you want to transmit data over an insecure network, you need more than a cipher, you need a secure protocol, potentially including key distribution and authentication.

If you're really serious about crypto implementation, not just doing it to understand the basic mathematics of cryptography, then you need to do more than implement the number-crunching correctly. You also need to worry about side-channel attacks. For example, if your implementation takes a different amount of time depending on the key, as is common, then an attacker can deduce information about the key from your various response times. And that's just the basic algorithm, never mind putting it all together.

This is in general an unsolved problem and an area of ongoing research. Most or all implementations are flawed, although for the latest versions of well-used libraries probably not in a way that anyone has publicly announced they can exploit. Timing-based attacks on OpenSSL have been demonstrated in the past, albeit only on a highly predictable local network AFAIK. You can basically spend as long as you like on it, up to and including your entire career.

In practice, just use SSL, in whatever implementation comes with your platform.

Steve Jessop