Since this is heading towards the top of HN, I figure it's worth responding to the specifics here:
AES-GCM
As tptacek says, this has pitfalls on some platforms. I also dislike exposing AES cores to malicious data, which is my primary reason for preferring a hash-based MAC construction.
Avoid: key sizes under 128 bits.
My recommendation for 256-bit symmetric keys isn't because I think AES-128 can be broken mathematically; rather, it's because AES implementations have a history of leaking some of their key bits via side channels. This is less of an issue now than it was five years ago (implementors have found and closed some side channels, and hardware AES implementations theoretically shouldn't have any) but given the history of leaking key bits I'd prefer to have a few to spare.
Avoid: userspace random number generators
Thomas and I have argued about this at length; suffice to say that, as someone who has seen interesting misbehaviours from kernel RNGs I'd prefer to use them for seeding and then generate further bits from a uesrspace RNG. (Thomas's counterargument, which has some validity, is that he has seen interesting misbehaviours from userspace RNGs. This largely comes down to a question of whether you think the person writing your userland crypto code is more or less prone to making mistakes than the average kernel developer.)
avoid RSA
Thomas is correct to imply that a random RSA implementation is more likely to be broken than an average elliptic curve implementation. This is true for the same reason as a random program written in python is more likely to have bugs than a random program written in Brainfuck: Inexperienced developers usually don't even try hard problems. On the other hand, for any particular developer, an RSA implementation they write is more likely to be correct than an elliptic curve implementation they write.
I also continue to be wary of mathematical breakthroughs concerning elliptic curves. Depending on the amount of new research we see in the next few years I might be comfortable recommending ECC some time between 2020 and 2025.
use NaCl
This is not entirely a bad idea. The question of "implement yourself or use existing libraries" comes down to the availability of libraries and whether the authors of the library are more or less prone to making errors than you; "random developer vs. NaCl developers" is straightforward and doesn't have the same answer as "random developer vs. OpenSSL developers".
you discover that you made a mistake and your protocol had virtually no security. That happened to Colin
Just to clarify this, the (very embarrassing) bug Thomas is referring to was in the at-rest crypto, not the encrypted client-server transport layer.
Online backups (Was: Use Tarsnap): Remains Tarsnap. What can I say? This recommendation stood the test of time.
* If you're concerned about attacker data hitting the AES core, Salcha20+Poly1305 doesn't have that problem, and is generally preferable to AES-GCM in every scenario anyways. There is no scenario I can think of where you can do CTR+HMAC and can't do Salcha20+Poly1305. If you have to stick with standards-grade crypto, GCM is your best bet.
* The track record of userspace RNGs vs. kernel RNGs speaks pretty loudly. In any case, we should be clear that you're advocating for "bootstrap with /dev/urandom and then expand in-process", not, like, havaged or dakarand. We're closer on this than people think.
* I'm not even talking about people writing their own RSA. Do I need to say that? If so, recommendation #1: don't write your own RSA. I'm saying that all else equal, if you're using good libraries, still avoid RSA, for the reasons I listed.
* In fairness, the CTR problem you had is also a threat to GCM. This used to be why I recommended CBC a few years ago: because we kept finding gameover CTR bugs in client code, and not so often CBC bugs. My opinion on this has changed completely in the last year or so.
If you're concerned about attacker data hitting the AES core, Salcha20+Poly1305 doesn't have that problem, and is generally preferable to AES-GCM in every scenario anyways.
Right. And I'm optimistic about Salcha20 and Poly1305, but I'd like to see a few more years of people attacking them before I would be willing to recommend them.
we should be clear that you're advocating for "bootstrap with /dev/urandom and then expand in-process"
Right. Or to be even more precise: Use HMAC_DRBG with entropy_input coming from /dev/urandom.
Also: For $DIETY's sake, if you can't read /dev/urandom, exit with an error message. Don't try to fall back to reading garbage from the stack, hashing the time and pid, or any other not-even-remotely-secure tricks. Denial of service is strictly superior to falsely pretending to be secure in almost all conceivable scenarios.
AES-GCM
As tptacek says, this has pitfalls on some platforms. I also dislike exposing AES cores to malicious data, which is my primary reason for preferring a hash-based MAC construction.
Avoid: key sizes under 128 bits.
My recommendation for 256-bit symmetric keys isn't because I think AES-128 can be broken mathematically; rather, it's because AES implementations have a history of leaking some of their key bits via side channels. This is less of an issue now than it was five years ago (implementors have found and closed some side channels, and hardware AES implementations theoretically shouldn't have any) but given the history of leaking key bits I'd prefer to have a few to spare.
Avoid: userspace random number generators
Thomas and I have argued about this at length; suffice to say that, as someone who has seen interesting misbehaviours from kernel RNGs I'd prefer to use them for seeding and then generate further bits from a uesrspace RNG. (Thomas's counterargument, which has some validity, is that he has seen interesting misbehaviours from userspace RNGs. This largely comes down to a question of whether you think the person writing your userland crypto code is more or less prone to making mistakes than the average kernel developer.)
avoid RSA
Thomas is correct to imply that a random RSA implementation is more likely to be broken than an average elliptic curve implementation. This is true for the same reason as a random program written in python is more likely to have bugs than a random program written in Brainfuck: Inexperienced developers usually don't even try hard problems. On the other hand, for any particular developer, an RSA implementation they write is more likely to be correct than an elliptic curve implementation they write.
I also continue to be wary of mathematical breakthroughs concerning elliptic curves. Depending on the amount of new research we see in the next few years I might be comfortable recommending ECC some time between 2020 and 2025.
use NaCl
This is not entirely a bad idea. The question of "implement yourself or use existing libraries" comes down to the availability of libraries and whether the authors of the library are more or less prone to making errors than you; "random developer vs. NaCl developers" is straightforward and doesn't have the same answer as "random developer vs. OpenSSL developers".
you discover that you made a mistake and your protocol had virtually no security. That happened to Colin
Just to clarify this, the (very embarrassing) bug Thomas is referring to was in the at-rest crypto, not the encrypted client-server transport layer.
Online backups (Was: Use Tarsnap): Remains Tarsnap. What can I say? This recommendation stood the test of time.
I have to agree with Thomas on this one. ;-)