This post is a welcome change from the derogatory yelling that usually surrounds these topics: “Don’t use RSA!” — often ignoring that those who are using RSA often have unfortunate constraints (legacy, etc.) or very good reasons imposed by corner cases outside of their control.
One particularly illustrative example of the hard-headedness that I’m referring to is an incredibly abrasive and elitist post from 2019, which was originally titled, simply, “Fuck RSA” and which focused more on just signaling the authors’ doubtlessly impressive knowledge of RSA’s shortcomings instead of recognizing that some developers using RSA aren’t blubbering fools, but are simply stuck with it for some reason or another.
The API suggested suggested by Soatok’s post, on the other hand, is sufficiently agnostic and provides a helpful grounder for all sorts of developers who could be reading the post. This useful framework is surrounded by exactly the sort of considerations that non-specialist engineers should be primed to think about! It takes a thoughtful mind to be truly pedagogical.
This sort of anti-elitist, non-judgmental, well-written and accessible focus on providing standard engineering solutions is exactly what applied cryptography needs more of.
Another author who writes like this is Vitalik Buterin. His explainers of ZK math are always a joy to read, largely because you feel like he’s genuinely interested in explaining valuable concepts to you in a simple and honestly accessible way, and that by doing so, he solidifies his own knowledge in his mind. Here’s one example.
Really liked the first paragraph. Can’t comment on anything else, because I’m of the lucky few who don’t have to work with RSA systems, so I just skipped the rest of the blog post. (I’m joking, I have read the rest and liked it)
If you’re still reading, then I assume one of two things is true:
You’re implementing RSA encryption and/or signatures, because you can’t avoid this algorithm in your system requirements.
You’re just curious about what I’m going to recommend.
Like you, I am squarely in the second category. Fantastic article as always @soatok, but my main take-home was that I want to try really hard to remain in the second category.
Took me a few days to find the time to read the post.
I feel like I’d remove quite a bit more flexibility. E.g. all the discussions about e - I simply think this shouldn’t be part of the key, but fixed. Almost every standard in the past year settled on e=65537, so I think if you reimplement anything in RSA, your code should be “if (e!=65537) fail;”.
Further you’re kinda doing that, but I’d emphasize that one shouldn’t allow arbitrary keysizes and it’s adding a whole lot of complexity to RSA that this was ever allowed. Let’s Encrypt started disallowing anything !={2048,3072,4096} for interesting reasons (makes it easier to block Debian weak keys).
This post is a welcome change from the derogatory yelling that usually surrounds these topics: “Don’t use RSA!” — often ignoring that those who are using RSA often have unfortunate constraints (legacy, etc.) or very good reasons imposed by corner cases outside of their control.
One particularly illustrative example of the hard-headedness that I’m referring to is an incredibly abrasive and elitist post from 2019, which was originally titled, simply, “Fuck RSA” and which focused more on just signaling the authors’ doubtlessly impressive knowledge of RSA’s shortcomings instead of recognizing that some developers using RSA aren’t blubbering fools, but are simply stuck with it for some reason or another.
The API suggested suggested by Soatok’s post, on the other hand, is sufficiently agnostic and provides a helpful grounder for all sorts of developers who could be reading the post. This useful framework is surrounded by exactly the sort of considerations that non-specialist engineers should be primed to think about! It takes a thoughtful mind to be truly pedagogical.
This sort of anti-elitist, non-judgmental, well-written and accessible focus on providing standard engineering solutions is exactly what applied cryptography needs more of.
Another author who writes like this is Vitalik Buterin. His explainers of ZK math are always a joy to read, largely because you feel like he’s genuinely interested in explaining valuable concepts to you in a simple and honestly accessible way, and that by doing so, he solidifies his own knowledge in his mind. Here’s one example.
It’s linked in the first sentence..
Really liked the first paragraph. Can’t comment on anything else, because I’m of the lucky few who don’t have to work with RSA systems, so I just skipped the rest of the blog post. (I’m joking, I have read the rest and liked it)
Shortly after that, you come to:
Like you, I am squarely in the second category. Fantastic article as always @soatok, but my main take-home was that I want to try really hard to remain in the second category.
That’s an excellent take-home :3
Not all software has caught up, so thanks. For example, openssl cms/smime appears to still only have RSA support.
Took me a few days to find the time to read the post.
I feel like I’d remove quite a bit more flexibility. E.g. all the discussions about e - I simply think this shouldn’t be part of the key, but fixed. Almost every standard in the past year settled on e=65537, so I think if you reimplement anything in RSA, your code should be “if (e!=65537) fail;”.
Further you’re kinda doing that, but I’d emphasize that one shouldn’t allow arbitrary keysizes and it’s adding a whole lot of complexity to RSA that this was ever allowed. Let’s Encrypt started disallowing anything !={2048,3072,4096} for interesting reasons (makes it easier to block Debian weak keys).
Good points all around :)