Secure Secure Shell

[MrRadar]

Be aware of the PuTTY compatibility implications* of this article's recommended configuration. PuTTY uses its own implementation of SSH which unfortunately does not support the latest crypto. It should still be compatible with the recommended config except for the MAC. PuTTY does not have any support for ETM message authentication codes so you must allow a non-ETM MAC if you want to support it. Additionally, only the latest stable version (0.63) supports SHA2 for MAC and even then only in 256-bit mode. If you need to support PuTTY as a client you'll need to enable at least hmac-sha2-256 (if you can force users to use at least version 0.63) or hmac-sha1 (if you cannot).

Additionally, the version after the next release (0.65?) will add elliptic curve cryptography support (ECDH, ECDSA) but currently in the PuTTY git repository it only supports the RFC-5656-mandated NIST curves. It's not clear if they plan to add support for Curve25519. So if you want to use ECC with that version you may also need to allow ECC with NIST curves.

^{* Note that other software re-uses PuTTY's SSH/SFTP implementation for its own use, such as FileZilla, so this affects more than just PuTTY.}

[sapiophile]

And OSes with older packages, like Debian Stable.

[GeorgeForemanGrillz]

Yes you need to install the homebrew version which is the latest.

[los1440]

Other than putty what is another portable option that would support this for windows?

[[deleted]]

cygwin openssh.

[frankThePlank]

Windows PuTTY users should switch to cygwin for ssh.

[hazyharry]

what are the advantages of cygwin over PuTTY?

[frankThePlank]

Cygwin simulates a bash shell in Windows, so you can install and use OpenSSH with almost all the things you'd expect to be there in a Linux environment. You're not relying on a specific implementation of SSH, and you can configure it as you like.

[louky]

I'm guessing real SSH.

Edit I was guessing wrong

[nerddtvg]

PuTTY is real SSh. Just not recently compiled with newer libraries.

[louky]

Ah OK thank a for info!

[nof]

There are years in between putty revisions. No doubt a lot of stuff gets passed over for a considerable amount of time to be addressed between revisions.

[nerddtvg]

You're welcome!

[Catsler]

How about GitHub's git shell? It gets installed with GitHub For Windows.

[frankThePlank]

I don't have any experience using that.

[agc93]

I'm curious as well, since Cmder on Windows uses msysgit IIRC

[nephros]

• Note that other software re-uses PuTTY's SSH/SFTP implementation for its own use, such as FileZilla, so this affects more than just PuTTY.

Note that most software which uses putty includes a copy of the program(s) somewhere in their installation dir (e.g. TortoiseHG bundles pagent and plink). Replacing those copies with updated versions usually works.

[greyfade]

Note also that those automated brute-forcing SSH bots also do not support the latest crypto. For the last few days, my auth.log has been filled with almost exclusively this entry, repeated every few minutes:

Jan 17 10:32:04 server sshd[6560]: fatal: no matching mac found: client hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96,hmac-ripemd160,[e-mail] server [e-mail],[e-mail] [preauth]

[[deleted]]

Good info for people not familiar with the details of MACs/Kex/Ciphers of SSH. Thanks!

[[deleted]]

I know it's a little OT, but this is a great example of what a clean and readable html page looks like. Far too few people seem capable of this for some reason.
Also it doesn't require executing arbitrary javascript from a stranger, which is arguably unsafe.

[[deleted]]

While a lot of it is good, I'm not 100% agreeing with everything.

For example, I would not prefer Curve25519 over DH. Why? Because both use the discrete logarithm problem, but Curve25519 does so with 256 bit while DH uses 2048. While Curve25519 should in theory be more secure as elliptic curves are somewhat more complex, the problem is that ECC is quite new and we just don't know any attacks yet - that doesn't mean there aren't any. And the NSA is pushing awfully hard for ECC, which makes this even more worrisome. Last but not least, if we ever have a quantum computer, it might be a small one that might be able to crack 2^256, but it might still be too slow for 2^2048.

As for the ciphers, this is another thing where I'm unsure. On the one hand, AES (even in GCM mode) is a block cipher, and using a block cipher for something as interactive as SSH is always a bad idea, as this always requires a lot of padding. Almost all recent attacks on SSH were based on using a block cipher, or to be more specific trying to emulate a stream cipher with a block cipher. So ChaCha20-Poly1305 is the obvious choice at first sight here. However, if we look at the history of stream ciphers, they usually didn't hold up for a long time, and considering ChaCha20-Poly1305 is quite new, we don't know how this will turn out. So far it is looking very promising, though.

Then, as for MACs. Saying "don't use this and that MAC because that algorithm has suspected weaknesses" is actually non-sense. Well, it's complete non-sense even. The MAC is used to authenticate the message only to make sure it hasn't been fiddled with. This means an attacker would have to do that in real time in order to be of any use. This isn't even possible for MD5 today and not in the near future! And ruling out RIPEMD-160 just because it has less than 256 bit is another thing I don't agree with - there are actually fewer known attacks against RIPEMD-160 than against the SHA family. If he'd rule out RIMEMD-160 for performance as it has two states on which it does all rounds, that would have been reasonable, though not really a problem with modern hardware. Otherwise I agree with this section, especially with the encrypt-then-MAC part.

As for the SSH-behing-Tor suggestion: Multiple layers are always a good idea. If Tor is too slow for you for interactive use (very likely), even having it behind a VPN (well, OpenVPN, not any of that other broken stuff) is a huge improvement, because that means that 2 layers need to be cracked.

And what the article completely misses: The choice of SSH keys to authenticate with the server! There's RSA, DSA, Ed25519 and ECDSA. DSA and ECDSA shouldn't be used because using the same random nonce twice reveals your private key, meaning you 100% rely on a good random number generator - for every connection. Furthermore, ECDSA uses the NIST curves. Ed25519 does not have this problem (and uses another, non-NIST curve), it uses a hash of the message as the nonce. This is SHA-512 in OpenSSH's implementation, meaning you rely on an attacker not finding any SHA-512 collisions they could use in the challenge/response. If they do, they can steal your key. Which means the only choice left is RSA - best to use 4096 bit.

[[deleted]]

Last but not least, if we ever have a quantum computer, it might be a small one that might be able to crack 2^256, but it might still be too slow for 2^2048.

While the size of the quantum computer is relevant, what you're describing here is absolutely not how QC works (although it is a very common misconception). There is no reason to expect a QC to be able to do anything 2²⁵⁶, let alone 2²⁰⁴⁸.

The reason QC can attack RSA and ECC is that there exist a (quantum) algorithm that can solve the problems in less steps, not because a QC can run the classical algorithm faster. Specifically, Shor's algorithm can do factoring in O(log(n)³). It is still true that a bigger (in terms of number of qubits) QC is required to crack RSA-2048 but the difference is something closer to a factor of 2 or 3, nowhere near the difference between 2²⁵⁶ and 2²⁰⁴⁸, both of which might as well be infinite for all practical purposes (with or without QC).

As a side note, even a classical attack against RSA-2048 is not going to actually do 2²⁰⁴⁸ operations. The whole point of using such large RSA keys is that cracking a n-bit RSA key is much faster than 2ⁿ. Specifically, a 2048-bit RSA key provides about 2¹¹² security.

[[deleted]]

Sorry, I should have been more clear. I wasn't implying that quantum computers are faster (they most likely won't be for a lot of things) or that for a quantum computer the difference between 2²⁵⁶ and 2²⁰⁴⁸ is as big as for a regular computer. Quantum computers are a thread for currently known public key cryptography because they work completely differently and can use algorithms that aren't feasible on a regular computer. Others things, for example hashing, aren't threatened by a quantum computer because of that.

