Counter mode always seemed like an argument against 64-bit blocks, since it implies a 32-bit counter and a 32-bit nonce.

In general I agree and am as anti-64-bit blocks as it gets; but I don't think it matters in the specific case of SSH.

3DES has become fairly weak, and it seems like most cryptographers wouldn't recommend it - especially if you are trying to defeat the NSA - originally it had a 168 bits, but with known attacks, it's reckoned to have around 80 bits of security left, which given DES was considered insecure with 56 bits makes it sound iffy at best.

Well...there's "insecure"...and then there's really insecure.

DES (and by extension 3DES) isn't, per se, "insecure" at 56-bits except that technology has progressed from the mid-1970s such that an exhaustive search of the keyspace (e.g. brute force) is now practical in reasonable time. DES is resistant to differential analysis and even more modern techniques that could seriously reduce DES security are theoretical exercises at best (like those requiring terabytes of known plain-text to derive a key, or those only applicable to reduced-round implementations).

Yes, I'm aware that to a cryptographer, "theoretical attack possible" == "OMFG insecure cipher", and that attitude is a good thing. If DES was an AES candidate we'd never pick it. But from a practical standpoint, baring implementation mistakes or operational missteps, no one using known 2015 tech and technique is cracking 3DES before the heat death of the universe (or at least before we're long turned to dust).

That said, can you provide a reference to a practical (that is, not the linear cryptanalysis stuff from Davies) attack which reduces 3DES to 80-bits of effective security? If it's there, I missed it, and would invalidate what I've said.

> Hard-to-implement NIST curves suck, whereas GCM and Poly1305 are recommended.

I've always wondered this about DJB - he preaches the gospel of ease-of-implementation with Curve25519 and Salsa/Chacha20, but then for a MAC he has... Poly1305. I guess speed trumps everything?

Poly1305 is significantly easier to implement than GCM. Carter-Wegman MACs have been a research focus for DJB since the 1990s.

Sure. I'm not saying Poly1305 is problem for DJB, just for anyone else trying to implement it, which is a concern DJB has with his other crypto, but not here.

GCM is harder for everyone else to implement than Poly1305. It's harder in the "literally trickier to implement" sense, and in the "needs hardware support to be performant and secure at the same time".

> "needs hardware support to be performant and secure at the same time"

So does Poly1305; it just so happens that most popular processors have strong hardware support. Here's an exercise: implement both GHASH and Poly1305 for MSP430.

I think you're calling fast multipliers "hardware support", which is fair, but the hardware support needed by GHASH is idiosyncratic to things like GHASH. CLMUL is only a few years old and GCM is its primary use case.

Implementing a truly constant-time GCM in software without CLMUL is sufficiently hard that noone has managed to create a remotely competitive implementation. They're all either an order of magnitude slower or vulnerable to cache-timing attacks.

Poly1305 isn't a walk in the park, but doesn't need special hardware support for fast constant-time implementation. Though I will agree something like HMAC is much simpler.

What do you think about 64-bit tags (particularly in the context on ssh)?

I think they're OK, but would not recommend them unless you have serious bandwidth woes.

> AES was also designed by NSA

No, it was designed by Joan Daemen and Vincent Rijmen, two Belgian academics.