This impacts EdDSA as well, the Edwards-curve Schnorr-based system that is a gold standard for signing crypto. While I agree that you should avoid ECDSA, implementation errors can happen to anything.
But, if you fear and loathe ECDSA (and I do as well), it's probably a good idea to get in early against protocols that seek to deploy more of it. For instance, DNSSEC, which is barely deployed anywhere on the Internet, is just now (as in, resolvers couldn't reliably verify ECC records until recently) introducing ECC support --- with ECDSA.
I think EdDSA desperately needs to be allowed in FIPS certified hardware, so that secure hardware will have support for EdDSA so that people who have to store keys in secure hardware will be able to use it. I mean HSMs, smart cards, secure enclaves, TPMs, things with a ATECC508A, etc.
This looks like a really phenomenal writeup, with worked examples. The underlying math and algorithm stuff here is applicable to other attacks; it looks like this is worth a close read.
Can you say whether libgcrypt did something especially stupid? [1]
I understand that most people just take the ref10 code from supercop, but if I were to try to implement ed25519 from the paper (https://ed25519.cr.yp.to/papers.html), what is the chance I would do something like what libgcrypt did, or equally bad?
Basically, is ed25519 secure because everyone uses a known secure implementation or because it is engineered to be genuinely hard to implement incorrectly from the paper? (I know it's both, but is it mostly one or the other?)
1 - They special cased the point at infinity and this short-circuit allowed to count leading zeros.
If my two cents count, I would say that if you were to implement EdDSA from the paper, you would have a good chance of creating a secure implementation w.r.t. to this kind of leakage.
However, if you were starting with some Short-Weierstrass EC code in your library, then you might be inclined to skip all the scalar multiplication specific stuff in the Ed25519 paper, just take some (incomplete) Edwards formulas, take some general scalar multiplication algo (or even reuse the one you have for Short-Weierstrass, like libgcrypt) and end up with a vulnerable EdDSA (if your ECDSA was).
The short-circuiting in the addition formulas is necessary if incomplete formulas are used. Either that is done, or the scalar multiplication algorithm has to explicitly find out the bit-length and start so that the point at infinity is not input into them ever.
In https://minerva.crocs.fi.muni.cz/#details-reasons and in your comment you're describing two bad ways to do scalarmult, but you do not show side-by-side the correct way (e.g. what ref10 does). Can you describe it in a sentence or two?
Right, there are many ways to do it correctly. In general, you need complete addition formulas (those that can take the point at infinity and produce a correct result in a side-channel indistinguishable way), if you have those, almost any scalar multiplication algo can be made constant time with regards to the scalar bit-length (you would just start at some fixed point past the end of the scalar in case of a left-to-right algo, with the point at infinity intialized).
One of the main points in the root causes discussion is that without complete formulas you are almost always going to leak the bit-length, so the only way to not be vulnerable in that case is to fix the bit-length to a constant value. This cannot be done naively by simply setting the high bit, because this would introduce bias in the nonces which would be exploitable even without measuring the duration, a much worse attack! However it can be done via the method suggested by Brumley & Tuveri in https://eprint.iacr.org/2011/232 where you add a multiple of the curve order to the scalar to fix its bit-length. This means the distribution of the nonce modulo the order remains the same (uniform, no bias) yet the bit-length used in scalarmult as a loop bound is constant.
Thanks, a paper is being prepared with the full details and an improved method. The sensitivity of the method to noise (one bad inequality in the lattice can make it not find the key) is really worth looking at, as that would improve the number of signatures necessary for the attack severely.
> the trustworthiness of NIST-produced curves being questioned after revelations that the NSA willingly inserts backdoors into software, hardware components and published standards were made; well-known cryptographers have expressed doubts about how the NIST curves were designed, and voluntary tainting has already been proved in the past.
There's two stories that often get mixed together. One is an elliptic curve based random number generator (Dual EC DRBG), and yes, everyone who knows the facts believes it's backdoored.
Then there's some much more general concerns about the NIST curves themselve. These concerns come down to that a) we don't really know how they were generated (there are some numbers in the paper that just "appear out of nowhere") and b) that they've been created by the NSA. But there's no concrete proof of any backdooring and it seems relatively implausible, as no method is known that would explain how that backdooring would work. I guess most people familiar with the facts don't believe they are backdoored.
We don't actually know for sure that Dual EC is backdoored, we have unexplained constants plus subsequently a way to pick constants that backdoor the algorithm have been discovered. The constants could have been chosen randomly or based on something that would be embarrassing to reveal, e.g. the project leader picked their children's birthdays. Since this algorithm is worse in other ways there is no reason to use it and it's reasonable to treat things that pick Dual EC as problematic because they had no good reason to do that once it became controversial. But we shouldn't forget that it's not actually proven to be backdoored, we have only reasonable suspicions.
We also know that Juniper not only used Dual-EC for their VPNs, but that someone at some point got access to their source tree and rekeyed the backdoor to a new secret. It's obviously a backdoor.
Based on his comments on all matters related to state surveillance and, in particular, on dualec drbg I would take a comment like that from him to be weak evidence that they were backdoored. :)
He's spent countless hours tirelessly denying the existence of programs that have subsequently been proven to exist. He clearly has a huge blindspot related to the potential for unlawful and unethical conduct by the US government.
What is clear enough about the NIST curves is that they used a high entropy process that would have easily allowed them to grind to select for undisclosed criteria, somewhat inexplicably. Maybe they used this fact to add security against currently non-public attacks? Maybe they used this fact to weaken them against an attack the public doesn't know about. Maybe, like tptacek, they were largely blind to the concern of government backdoors and just didn't care if the process looked somewhat janky. Regardless of the reason no clarification seems likely to every be made.
The more frustrating point is that the alternative of choice (curve25519/ed25519) is only available at the 252-bit security level, and current goverment guidance discourages ECC below 384 bits. Higher bit ed25519-alikes are no where near as mature or deployed. If your strategy is try to make choices where in the future you'll never have reason to feel stupid about the choices you made the options aren't really that great right now. You either use 384bit+ NIST and are exposed to the suspicious generation mechanism, use ed448 which is some weirdo cryptosystem few other things use, or use ed25519 and violate NSA's recommendation to use >=384 bits. With each of those options if it later turns out to be a bad choice you'll have plenty of reason to feel stupid.
I'll also add that BULLRUN clearly stated they were backdooring cryptographic standards. At that point, any NSA connection is suspect. Personally, I thought it was brilliant attempt at a NOBUS attack. NOBUS is rarely achievable in practice while simultaneously being deniable.
I'll note as well that you've been on plenty of threads that contradict the account 'nullc provided here, but appear happy to let it go in the service of whatever weird point you're trying to make here. Gross.
I was corroborating the backdoor point. I didn't read the rest of the comment cuz I was too busy going through a ton of threads in prolly 15 minutes. Also, I stayed rate limited voluntarely from way back to deal with being on social media too much. By default, I don't comment or elaborate most of the time in case more important stuff comes up needing my commemts.
It did. There were two chances in that timeframe to do some good. One was a set of comments on robust software at 4-5pts with a two follow-ups in comments who plan to learn more. Another was necessary reminder banks can themselves cut funding off opponents like they did Wikileaks. That was 5pts with 2 supporting comments. Whatever you expected me to reply to was presumably going to use up my few comments to do less social good.
I figured I'd throw one your way since you or anyone following this may not know why I don't comment as much in situations with lots of back and forth style discussion. It use up all my comments for probably nothing. Now you know why I didn't reply to several of yours done in that way. Just the rate limit doing its job, Sir. ;)
Edit: I'm keeping everything but "sophistry" I edited out. Although sleepy as hell from 13hr days, I checked out your other comments in that thread. My memory is too bad to know what NSA programs you were calling or not calling in the past. That commenter might be full of shit about that. Original comment stands since it was just as a corroboration they were doing it regardless of what you said.
I've repeatedly acknowledged the existence of USG surveillance programs, including Dual-EC. I believe the "hours" I've spent discussing Dual-EC and PKRNGs in general are also straightforwardly countable; just use the search box:
What you're doing here is deceptively reframing a subtle nerd technical argument as a normative argument about USG surveillance. In particular: at no point have you or anyone else ever witnessed me arguing that Dual-EC was okay; rather, my argument was that Dual-EC was so batshit, and such poor tradecraft, that it was unlikely to be a serious NSA program. My argument at the time mirrored that of Bruce Schneier: "never use this, no competent engineer would". My twin mistakes: I overestimated both NSA and the industry, in particular vendors like Juniper, which did in fact implement this standard.
What's even dumber about this comment is that you're making it in support of an argument virtually nobody in the field supports, which is that the NIST P-curves are somehow "backdoored". As you know, or at least should know before talking about this stuff, there is virtually no relationship between the P-curves and Dual-EC. But you're happy to exploit the general lack of understanding about the distinction to score points on HN, even if means dumbing the whole thread down.
To head off some other comment you'll write 6 months from now without me noticing: you can easily peruse the site history and see me consistently arguing against use of the P-curves (in fact, I cite the P-curves is a damning failure of DNSSEC, which you'll no doubt find some fig leaf some years from now to claim I also support). But not because the curves are "backdoored"; rather, because modern curves are misuse-resistant.
Since I'm assuming you have at least the ability to Google, I'm expecting you to cite Bernstein's analyses of the flexibility NSA's generation process provided for hunting for vulnerable curves. To see that outré claim rebutted, here's another Google search for you: [koblitz menezes enigma curve]. Happy to help.
Meanwhile, your message betrays no evidence of understanding what misuse-resistance in curves means, though you've been happy to preen about cofactors and Schnorr signatures on other threads; you depict the choice between 25519 and P-384 as one between a "suspicious generation mechanism' and an "immature" alternative. Of course, that's not why serious designs use 25519; rather, it's because 25519 is less susceptible to curve point validation vulnerabilities and is designed to be straightforwardly implemented without side channels.
Your comment is one of the most gratuitously uncivil and mean-spirited things I've had directed at me on this site, and I have been the target of a lot of mean-spirited bullshit here.
I apologize for giving you what seems to have felt like a kick in the knee.
That isn't something that I wanted, but at the same time, I earnestly believe you've harmed the world with your positions-- which have, in my view, consistently and inexplicitly apologized for both suspicious and unethical conduct from the US government. Not just in your commentary about backdoor risks, but also in your commentary about Snowden, Manning, and Wikileaks.
I suppose I lack the communications chops required to be crisp and clear in that disapproval without it coming across as mean. For whatever it's worth, I earnestly don't think you are a bad person, but I do think that you've found yourself stuck behaving consistently with years of mistaken positions (perhaps some of which your income depended on?... gross speculation on my part, I admit). In any case, I am happy to extend you the benefit of doubt to believe you're at worst just mistaken, I hope you can find it in your heart to do the same for me.
If no one close to you that you trust has said similar things to you about your positions on HN then I think people must be afraid to be frank to you. I've had people who worked for you apologize to me for your conduct on HN when I heard where they worked and responded with a "whats with the government apologia?". And not with a surprised apology but rather a 'sorry, I know, I have heard this 100 times before' sort of tone.
Maybe it's ultimately unfair, but at least w/ some people you've managed to pick up that reputation.
> My twin mistakes: I overestimated both NSA and the industry, in particular vendors
But it isn't the case that vendors merely implemented it-- consider the absolutely astronomical payoff we know that was required for RSA: a company at least on paper full of cryptographic experts-- to implement it.
This wasn't hapless implementers making dumb choices, this was the government standardizing a backdoor then paying people quietly ship it. ( https://www.reuters.com/article/us-usa-security-rsa/exclusiv... ) Doubly so when you consider that until they expired in 2000 RSA patents were used to force people to use the bsafe library.
I'm not quite sure what part of my message really conflates dual-ec and curve selection beyond this one point: I hope we can agree what DualEC provides virtually irrefutable proof that the US government is willing to promulgate backdoored standards.
The only connection to the curve selection is that there are, in fact, degrees of freedom which I believe reasonable people can hold present an actual (if small) risk. I had seen the "Enigma" paper, but I found it fairly unconvincing especially since it patronizes the reader with an argument that the NSA wouldn't select an insecure system, I say patronizes because the track record with DualEC is an extremely a strong counterargument to that position. (You could argue that DualEC is trapdoored to a designated mallory, but Juniper's experience shows that it isn't even that simple!).
It's also relatively straight-forward that if we 'forget' some of the things we have long know about choosing secure curves that is isn't hard to grind a NIST like procedure to choose an actually insecure curve. Consider: if, absent knowing about insecure forms we were cryptographically-unlikely to encounter one, why would the NIST generation procedure include security tests in the inner loop?
For me, it comes down to the simple argument that we can select curves rigidly where there is little avenue to grind in any hidden properties. ... and there are curves from a source known to have released backdoored parameters. It's a needless risk to choose unrigid parameters at all, but especially fool...
Great writeup. Once again, physical access owns. This line stuck out:
> The attack required 11000 signatures
For a smartcard, this seems rather impractical in the real world. My Nitrokey has 1938 total signs after a month of usage, signing every git commit to our company repository and using it to authenticate over ssh (gpg-agent)
It is quite a conservative estimate, we didn't want to claim something our PoC couldn't deliver. Also, it is with minimal attack runtime, as in, after you have those signatures and timings it takes a few minutes to get the private key. There is a trade-off where you can get around some of the noise and thus need less signatures if you just throw more computation resources at it.
At minimum, for asymmetric, at the time of the writing:
* ECDSA with secp-256 or ed25519 curves
* RSA >= 2048 bits. Performance takes a steep dive at 4096bits unfortunately
What people don't understand is that your implementation needs to be selected against your attack surface. If your attack surface includes hardening against side channels, your implementation selection needs to take that into account.
See my original comment about attack surface. Given the correct set of circumstances, transmitting the IV in the clear with CBC could possibly open you up to chosen ciphertext/plaintext attacks. And you better be doing encrypt-then-prepend-IV-then-MAC with CBC. Just a lot of gotchas that may or may not be relevant, depending on your environment.
We can get into the weeds about which specific cryptographic primitives are fine in isolation, but that misses the point — the ones that were fine 5-10 years ago are still more or less fine — the problems for developers and end-users generally stem from accidental misuse of cryptographic primitives in designing systems incorporating cryptographic primitives as a component. Sure, don't use DES, DSA, or MD5/SHA1; strong primitives are only necessary, not sufficient.
The appeal of libsodium is that it is (or was) mostly an easy to consume NaCl. Correct me if I'm wrong, but I don't think libhydrogen is related to NaCl or the NaCl authors.
I like the presentation format of this work. Not only it plays well as a paper, it also contains elements of interactivity to make things more concise and clear. Definitely a thing from the future.
54 comments
[ 4.5 ms ] story [ 110 ms ] thread2. People need to use ECDSA for same reason they need to use RSA: compatibility. In particular, EdDSA webpki certificates will likely never happen (https://cabforum.org/pipermail/servercert-wg/2019-June/00087...).
I understand that most people just take the ref10 code from supercop, but if I were to try to implement ed25519 from the paper (https://ed25519.cr.yp.to/papers.html), what is the chance I would do something like what libgcrypt did, or equally bad?
Basically, is ed25519 secure because everyone uses a known secure implementation or because it is engineered to be genuinely hard to implement incorrectly from the paper? (I know it's both, but is it mostly one or the other?)
1 - They special cased the point at infinity and this short-circuit allowed to count leading zeros.
However, if you were starting with some Short-Weierstrass EC code in your library, then you might be inclined to skip all the scalar multiplication specific stuff in the Ed25519 paper, just take some (incomplete) Edwards formulas, take some general scalar multiplication algo (or even reuse the one you have for Short-Weierstrass, like libgcrypt) and end up with a vulnerable EdDSA (if your ECDSA was).
The short-circuiting in the addition formulas is necessary if incomplete formulas are used. Either that is done, or the scalar multiplication algorithm has to explicitly find out the bit-length and start so that the point at infinity is not input into them ever.
Thank you for the explanation!
In https://minerva.crocs.fi.muni.cz/#details-reasons and in your comment you're describing two bad ways to do scalarmult, but you do not show side-by-side the correct way (e.g. what ref10 does). Can you describe it in a sentence or two?
One of the main points in the root causes discussion is that without complete formulas you are almost always going to leak the bit-length, so the only way to not be vulnerable in that case is to fix the bit-length to a constant value. This cannot be done naively by simply setting the high bit, because this would introduce bias in the nonces which would be exploitable even without measuring the duration, a much worse attack! However it can be done via the method suggested by Brumley & Tuveri in https://eprint.iacr.org/2011/232 where you add a multiple of the curve order to the scalar to fix its bit-length. This means the distribution of the nonce modulo the order remains the same (uniform, no bias) yet the bit-length used in scalarmult as a loop bound is constant.
https://wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_...
Then there's some much more general concerns about the NIST curves themselve. These concerns come down to that a) we don't really know how they were generated (there are some numbers in the paper that just "appear out of nowhere") and b) that they've been created by the NSA. But there's no concrete proof of any backdooring and it seems relatively implausible, as no method is known that would explain how that backdooring would work. I guess most people familiar with the facts don't believe they are backdoored.
1 - https://eprint.iacr.org/2016/376.pdf
He's spent countless hours tirelessly denying the existence of programs that have subsequently been proven to exist. He clearly has a huge blindspot related to the potential for unlawful and unethical conduct by the US government.
What is clear enough about the NIST curves is that they used a high entropy process that would have easily allowed them to grind to select for undisclosed criteria, somewhat inexplicably. Maybe they used this fact to add security against currently non-public attacks? Maybe they used this fact to weaken them against an attack the public doesn't know about. Maybe, like tptacek, they were largely blind to the concern of government backdoors and just didn't care if the process looked somewhat janky. Regardless of the reason no clarification seems likely to every be made.
The more frustrating point is that the alternative of choice (curve25519/ed25519) is only available at the 252-bit security level, and current goverment guidance discourages ECC below 384 bits. Higher bit ed25519-alikes are no where near as mature or deployed. If your strategy is try to make choices where in the future you'll never have reason to feel stupid about the choices you made the options aren't really that great right now. You either use 384bit+ NIST and are exposed to the suspicious generation mechanism, use ed448 which is some weirdo cryptosystem few other things use, or use ed25519 and violate NSA's recommendation to use >=384 bits. With each of those options if it later turns out to be a bad choice you'll have plenty of reason to feel stupid.
Any chance you could list an example or two?
It did. There were two chances in that timeframe to do some good. One was a set of comments on robust software at 4-5pts with a two follow-ups in comments who plan to learn more. Another was necessary reminder banks can themselves cut funding off opponents like they did Wikileaks. That was 5pts with 2 supporting comments. Whatever you expected me to reply to was presumably going to use up my few comments to do less social good.
I figured I'd throw one your way since you or anyone following this may not know why I don't comment as much in situations with lots of back and forth style discussion. It use up all my comments for probably nothing. Now you know why I didn't reply to several of yours done in that way. Just the rate limit doing its job, Sir. ;)
Edit: I'm keeping everything but "sophistry" I edited out. Although sleepy as hell from 13hr days, I checked out your other comments in that thread. My memory is too bad to know what NSA programs you were calling or not calling in the past. That commenter might be full of shit about that. Original comment stands since it was just as a corroboration they were doing it regardless of what you said.
I've repeatedly acknowledged the existence of USG surveillance programs, including Dual-EC. I believe the "hours" I've spent discussing Dual-EC and PKRNGs in general are also straightforwardly countable; just use the search box:
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
What you're doing here is deceptively reframing a subtle nerd technical argument as a normative argument about USG surveillance. In particular: at no point have you or anyone else ever witnessed me arguing that Dual-EC was okay; rather, my argument was that Dual-EC was so batshit, and such poor tradecraft, that it was unlikely to be a serious NSA program. My argument at the time mirrored that of Bruce Schneier: "never use this, no competent engineer would". My twin mistakes: I overestimated both NSA and the industry, in particular vendors like Juniper, which did in fact implement this standard.
What's even dumber about this comment is that you're making it in support of an argument virtually nobody in the field supports, which is that the NIST P-curves are somehow "backdoored". As you know, or at least should know before talking about this stuff, there is virtually no relationship between the P-curves and Dual-EC. But you're happy to exploit the general lack of understanding about the distinction to score points on HN, even if means dumbing the whole thread down.
To head off some other comment you'll write 6 months from now without me noticing: you can easily peruse the site history and see me consistently arguing against use of the P-curves (in fact, I cite the P-curves is a damning failure of DNSSEC, which you'll no doubt find some fig leaf some years from now to claim I also support). But not because the curves are "backdoored"; rather, because modern curves are misuse-resistant.
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
Since I'm assuming you have at least the ability to Google, I'm expecting you to cite Bernstein's analyses of the flexibility NSA's generation process provided for hunting for vulnerable curves. To see that outré claim rebutted, here's another Google search for you: [koblitz menezes enigma curve]. Happy to help.
Meanwhile, your message betrays no evidence of understanding what misuse-resistance in curves means, though you've been happy to preen about cofactors and Schnorr signatures on other threads; you depict the choice between 25519 and P-384 as one between a "suspicious generation mechanism' and an "immature" alternative. Of course, that's not why serious designs use 25519; rather, it's because 25519 is less susceptible to curve point validation vulnerabilities and is designed to be straightforwardly implemented without side channels.
Your comment is one of the most gratuitously uncivil and mean-spirited things I've had directed at me on this site, and I have been the target of a lot of mean-spirited bullshit here.
That isn't something that I wanted, but at the same time, I earnestly believe you've harmed the world with your positions-- which have, in my view, consistently and inexplicitly apologized for both suspicious and unethical conduct from the US government. Not just in your commentary about backdoor risks, but also in your commentary about Snowden, Manning, and Wikileaks.
I suppose I lack the communications chops required to be crisp and clear in that disapproval without it coming across as mean. For whatever it's worth, I earnestly don't think you are a bad person, but I do think that you've found yourself stuck behaving consistently with years of mistaken positions (perhaps some of which your income depended on?... gross speculation on my part, I admit). In any case, I am happy to extend you the benefit of doubt to believe you're at worst just mistaken, I hope you can find it in your heart to do the same for me.
If no one close to you that you trust has said similar things to you about your positions on HN then I think people must be afraid to be frank to you. I've had people who worked for you apologize to me for your conduct on HN when I heard where they worked and responded with a "whats with the government apologia?". And not with a surprised apology but rather a 'sorry, I know, I have heard this 100 times before' sort of tone.
Maybe it's ultimately unfair, but at least w/ some people you've managed to pick up that reputation.
> My twin mistakes: I overestimated both NSA and the industry, in particular vendors
But it isn't the case that vendors merely implemented it-- consider the absolutely astronomical payoff we know that was required for RSA: a company at least on paper full of cryptographic experts-- to implement it.
This wasn't hapless implementers making dumb choices, this was the government standardizing a backdoor then paying people quietly ship it. ( https://www.reuters.com/article/us-usa-security-rsa/exclusiv... ) Doubly so when you consider that until they expired in 2000 RSA patents were used to force people to use the bsafe library.
I'm not quite sure what part of my message really conflates dual-ec and curve selection beyond this one point: I hope we can agree what DualEC provides virtually irrefutable proof that the US government is willing to promulgate backdoored standards.
The only connection to the curve selection is that there are, in fact, degrees of freedom which I believe reasonable people can hold present an actual (if small) risk. I had seen the "Enigma" paper, but I found it fairly unconvincing especially since it patronizes the reader with an argument that the NSA wouldn't select an insecure system, I say patronizes because the track record with DualEC is an extremely a strong counterargument to that position. (You could argue that DualEC is trapdoored to a designated mallory, but Juniper's experience shows that it isn't even that simple!).
It's also relatively straight-forward that if we 'forget' some of the things we have long know about choosing secure curves that is isn't hard to grind a NIST like procedure to choose an actually insecure curve. Consider: if, absent knowing about insecure forms we were cryptographically-unlikely to encounter one, why would the NIST generation procedure include security tests in the inner loop?
For me, it comes down to the simple argument that we can select curves rigidly where there is little avenue to grind in any hidden properties. ... and there are curves from a source known to have released backdoored parameters. It's a needless risk to choose unrigid parameters at all, but especially fool...
> The attack required 11000 signatures
For a smartcard, this seems rather impractical in the real world. My Nitrokey has 1938 total signs after a month of usage, signing every git commit to our company repository and using it to authenticate over ssh (gpg-agent)
It is quite a conservative estimate, we didn't want to claim something our PoC couldn't deliver. Also, it is with minimal attack runtime, as in, after you have those signatures and timings it takes a few minutes to get the private key. There is a trade-off where you can get around some of the noise and thus need less signatures if you just throw more computation resources at it.
* ECDSA with secp-256 or ed25519 curves
* RSA >= 2048 bits. Performance takes a steep dive at 4096bits unfortunately
What people don't understand is that your implementation needs to be selected against your attack surface. If your attack surface includes hardening against side channels, your implementation selection needs to take that into account.
https://www.nccgroup.trust/us/about-us/newsroom-and-events/b...
https://en.wikipedia.org/wiki/Heat_Vision_and_Jack
For new designs: basically just use libsodium.
For SSH: Ed25519 or 2048 bit RSA.
We can get into the weeds about which specific cryptographic primitives are fine in isolation, but that misses the point — the ones that were fine 5-10 years ago are still more or less fine — the problems for developers and end-users generally stem from accidental misuse of cryptographic primitives in designing systems incorporating cryptographic primitives as a component. Sure, don't use DES, DSA, or MD5/SHA1; strong primitives are only necessary, not sufficient.
Check out libhydrogen from the same author. The API contains less footguns (like nonces).
https://latacora.singles/2018/04/03/cryptographic-right-answ...
On a glance none of those recommendations have become invalid in the passing 18 months or so.
https://www.securetechalliance.org/athenas-idprotect-smart-c...