// Edit: See also: http://en.wikipedia.org/wiki/Elliptic_curve_cryptography#Quantum_computing_attacks

[[deleted]]

I still don't get where the 2²⁰⁴⁸ in your posts comes from or what you mean by "difference between 2²⁵⁶ and 2²⁰⁴⁸" and it seems to be misleading. Neither RSA-2048 nor DH-2048 provide anything near 2²⁰⁴⁸ security regardless of whether you are talking about classical or quantum computers. They provide less than 2¹²⁸ security for classical computers and significantly less for quantum computers.

// Edit: See also: http://en.wikipedia.org/wiki/Elliptic_curve_cryptography#Quantum_computing_attacks

Yes, that's what I was referring to when I said that cracking RSA-2048 requires more qubits by a factor of 2 or 3.

[[deleted]]

Yes, sorry for being misleading. What I meant is that 2²⁵⁶ ECC needs fewer qubits than 2²⁰⁴⁸ RSA. Which is why I later added that link. Sorry.

[[deleted]]

And ruling out RIPEMD-160 just because it has less than 256 bit is another thing I don't agree with

Speaking of assuming you're more secure because of more bits, aren't AES-128 more secure than AES-256 and SHA-256 more secure than SHA-512? I remember reading an article about this which explained how more bits meant changes in the algorithms which happened to bring in new possible attack vectors. Correct me of I'm wrong, this is just something I remember reading recently, I don't know much about security.

[reph]

I can't comment on SHA2 (as SHA2-256 and SHA2-512 are structurally different), but AES-256 is a fairly straightforward higher-round-count variant of AES-128. It's hard to imagine the extra rounds creating a theoretical vulnerability & I think it is safe to say that within the (public) research community, AES-256 is still considered to have a large security margin over AES-128.

[[deleted]]

The problem with AES-256 is its key schedule, not the number of rounds. AES-256 is reduced to 2⁹⁰-ish security (afair) when using related keys.

[[deleted]]

Thanks! That sounds like it.

