[tptacek]

"SSH2-RSA" isn't an encryption algorithm. It's a description of the SSH protocol using RSA authentication.

It is easier to provide the list of things that are worth worrying about than it is to list the things that are safe. There are a lot of as-yet unbroken ciphers and constructions. So, here are the things to avoid:

* Block ciphers in the default mode ("ECB").

* The Dual_EC random number generator, which virtually nobody uses anyways. You weren't going to accidentally end up using it. Or, for that matter, any other PKRNG (random numbers produced by public key algorithms).

* RSA with 1024 bit moduli (or below); RSA-2048 is your starting point. Conventional DH at similar key sizes will be an issue too, but there's a "means/motive/opportunity" issue for RSA-1024 given its prevalence.

* MD4, MD5, and SHA1 aren't backdoored, but are broken or weak. But: all three are survivable in HMAC (don't use them, though). SHA2 is your best all-around hashing bet right now.

* The NIST P- curves. There's no evidence to suggest they're backdoored, but (a) the rationale behind their generation is questionable and (b) they have other annoying properties.

So far as I can tell, you are now fully briefed on the "distrusted" crypto.

Don't build your own crypto. Use PGP for data at rest, TLS for data in motion, and NaCl for the rare in-between cases.

[parfe]

>* Block ciphers in the default mode ("ECB").

You can plainly see the problem ECB causes in this example image: http://legacy.kingston.com/secure/image_files/Figure2_ECB.jp...

[tptacek]

This is a perennial favorite illustration of "what's wrong with the default mode", but it's biggest problem is that given chosen plaintext, you can often decrypt it a byte-at-a-time.

[hackcasual]

For the record DH key sizes are smaller than RSA keys of the same strength based on our current understanding of the computational effort involved in attacking them. DH-256 should be considered on the verge of too small. 340 or 512 will be necessary going forward.

[tptacek]

I think I'm probably confusing terms here; you're referring to the size of "a", and I'm referring to the size of "p".

Perhaps 'pbsd will be around in a bit to resolve whether the index calculus will push the size of p or a first; my understanding is that it's bounded by the size of the modulus, and that most of the work it does is independent of the specific element of the group you're attacking.

I am definitely a lot fuzzier on DH key sizes than on RSA; we're getting into cryptanalytic attacks that don't have a lot of relevance to the kind of work I do.

[pbsd]

The NFS complexity for factorization and discrete logarithm is asymptotically the same. In practice, the matrix step is more costly in discrete logarithm, but this should increase the bit security by at most a handful of bits, which is not enough to justify differentiating DL estimates from RSA estimates.

This refers to the size of p, the prime modulus. Sizes of exponents and/or subgroups are not affected by the complexity of the NFS, so they generally only need to be twice the target bit security to avoid birthday-type attacks.

[tptacek]

So it's the size of p that matters most in practice, assuming other parameters are sane.