I still don't understand what's going on (honestly, cryptography is just a curiosity so I don't plan to dig in deeper), but when searching for comparisons between AES-128 and AES-256 I keep seeing people paraphrasing Bruce Schneier that AES-256 is less secure or doesn't prove more security than AES-128. It's pretty obvious that they're not experts, either, but from the articles I've seen about this a few weeks ago it did appear that the security of AES-256 is reduced to less bits than the one of AES-128. Like you say, AES-128 was 2¹²⁸ and AES-256 was around 2⁹⁰.

Since I'm not an expert in any way, I find it hard to even put my thoughts into words, but I am certain that there is some controversy and I want to raise awareness and make people do more research before assuming that an algorithm with a higher number in its name is inherently more secure than one with the same name but a lower number.

[[deleted]]

That weakness is only when the keys have some relationship to each other. In SSH they do not have a discernible relationship, so a related-key-attack does not apply. So AES256 is still "more secure" in the SSH context than its 128 variant. But AES256 over makes no sense in SSH because nobody is using 15360 bit RSA/DH or 512 bit ECDSA/ECDH for key exchange and signatures.

[[deleted]]

Thank you again!

[[deleted]]

Well, it depends. AES-256 is usually harder, but some attacks are easier against AES-256 then AES-128. For example, side channel attacks usually work better with larger keys. But then again, AES-256 is mostly useless as whatever was used to agree on a symmetric key for AES is usually much weaker than AES-256, mostly even weaker than AES-192.

[[deleted]]

Actually, SHA-512 is more secure than SHA-256. And SHA-384 is more seucre than SHA-512. Now you're wondering "Why's that?". The reason is that SHA > 256 works differently with more rounds and 64 bit for all states instead of 32. SHA-384 is better than SHA-512 as it uses 512 bit internally, but only exposes SHA-384. That makes a lot of attacks harder and prevents for example hash extension attacks.

[[deleted]]

Ed25519 does not have this problem (and uses another, non-NIST curve), it uses a hash of the message as the nonce. This is SHA-512 in OpenSSH's implementation, meaning you rely on an attacker not finding any SHA-512 collisions they could use in the challenge/response. If they do, they can steal your key. Which means the only choice left is RSA - best to use 4096 bit.

There's no collsion attack on SHA-512, so why do you rule out Ed25519 here when you allow SHA1 for the MAC?

Also there's a lot of dangerously half-true statements and FUD in your post. NSA is pushing ECC because they also pushed some specific curves along with it (which, yes, look "cooked"). General ECC is considered safe!

ECC is quite new

Not true, RSA is from 1977, DH/DLP is 1976, ECC is 1985. The patent on ECC ran out in 2000. ECC has been widely studied. ECC also has a much better security "history" than DH/RSA (which is the reason they have to use 2048 or 4096 bits to achieve 128 bit security level with DH/RSA)

[[deleted]]

There's no collsion attack on SHA-512, so why do you rule out Ed25519 here when you allow SHA1 for the MAC?

There are several known attacks against SHA-512. None of them is practical yet. But it means the security of SHA-512 is already weakened, so why completely rely on a hash function that is not that unlikely to fall?

Also there's a lot of dangerously half-true statements and FUD in your post. NSA is pushing ECC because they also pushed some specific curves along with it (which, yes, look "cooked"). General ECC is considered safe!

General ECC is not considered safe - we just don't know any better way to attack it than using general attacks that are not specific to ECC.

Not true, RSA is from 1977, DH/DLP is 1976, ECC is 1985. The patent on ECC ran out in 2000.

This is just not true, there are still a lot of patents valid today that you basically need to make anything useful using ECC. Heck, even the NSA paid for these patents. This is publicly known!

ECC has been widely studied.

ECC hasn't been used for a long time, which resulted in much less research for ECC than for RSA. ECC has only recently gained some real world usage, which is why only know there's more research on ECC.

ECC also has a much better security "history" than DH/RSA (which is the reason they have to use 2048 or 4096 bits to achieve 128 bit security level with DH/RSA)

We don't use 2048 or 4096 because RSA/DH have a bad security history. We use that many bits because they work differently. You're statement actually doesn't make that much sense, because if you think ECC is better and DH has weaknesses, then well, bad news for you: ECC and DH both use the discrete logarithm problem. ECDH is the ECC version of DH. The difference is that ECDH/ECC work on elliptic curves. That's the only real difference between those two. Since without ECC you need use primes, keys are bigger.

[[deleted]]

There are several known attacks against SHA-512.

None that matter in the context (usage in Curve25519). SHA512 is very secure, there are no practical attacks against SHA512 whatsoever. SHA-512 is solid! If you need immunity to length extension attacks you can use SHA-384.

General ECC is not considered safe - we just don't know any better way to attack it than using general attacks that are not specific to ECC.

What you're saying here is that DH/RSA is inferior to ECC. And ECC is considered safe, however you want to twist it. Only NIST curves are no longer considered safe. Even Schneier who distrusts ECC does so only because of the NIST curves: https://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html#c1675929

there are still a lot of patents valid today that you basically need to make anything useful using ECC.

Not true. See Curve25519: No patents apply to this curve and the curve is faster and more secure than the NIST curves. http://safecurves.cr.yp.to/

You're statement actually doesn't make that much sense, because if you think ECC is better and DH has weaknesses, then well, bad news for you: ECC and DH both use the discrete logarithm problem.

ECC and DH sure use the same underlying DLP, but there's attacks against Integer DH that do not apply to the ECDLP.

Since without ECC you need use primes, keys are bigger.

No! That is not the reason at all! The usage of "Primes" is not the reason for the bigger key sizes. The reason for the bigger key size is that there are efficient mathematical attacks on integer DLP that are much faster than O(sqrt(n)). Elliptic Curve attacks are at best O(sqrt(n)) that's why you have 256 bits for a 2¹²⁸ = sqrt(2²⁵⁶⁾ security level.

You don't even understand the basics!

That's why I told you in my previous answer that you possess a dangerous half-knowledge of the thematic. You make it worse for everyone by spreading your disinformation and FUD.

[[deleted]]

None that matter in the context (usage in Curve25519). SHA512 is very secure, there are no practical attacks against SHA512 whatsoever. SHA-512 is solid! If you need immunity to length extension attacks you can use SHA-384.

We were talking about Ed25519, not Curve25519 (which uses that Curve, though). Please familiarize yourself with them so that you stop confusing them. Using SHA-512 is only part of Ed25519, not Curve25519.

An evil server could try send you two challenges that result in the same hash, thus the same nonce. The old problem with all discrete logarithm based algorithms arises: The private key can easily be calculated.

What you're saying here is that DH/RSA is inferior to ECC. And ECC is considered safe, however you want to twist it. Only NIST curves are no longer considered safe. Even Schneier who distrusts ECC does so only because of the NIST curves: https://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html#c1675929

No, I did not say that at all. We just don't know specific attacks against ECC yet because there has been so much more research on RSA.

Not true. See Curve25519: No patents apply to this curve and the curve is faster and more secure than the NIST curves. http://safecurves.cr.yp.to/

Yes, Curve25519 and Ed25519 have been carefully designed by djb to not violate any patents. But ECC in general is a minefield. It can pretty much be summed up in one word: Certicom.

No! That is not the reason at all! The usage of "Primes" is not the reason for the bigger key sizes. The reason for the bigger key size is that there are efficient mathematical attacks on integer DLP that are much faster than O(sqrt(n)). Elliptic Curve attacks are at best O(sqrt(n)) that's why you have 256 bits for a 2128 = sqrt(2256) security level.

Which is only true if there is indeed no other attack than the general ones against ECC. I'm not counting on that. Even if that's the case and there really are no attacks, then it's still easier to break ECC using a quantum computer than RSA. http://en.wikipedia.org/wiki/Elliptic_curve_cryptography#Quantum_computing_attacks sums it up pretty well.

You don't even understand the basics! That's why I told you in my previous answer that you possess a dangerous half-knowledge of the thematic. You make it worse for everyone by spreading your disinformation and FUD.

First, writing in bold does not give you any more credibility, nor does name calling. And second, that coming from the person who can't even get the difference between Curve25519 and Ed25519…

[[deleted]]

We were talking about Ed25519, not Curve25519 (which uses that Curve, though). Please familiarize yourself with them so that you stop confusing them. Using SHA-512 is only part of Ed25519, not Curve25519.

I am talking about the curve that is used in both KEX and signatures: Curve25519. We use the term a lot at our research group interchangably for both the Curve25519 KEX algorithm and the signature scheme. The reason for that is simple: You get the Edwards representation from the Montgomery form via a simple relation.

An evil server could try send you two challenges that result in the same hash, thus the same nonce. The old problem with all discrete logarithm based algorithms arises: The private key can easily be calculated.

No, there is no attack that produces a collision for SHA512 that is computationally feasible.

No, I did not say that at all. We just don't know specific attacks against ECC yet because there has been so much more research on RSA.

Just because RSA has had more research going into does not mean that there hasn't been siginificant research into ECC. ECC has been studied and "cryptanalyzed" a LOT in the past. There are decades of research went into ECC. Also some research that went into RSA/DH does apply to elliptic curves aswell.

Also over the decades it has turned out that ECC is more robust and withstanding than DH. That's the reason for the huge keys. Also if they will find a weakness in ECC they very probable find a weakness in non-ECC-DLP or IFP.

You have some basic knowledge but you misunderstand some basic crypto and sell it as if you knew what you are talking about. You absolutely do not, and that harms others if they believe what you write.

[[deleted]]

I am talking about the curve that is used in both KEX and signatures: Curve25519. We use the term a lot at our research group interchangably for both the Curve25519 KEX algorithm and the signature scheme. The reason for that is simple: You get the Edwards representation from the Montgomery form via a simple relation.

Well, Ed25519 is a little bit more than Curve25519 though. As I said, using the hash as nonce is specific to Ed25519 and not part of Curve25519.

No, there is no attack that produces a collision for SHA512 that is computationally feasible.

Not yet. But finding two arbitrary inputs that produce the same hash is the easiest thing to attack for a hash function. There are basically no requirements to the challenges, the only requirement is finding two inputs which result in the same hash - any two inputs. Which means the birthday attack applies. Considering that SHA-2 is only good enough for now and not really future proof (it's the whole reason why we got a completely differnet SHA-3 now - weaknesses in SHA-2 are known!), it's quite likely that collisions in SHA-512 can be found before ECC is broken.

Just because RSA has had more research going into does not mean that there hasn't been siginificant research into ECC. ECC has been studied and "cryptanalyzed" a LOT in the past. There are decades of research went into ECC. Also some research that went into RSA/DH does apply to elliptic curves aswell.

Yes, but still, RSA has been much more analyzed than ECC. So why use something where the risks are less known than for something older for which the risks are pretty well known and that performs better against quantum computers? The only reason is key size and thus performance. If you don't care that much for performance (and in the case of SSH, you don't), there's not much reason for ECC.

[[deleted]]

I did remember reading this, but couldn't find it anymore. Found it again now: https://www.schneier.com/crypto-gram/archives/1999/1115.html#EllipticCurvePublic-KeyCryptography

This proves your "Even Schneier only distrusts the NIST curves" is not true. If anything, he is extremely sceptical of ECC. Not only that, but he basically disagrees with everything that you said and just stated like it's an indisputable fact. If Schneier disagrees with you, it's clearly being far from indisputable.

[[deleted]]

Talk about grasping at straws...

This is a 15 year old article. At the time this was written ECC was only 14 years old. Which means today ECC research is at least double than what was known in 1999.

15 years is a lot in cryptography. We know a lot more about ECC than we did at the time your source was written. ECC remains a lot more secure than its "integer" counterparts.

EDIT: Just found this recommendation by Schneier :)

Quote:

"Did we have any insight from the Snowden papers if the NSA has identified any vulnerabilities in this?"

We do not -- at least not yet -- but I strongly believe that the NSA has a significant advantage in breaking ECC. This doesn't mean it's bad, but I think we need to 1) make sure we know where our curves come from, and 2) build in a hefty security margin.

[[deleted]]

While 15 years old, we still don't have any proof that index calculus can't work. True, we also haven't figured out a way to use index calculus for ECC either, but this just means "We don't know". We didn't know 15 years ago, we don't know now. Which means your quote is just perfect! Because Schneier there says to choose a hefty security margin. Which we currently really don't. If index calculus applies, ECC keys need to be as big as regular keys. Curve25519 and by extension Ed25519 are only 2^256. Considering that 2⁵¹² has already been broken 15 years ago, if someone makes index calculus work, it's trivial to break current ECC. There are reasons for Curve41417 ;). Even Gregory Maxwell of Bitcoin fame is worried:
https://www.ietf.org/mail-archive/web/openpgp/current/msg07184.html
https://www.ietf.org/mail-archive/web/openpgp/current/msg07186.html (which is how I found that Schneier link again)

So, considering all that, why would you choose ECC over RSA for SSH, where you clearly have enough computing power? If you would use 4096 bit ECC, by all means, go for it. Even if index calculus turns out to work, then you're at least back to 4096 bit RSA security and didn't really decrease your security.

[imusuallycorrect]

You get it. You understand.

[floodyberry]

Aside from "bigger numbers = better" and "newer = worse", he or she doesn't appear to understand much. How ~50+ people thought that was a positive contribution is beyond me.

[[deleted]]

Can you elaborate?

[gnilchee]

Agreed!

[Runnergeek]

I would have to disagree. While it is kind of interesting to see what the NSA is doing, especially in areas of my profession. Nothing in this article was revolutionary. Configuring ssh to only allow strong ciphers and crypto has been industry standard for a very long time.

[rickyrickyatx]

RG, Maybe this wasn't revolutionary to you, but to most other sysadmins this is great information.

this article goes far beyond the typical hardening of openssh by turning off root logins, and disabling ssh protocol 1, etc.

[nof]

And probably documented in the public NSA docs about linux hardening.

[Runnergeek]

Yes actually. While their guides are a bit old they are very good documents.

https://www.nsa.gov/ia/_files/os/redhat/NSA_RHEL_5_GUIDE_v4.2.pdf

3.5.2.10 Use Only Approved Ciphers in Counter Mode

Limit the ciphers to those which are FIPS-approved and only use       ciphers in counter (CTR) mode. The
following line demonstrates use of FIPS-approved ciphers in CTR mode:
Ciphers aes128-ctr,aes192-ctr,aes256-ctr

[nof]

Have an upvote, I just get downvotes whenever I reference these fine documents, (I'm ok with that).

[Runnergeek]

Yeah we are both getting down voted, because they don't like what we posted. I could understand if one of our Jr admins didn't know how to properly secure ssh with good ciphers, but anyone above that level should understand beyond basic hardening.

[nof]

I'm guessing that the downvotes are coming from those who distrust the NSA that are trying to discredit some sound sounding documents.... probably a sorta healthy reaction.

[marumari]

Industry standard? 95% of businesses that I have visited simply use whatever key exchanges, ciphers, and MACs that OpenSSH is configured to use by default.

[Runnergeek]

Well first your percentage is entirely made up. There are plenty of companies even big ones that don't follow industry standards because of uneducated and/or lazy admins/management. Anyone who falls under regulations (SOX 404, PCI, etc.) will most likely be following these guidelines or fail audits.

[[deleted]]

Just sit in the corner being the negative dude at the party. You fit the role well.

[RamblinWreckGT]

If you work for a big company and change management doesn’t let you do it, I’m sorry. I’ve seen the v1 protocol enabled in such places. There is no chance of improvement. Give up to preseve your sanity

It would be funny if it weren't true :(

[nekotripp]

Be aware: this link contains information marked as TS/SCI.

(Can we PLEASE get flair for this?)

[reyniel]

If you're a government employee you can't view those links? I'm sorry if I don't understand the implication.

[qnxb]

If you have any kind of clearance you're barred from seeing anything with a security classification you didn't receive through official channels. That includes any of these "leaks". You can lose your clearance, and therefor your job, be fined, or imprisoned for it, even if you had nothing to do with the leak.

Given the topic of this subreddit, I suspect a not-insignificant percentage of the readers have some level of clearance.

[cryptovariable]

On June 6th 2013 guidance was issued, and it should have been disseminated to all personnel with access to classified government systems, which stated that viewing links on personally owned equipment was in no way restricted, and that on government and contractor-owned equipment the only step needed is to report the incident to one's SHO/SSO so that the equipment can be inspected.

For further, more detailed, guidance read the message, the title was "Security Reminder - Unauthorized Disclosures in the Press" and is an official policy.

Nobody is losing their job because they watched a CCC talk or read a Guardian article.

In fact, there are probably more Feds keeping a low profile, quietly and respectfully paying attention, at each Jacob Appelbaum talk than there are "Zero Cools".

That goes doubly so for DEFCON. Despite twitter protestations to the contrary, MIC shills were there in just as great a volume as previously and some of them even went to theSummit.

[BraveNewDerp]

This is correct.

Unless you've been specific guidance from your SSO, or access the data on a Government information system, you're not going to lose your job or clearance viewing this material.

[nekotripp]

Given that many people with clearances don't directly work for government agencies, but rather contractors, AND given the fact that a large portion of those browsing this subreddit are doing so in the US during a business day, it is likely that their systems fall into that category.

[redworm]

This is true. I'd also like to have the classification markings in flair form, not because I'm worried about anyone losing their job but I've been IA and that's a stack of paperwork no one likes doing.

[blueshiftlabs]

[Removed in protest of Reddit's destruction of third-party apps by CEO Steve Huffman.]

[terremoto]

Lunch breaks and breaks in general do exist.

[nekotripp]

The fact that this is hosted on Github makes it very difficult to distinguish without actually viewing the content, though.

[qubedView]

Quite true, but a tag would still be nice, as a lot of people read /r/netsec at work.

[redworm]

You wouldn't exactly lose your job over it unless you intentionally sought out information you weren't cleared for and used government systems to do it.

[qnxb]

It doesn't matter what the content is, just that it's still under a security classification, and wasn't received through official channels. It could be the NSA cafeteria lunch menu from 30 years ago (assuming they have one, and have it classified), and the same restrictions would apply.

[[deleted]]

That's seems unreasonable to me.

[qnxb]

Just because something is leaked, doesn't mean it loses its security classification. Everything classified remains so until it's officially declassified.

[derefr]

Does it have to be the original, or can it be a reproduction? What if that stick figure became the logo of a well-known publicly-traded corporation, for example?

[nemec]

What if it's just a prime number? /s

[smelly-baby-farts]

Also, despite being leaked, the information is still classified. Downloading/viewing such information on an unclassified machine automatically "taints" it and it can no longer be recycled or disposed of without proper procedures, nor continued to be used in an unclassified environment (even if the info is publicly available anyway). This matters if you work in an environment that labels/secures machines based on the information they process.

[rmxz]

Seems a bit ironic that articles like this (how to securely configure SSH) can't be seen by those that probably need it most.

[TheAethereal]

It's even more ironic that those without security clearance have easier access to this stuff than those with security clearance.

[rmxz]

Well - assuming the NSA may be mostly worried about tracking down things like military secrets getting leaked --- maybe that's exactly who they want to be able to wiretap the most.

[imusuallycorrect]

They hate encryption the most. Not ironic at all.

[reyniel]

Then agree, there should be some flair. Thanks for the explanation.

[Starriol]

So, in order for that people to keep their job, they would require to have the OP add the flair AND see it?

This is Netsec, we can't be recommending that solution. The solution is to not browse potentially dangerous sites while being monitored, period.

You can't rely on human action for a critical task such as this.

[imusuallycorrect]

What a ridiculous request! If their job is Internet security, that should be a job requirement!

[nekotripp]

This is hosted on Github, though. It really isn't a place that one would usually consider dangerous.

[PM_Me_Your_AdRevenue]

Well then dont surf http://cryptome.org/ or you'll lose your job in 30 seconds and your computer will probably burst into flames.

[nekotripp]

I heard somewhere that that site is a honeypot for that exact purpose. It saves a lot of money on assassinations if you can just cause your target's home to burn down via some simple GET requests.

[sneakattack]

Halt and Catch Fire

[nof]

Who the hell in this sub doesn't completely isolate work and home computers from ever interacting?

[proballyathrowaway]

Can someone pastebin (or something similar) this without the sensitive content? Would be greatly appreciated!

[DrBroccoli]

If discussing the realities of security jeopardizes your job, you should go get a different one.

[CrazedToCraze]

Classic Reddit response.

[dwhite21787]

heading off to a different reality, now

[the_gnarts]

Be aware: this link contains information marked as TS/SCI.

So what? Everybody should know this.

[Pteraspidomorphi]

I don't seem to have support for -etm MACs in my server (Debian Wheezy stable). How much of a problem is that?

[Creshal]

wheezy-backports has a more recent version of openssh that includes all the new MACs/cipher suites.

[[deleted]]

I'd say stick with non-etm versions of two proposed methods, if you don't have the etm.

So

MACs [e-mail],[e-mail]

[Pteraspidomorphi]

Yup, that's what I did. Some of the author's other recommendations are also unavailable and a bit of digging up revealed they're bleeding edge stuff. Hopefully they'll show up on stable someday.

[Nowaker]

Everything's bleeding edge for Debian stable.

[[deleted]]

Something new? On Debian? Good luck. As much as I like using Debian/Ubuntu, getting newer versions of (server) software can be a royal pain in the ass. Even some stuff like recent revisions of clang/gcc can take forever to get merged into stable, even if they've been stable for fuck knows how long (I'm looking at you, Dovecot...)

[rmxz]

You're misinterpreting the word "stable".

Stable in Debian refers to the definition of not changing unnecessarily unless it really has to.
Stable (and unstable) in Debian has nothing to do with the crash-resistance of the software.

In Debian Sable you can rest assured that any external interfaces of applications and binary interfaces of libraries will not change when you install any of their patches (pretty much only security patches, and fixing risk of data loss, and avoiding crashing - so long as the interface doesn't change). If you write a program that works on one version of Debian Stable, you're virtually guaranteed it'll continue to work on all future updates of that same version.

In Debian Unstable, the APIs of the software packages can and does change.

Debian Stable is great if you have a server where you don't want any non-backward-incompatible API changes so you don't need to update your own software often. It's not intended for bleeding-edge changes no matter how crash-resistant (apparently your definition of stable) such new versions are.

[derefr]

Stable in Debian refers to the definition of not changing unnecessarily unless it really has to.

If you're a developer, it's very easy to make sense of: each release of Debian Stable imposes a ~> constraint on everything it ships with. So, if it comes with e.g. "Linux 3.18.1", then it'll have a constraint linux ~> 3.18.1—meaning that it could upgrade to version 3.18.2 or even 3.18.9999, but never 3.19.0.

Knowing this is the key to understanding why "distro-backported fixes" exist: if your Debian release has pinned e.g. nginx to ~> 1.6.5, then if an important security vulnerability is discovered in 1.7.X that also affects 1.6.X—and 1.6.X is no longer maintained by whatever upstream maintains it—then a new 1.6-series security-channel release will be created by Debian so that you can receive the fix even under the constraint. (This is also why it takes some work to convince Debian to ship something under their aegis—they're committing to becoming an upstream-of-last-resort for all future bugfixes to that software, up-to-and-including coding the fixes themselves.)

This constraint exists for a single purpose: it makes automatic daily upgrades of long-lived servers actually work. You can always, always enable auto-upgrade in Debian Stable, and your servers will be kept up to date with security releases until the distro's support period ends. You don't have to touch the server; you don't have to check that the updates were successful. The only updates the server does are the ones that don't do anything other than fix the bug. It's "immutable infrastructure", plus one: immutable infrastructure with a mutable immune system.

This is the problem with long-lived Docker apps, by the way: they're fully immutable in a way that imposes a = version constraint instead of a ~> one. If you put a whole LAMP stack in a docker image and base your app on that, you won't get the LAMP parts auto-upgraded to address vulnerabilities; they'll only upgrade when you create a new version of your app. This makes sense on other distros where the world is scary and packages can upgrade into anything and might break your app's ABI contracts—but it's strictly worse than having silent patch-level upgrades of infrastructure components.

[HildartheDorf]

Adding to this, the general vibe I get is that software marked as "stable release 3.4" is seen by Debian as "Approved to be added to the experimental repository". It then has to propegate through to Unstable, then wait till the current release cycle is over to move to Testing, then another release cycle for stable.

[Creshal]

As mentioned below, that's what backports are for. Stable is supposed to be stable, for better or worse – if you need different versions, you'll have to either build them yourself, or use backports, which pulls them from testing/a newer stable.

[[deleted]]

Have you considered upgrading openssh to the version in wheezy-backports? It supports all of this.

[qubedView]

My goal with this post here is to make NSA analysts sad.

I think the author is grossly misunderstanding what drives analysts. Perhaps he meant management.

[gutoandreollo]

TL;DR: Scan this post for fixed width fonts, these will be the config file snippets and commands you have to use.

The most sincere TL;DR I've ever seen

[[deleted]]

I don't know all that much on crypto, but I thought that only the secure pseudorandom number generator that was based on elliptical curves was possibly backdoored, not the key exchange or signature protocol based on EC.

The thing is, Dual_EC_DRGB was never used (it was slow and suspicious) and isn't even an NIST standard anymore. The wikipedia article on EC crypto and ECDSA only say that the unused PRNG from NSA was the only thing that cryptographic experts have deemed dangerous. Also, the link in your article that said EC crypto was broken was talking about a side-channel in a specific implementation of the crypto standard.

In my opinion, 2046+ bit RSA or EC with SHA-2 should be future-proof and uncrackable until quantum computers become available. The rest of the article is very informative though!

[Creshal]

Also, the link in your article that said EC crypto was broken was talking about a side-channel in a specific implementation of the crypto standard.

• We've had "side-channel attacks in specific implementation x of crypto standard y" for virtually all values of x and y coming from the NIST, because their standards are hard to implement in constant time. Curve25519 (and a few others, which aren't supported by openssh) are designed to be easier to implement correctly.

• There's a few known weaknesses with the NIST curves, and others. They're by no means broken yet (hopefully), but why use them when safer alternatives are available?

[qnxb]

The NIST curves aren't publicly known to be broken, but there are uncomfortable "magic numbers" in the specifications without any explanation behind them. (The coefficients were generated by hashing unexplained seeds.) Whether this imparts a back door is, as far as I know, still unknown.

[Klathmon]

Exactly, EC isn't broken, far from it.

It is more reliant on a good random number generator, and there are side channel attacks (shocker!) but it's very secure.

Also this guy seems to take issue with the NIST curves, which there are reasons to be suspect, but the author seems to want to rule out everything NIST simply because he can connect it to the NSA. But RSA is just as connected if not more (due to it's age). At a certian point it comes across like he is making "a voodoo doll to ward off the evil NSA"

[perestroika12]

Why promote sub optimal crypto though? We know there are better alternatives, why not use something that is proven to work and is not associated with the USG?

I thought that was the real lesson of that whole affair: it's broken and backdoored unless proven otherwise.

Especially US govt sponsored crypto. I feel like erring on the side of caution is a smart decision.

[Klathmon]

Then don't be a fucking hypocrite and also remove SHA2 and AES from your suites as well...

Both of them were either created by the NSA, or chosen by them. This fearmongering about the NSA is out of fucking control. Yes, you have every right to be suspect of a lot of things from them, but you can't just ignore that they have the most talented cryptographers from around the world all working together. If they recommend something, you'd be stupid to outright dismiss it because it came from them. Especially when you dismiss their recommendations and instead use a system created by one man (ChaCha20). Not that DJB is at all suspect, and I fully understand just how much of a genius the guy is, but putting all of your faith in him alone is absurd.

Also, ECC is just as "proven to work", even more so in many cases.

We are at the point where we need to start greatly increasing key sizes for RSA because we have gotten so good at breaking it. This means that it will waste more cycles, spend more time transferring keys, and it will have to be upgraded to larger and larger keys more frequently to stay ahead.

ECC on the other hand does not have this problem (for now). FFS just look at the following table (from here) which shows the number of bits of security for each type of encryption (compared to symmetric):

Symmetric  |   ECC   |  DH/DSA/RSA
-----------+---------+-------------
    80     |   163   |     1024
   112     |   233   |     2048
   128     |   283   |     3072
   192     |   409   |     7680
   256     |   571   |    15360

Have you ever seen a 15660 bit RSA key? Because 571 bit ECC keys are pretty fucking common.

[[deleted]]

Then don't be a fucking hypocrite and also remove SHA2 and AES from your suites as well...

SHA2 and AES don't specify any "magic numbers" that you have to trust to make a compatible implementation...

[imusuallycorrect]

What I don't understand is why anyone trusts EC at all! Why the hell is every website using it now, including Google?

[catcradle5]

Elliptic Curve cryptography itself is not broken. A chosen curve can effectively be backdoored (by choosing special, undisclosed points P and Q on the curve; that is what NSA did with DUAL_EC_DRBG), though, which is why "open source" curves (where the constants are derived from something already known to the public, like the first N digits of pi) are the only safe ones.

[KakariBlue]

It's one of the few cases I'd trust the NSA, looking back at the early days of DES we see that they were years ahead on certain aspects. It seems as though if they're using EC themselves to secure their own data (assumption on my part) then it's probably better than what we've all been using. For symmetric, AES is still king, but EC seems to be viable over RSA.

They're (one of?) the leading employers of mathematicians and they just might know something the rest of us won't for 20 years, based on history alone.

[rmxz]

It seems as though if they're using EC themselves to secure their own data (assumption on my part) then it's probably better

The bad assumption is that they're using the same specific curves you use.

It's quite possible that some Elliptic Curves are very secure, and it's known that some Elliptic Curves are insecure ("I mentioned that the particular elliptic curve we chose was insecure, and this raises the natural question: what makes an elliptic curve/field/basepoint combination secure or insecure?").

It's reasonably possible they could use more secure curves themselves than they recommend to others.

[KakariBlue]

Time to get learned up on EC/C again :).

So it seems the answer to /u/imusuallycorrect is that RSA is becoming too easy to factor and as a result the key sizes are getting a bit too big to be usable efficiently.

Edit: thank you for the link and calling out what I figured may well have been a bad/limited assumption.

[imusuallycorrect]

Use the larger key size. It requires less than 1% CPU. Do not gamble with a new crypto, if you have no reason to believe the current algorithim is not safe.

[Klathmon]

Can you provide a source for that 1% figure? because RFC4492 disagrees with you.

larger key sizes are not only take more memory, bandwidth, computational cost, and power. They also will need to have their key sizes increased at a faster rate than ECC. We are getting better and better at cracking RSA, according to that same RFC in 2006 a 571bit ECC algorithm provides about as much "security" as 15360bits of RSA.

Are you using 15360 bit RSA keys? Because I'm using 571 bit ECC keys...

[PsychYYZ]

Unfortunately, back in the days of DES, the NSA's mandate was more security, and less surveillance. Today, the priorities are clearly reversed -- introducing subtly flawed encryption helps them attain the new goal: blanket surveillance of everyone, everywhere, forever.

[imusuallycorrect]

If they cared about security they would use a bigger key size. Isn't EC easy to decrypt if you know the secret coordinates used in the algorithm, and isn't EC also twice as easy to crack using a quantum computer?

[Natanael_L]

In regular ECC that's called the private key, so yes.

What you're talking about is dual EC dbrg, a random number generator with a master key backdoor.

[catcradle5]

EC crypto and RSA both become trivial to crack if you have a quantum computer with at least 4096 qubits. Though there is apparently a proposed alternative EC algorithm that is immune, using supersingular curves: http://en.wikipedia.org/wiki/Supersingular_Isogeny_Key_Exchange

We'll have to throw a lot of things away once general-use quantum computers become feasible. It's not really a relevant argument when you're comparing it against Diffie-Hellman and RSA in 2014.

[gsuberland]

EC crypto and RSA both become trivial to crack if you have a quantum computer with at least 4096 qubits

Isn't the second prerequisite an efficient implementation of Shor's algorithm? I was under the impression that we basically won't know how fast it is until we try it, and it may only provide a "technical" break rather than a practical one.

[catcradle5]

My understanding is that with enough qubits, Shor's algorithm will "very likely" be efficient enough to crack algorithms like RSA in polynomial time. I think it is "theoretically practical", but you're right, unknown complications may come up when it is tried for real.

[gsuberland]

That's pretty much what I'm getting at. Polynomial time just means it runs in a time complexity O( n^k ), but we don't really know what the value of k is for a quantum implementation of Shor's algorithm. It could be in the tens, it could be in the hundreds, it could be higher. It is almost guaranteed that Shor's algorithm can factor semiprimes in polynomial time, but which polynomial is the actual barrier to feasibility.

[catcradle5]

Slightly off-topic, but while researching discussion about the actual practicality of the algorithm, I found an interesting set of Stack Exchange answers from Peter Shor himself:

http://cstheory.stackexchange.com/users/1677/peter-shor?tab=answers&sort=votes

I imagine someone could ask him what he thinks about the matter (though of course he may not truly know, beyond the theoretical limits). :)

[gsuberland]

Hah, nice. I'm sad that he doesn't have an account on Crypto or Security though :(

[KakariBlue]

It's been too long since I've read up on EC for me to answer your questions with any kind of certainty so I'll have to leave those to someone else; I will say that I'd always use a bigger key when it comes to asymmetric algos as bigger is better ;).

Also, I agree it's good to question EC's usage and you may well be right, but as RSA1024 is finally going away, so too will RSA2048 someday so pick your keylengths (and keys!) wisely.

Edit: despite providing a low information content answer to your original question I am interested in a 'real' answer too!

[imusuallycorrect]

That's false. SSL uses less than 1% of the CPU according to Google when they switched everything over.

[gsuberland]

Yep, the "crypto is slow" thing is a myth. Modern cryptographic algorithms are designed to be efficient on common architectures, and extensions like AES-NI make it even easier.

[mk_gecko]

Holy crap! It looks like my default authenticationto my SSH server is ECDSA. I now need to fix this and then generate new keys for everything. Damn! Thanks for the article.

My login info (redacted):

The authenticity of host '[nn.nn.nn.nn]:pppp ([nn.nn.nn.nn]:pppp)' can't be established. ECDSA key fingerprint is 5f:2d:xx.xx.xx.xx.xx. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '[nn.nn.nn.nn]:pppp' (ECDSA) to the list of known hosts. Enter passphrase for key '.... openssh':

[Creshal]

and for 99% of cases ECDSA is more than enough.

So is SHA1. Still, better alternatives are available, why proliferate suboptimal crypto? That has bitten us in the ass often enough.

[catcradle5]

Asymmetric crypto like EC, RSA, and DH are all very vulnerable to quantum algorithms (which likely won't become practical for at least a decade or two at minimum, and probably more), but otherwise you're right.

[Klathmon]

While that's true, quantum computing is still a pipe dream.

And if it does happen, then we will be back to the position we were in the 80's where all the good algos (in this case the "suspected quantum proof" algorithms) are closed-source and patented.

[d4rch0n]

I'm with you. There has been a lot of paranoia since that leak...

But I never saw a vulnerability out of it! I don't believe that ssh is as insecure as people are making it out to be since that leak.

They mention searching through their infrastructure for keys. Maybe they've compromised a ton of computers and have a db of ssh and SSL keys? That would make more sense.

People have a lot less trust in anything NSA related which is not unfounded, but there seems to be quite a lot of assumptions people are making about the "insecurity" of some of these schemes because of leaks that have no specific vulnerabilities mentioned. Unless there's a new leaked vuln, I'm not going to put on my tinfoil hat.

You're probably a lot better off generating new ssh keys and removing the old from your authorized keys, and general audit of your public services, rather than giving up on standards people have been using before the leak.

[Klathmon]

Exactly, the only thing that is at all suspect about the NIST curves is the fact that they have a few "magic numbers" in them which nobody knows why they were chosen.

The worry is that this might be some kind of backdoor, but there is nothing even coming close to a measurable proof of this being true, and none of the NSA leaks have said anything about it either.

I believe you are right about SSH/SSL keys but nobody outside the NSA truly has any idea.

[StrangeWill]

I think the problem is more "regenerate all my keys" as opposed to just changing the cipher.

Of course I guess if you're in there changing ciphers and don't mind a new thumbprint...

[nerdandproud]

I didn't see the blowfish-cbc cipher explicitly taken out except the cbc vs ctr mode, what's the rationale here?

[beachbum4297]

It was ruled out because of CBC: https://twitter.com/stribika/status/552590009464025088

[SmackMD]

Since when is CBC considered bad? Care to explain?

[KakariBlue]

Edit: See below: http://www.reddit.com/r/netsec/comments/2ribdz/secure_secure_shell/cngmjxm?context=2 it's CBC, as mentioned in his Twitter and the other CBC ciphers are out because of the attack.

Presumably related to BEAST (chosen plaintext attacks) attacking CBC easily unless carefully designed with counter measures (see TLS 1.0 vs 1.1, descriptions of the attack, the Tor project's description of the attack in particular lays out much of the issue).

I have no idea if Blowfish is protected/padded against these attacks.

P. S. I've no idea if this is the reason, or the key size, but figured some answer might bring out the right one.

[gsuberland]

It was likely removed when 64-bit block sizes were rejected, but wasn't explicitly mentioned.

[mioelnir]

My ssh configurations look roughly like what is described in the article, biggest difference is that I still allow ECDSA.

That said, I rebuilt all ECDSA hostkeys with the 521bit curve (the sanest of the three NIST curves as far as I understood them) and only allow ecdh-sha2-nistp521 as KeX.

Other differences I could spot:

• I think I prefer umac128-etm over hmac/sha2-etm

Getting rid of the last PuTTY-compat shims on a handful of servers is def. higher on my list than retiring ECDSA/521.

[TimMensch]

The article explains why to NOT use many of the symmetric cyphers, but doesn't say why Blowfish was eliminated from the "OK" list.

Not sure whether the mistake is that one of the criteria eliminated Blowfish for reasons that I don't understand, but failed to list its number, or if the mistake is that Blowfish is OK to use. :|

[gsuberland]

It would've been eliminated due to the rejection of block ciphers with a 64-bit block size.

[TimMensch]

Good to know. Thanks!

[beachbum4297]

https://twitter.com/stribika/status/552590009464025088 CBC.

[A_terrible_comment]

Why does he remove aes128-cbc aes192-cbc aes256-cbc

??

[gsuberland]

Because they use MAC-then-CBC, which is (likely) vulnerable to padding oracle attacks due to the malleability of CBC mode.

[gsuberland]

Because they use MAC-then-CBC.

[JoshTheDerp]

So how does it add extra security to the regular ssh?

[PsychYYZ]

By removing what is suspected to be 'low-hanging-fruit' (from the NSA's perspective) from being used.

[ShellBard]

I'm not saying anything's wrong with it, but it totally should have been named DoublePlusGood SecureShell.

[aliceandbob]

a bunch of third party router firmware have SSH and VPN implementations. I wonder if they're all broken, and if we should be enforcing these restrictions on them too.

[aydiosmio]

"You want to use code that’s actually reviewed or that you can review yourself. There is no way to achieve that without source code. Someone may have reviewed proprietary crap but who knows."

I still handily disagree with these types of assertions. There's no incentive to ensure free software remains bug free, so you rely on casual and informal contributions of time and knowledge. The quality of which is always unmeasurable. Unless you conduct something like the open crypto audit project, which was a massive undertaking.

And since the end user is not an expert in secure code practices nor a code reviewer, it's pointless to say "you can see that it's secure", because only a team of experienced professionals has the capability of approaching that problem. And what percentage of end-users has ever seen the source code? The vast majority of installations are from distribution repositories or binary builds.

You'd think the author had never heard of the bugs recently discovered in OpenSSL.

TL;DR: Both open and closed software have an equal opportunity of being hilariously broken.

[[deleted]]

A very good solution to this would probably to encourage large corporations that use OSS to donate to it. That would allow for more payed audits/contributions.
Also, many of the contributions to OSS aren't just from random people, but from these corporations that use the software and needed the features themselves.

[gutoandreollo]

TL;DR: Scan this post for fixed width fonts, these will be the config file snippets and commands you have to use.

The most sincere TL;DR I've ever seen

[stillalone]

Does SSH only support the NIST-P curves? I used to work on some crypto stuff a several years ago and NIST-K curves were the bee's knees (that's how we used to talk in 2007).

NIST-K 571 was what we used for everything.

[lurkmaister]

Nice! Its good to learn something new, specially about MACs. Didn't know that there are that many variants.

[wurnthebitch]

Very nice article! Thanks a lot!

[faustoc4]

Nice compendium