
RSA is a fragile cryptosystem - ingve
https://blog.trailofbits.com/2019/07/08/fuck-rsa/
======
skrebbel
I'm a developer, not a cryptographer, and like most crypto articles, most of
this post is gibberish to me. I really tried to follow it in the beginning,
but then I gave up, scrolled to the "what should you use instead", and then
realized I didn't understand that either.

If this is article is "easy" crypto, and I shouldn't roll my own crypto, then
what should I do? "Just use elliptic curve crypto but make sure you choose the
right curve! Here's an abbreviation for you, libsodium has it so you're all
set" doesn't comfort me much. I don't have a good intuition of what a curve
even is and why my sensitive data can't just go straight ahead like all the
other data. I mean, when I call into libsodium with parameters I do not
understand, then aren't I, for all intents and purposes, rolling my own crypto
anyway? How is any of this of help?

If I want to allow my customers to send me encrypted data via an untrusted
channel, then what do I do? I need public key crypto for that, right?
Basically, I want the public key cryptography version of Coda Hale's classic
blog post about password hashing [0], does that exist?

EDIT: thanks for all the comments folks, great insights! I particularly found
[1] by CiPHPerCoder to be a great starting point (akin to Coda's password
article) for all kinds of scenarios. I feel much more confident about this
stuff now than I did 2 hours ago.

[0] [https://codahale.com/how-to-safely-store-a-
password/](https://codahale.com/how-to-safely-store-a-password/)

[1] [https://paragonie.com/blog/2017/06/libsodium-quick-
reference...](https://paragonie.com/blog/2017/06/libsodium-quick-reference-
quick-comparison-similar-functions-and-which-one-use)

~~~
tialaramex
Taking you seriously for a moment. You don't need to understand elliptic curve
mathematics. As with any other public key crypto system there will be a
Private Key which you must never reveal to anyone else, and a Public Key which
everybody can be told. They're bits. You don't need to care what those bits
mean, if you find yourself using software which expects you to care what the
bits mean that's too low level, bail out and find higher level software.

Unfortunately Coda Hale's post makes a bunch of assumptions. Reasonable
assumptions for a lot of the audience, but they're still assumptions. So an
equivalent post has to either make equally broad assumptions OR it has to ask
you a bunch of questions.

Not crypto questions, but just questions about what you actually want to
achieve by having public key crypto. That's going to dictate what you should
do. In particular Public Key crypto almost invariably ends up with questions
about Identity because of the Public Keys, how do I know this is Bob's Public
Key? Do I care about that? Who is "Bob" anyway?

Example #1: For a Web Browser the answer is Identity means the Internet DNS
hierarchy decides what hosts are named, the Web PKI provides us with an
Authority that says this public key belongs to news.ycombinator.com. It's up
to the end user to decide whether that's Hacker News or the Disney Company.

Example #2: For Signal the answer is that Identity is defined only locally by
a user's own "address book" or similar features and they get to decide whether
this contact is really "Dad" or "skrebbel" or "Jenny Smith", Signal promises
to tell you if "Dad" doesn't have the same public key any more (which is
suspicious), but paternity tests or verifying in person that "Dad" isn't just
a proxy are your problem.

If in fact you "want to allow my customers to send me encrypted data via an
untrusted channel" in 2019 you should just set up a secure Web Server, with a
Fully Qualified Domain Name your customers know (e.g. write it on business
cards, or the sides of vans, or a huge building) with a form on it, where they
can submit things. Done. Choose a web server you like and go look at Mozilla's
instructions for securing Web Servers.

~~~
cesarb
> If in fact you "want to allow my customers to send me encrypted data via an
> untrusted channel" in 2019 you should just set up a secure Web Server, with
> a Fully Qualified Domain Name your customers know (e.g. write it on business
> cards, or the sides of vans, or a huge building) with a form on it, where
> they can submit things.

That assumes the customer's browser is trusted, and not configured to silently
allow all encrypted connections to be intercepted, decrypted and potentially
modified by someone else in the network, which is unfortunately still too
common.

~~~
saagarjha
Do you have ideas for a more secure platform than this that the average person
can actually use?

------
tptacek
Nitpick:

This includes some attacks that I don't think really ever occur in the real
world (bad private exponent size, Franklin-Reiter) and misses one of the great
RSA attacks, Bleichenbacher's "rump session" e=3 signature attack, about which
there was an excellent NDSS paper (also being presented at Black Hat) just
this year.

So I guess I'm saying: RSA is even worse than this blog post suggests.

[https://www.ndss-symposium.org/wp-
content/uploads/2019/02/nd...](https://www.ndss-symposium.org/wp-
content/uploads/2019/02/ndss2019_04A-4_Chau_paper.pdf)

~~~
philbarr
While the rule for devs is, "never roll your own crypto", what is the
authoritative resource for what we _should_ use?

~~~
munchbunny
It depends on what you're trying to accomplish.

Rule of thumb is: just use TLS 1.3 if you can. That includes using TLS 1.3 in
mutual auth mode if you need to validate both client and server identities. It
comes with a lot of PKI for free to help address the "how do you know you can
trust the other guy on the line?" problem. If you want the client/server to
trust a restricted list of servers/clients, most clients and servers have that
capability.

If SSL/TLS won't suffice and you just need to create an end to end "thing"
with proof of identity, then libsodium is probably fine.

If you're looking for a more general purpose crypto library where you need to
mix and match algorithms, I'd recommend something like Google Tink
([https://github.com/google/tink](https://github.com/google/tink)), or the
high level interface to the native API's that come with the OS. On OS X that's
the native security framework
([https://developer.apple.com/documentation/security](https://developer.apple.com/documentation/security)),
and on Windows that's the .NET cryptography library
([https://docs.microsoft.com/en-
us/dotnet/api/system.security....](https://docs.microsoft.com/en-
us/dotnet/api/system.security.cryptography?view=netframework-4.8)).

If you need even more flexibility and are willing to do the research to avoid
the footguns, there's always OpenSSL/LibreSSL, but that comes with a huge
footgun warning.

~~~
loup-vaillant
> _It comes with a lot of PKI for free to help address the "how do you know
> you can trust the other guy on the line?"_

I would hesitate to trust a high stakes system (like, controlling a regional
power grid) with TLS's default PKI. There are hundreds of certificate
authorities out there, all of which can vouch for everything. Compromising
_one_ certificate authority is enough to mount a man in the middle attack.

Granted, this is not a trivial attack, and TLS as it is now is mostly
sufficient for your regular online shopping. More critical applications
however need a dedicated PKI.

~~~
munchbunny
Absolutely, which is why I included the extra point:

 _If you want the client /server to trust a restricted list of
servers/clients, most clients and servers have that capability._

If you are running a regional power grid, TLS as a technology is still fine,
but you should absolutely not trust the default PKI.

~~~
loup-vaillant
Oops, missed that, sorry.

------
groovybits
I generally enjoy the content that Trail of Bits puts out, but the harsh tone
and use of explatives seems only for the sake of attention to a non-issue.
RSA, the algorithm, is generally safe for real-world use. It is possible to
use RSA securely (we've been doing it). However, there is indeed an issue.

Lets define the issue: Poor understanding of cryptography leads to poor
implementation in practice.

This issue applies to any crypto algorthim, not just RSA and ECC. If everyone
dropped RSA tomorrow in favor of ECC, would all of our problems be solved? No.

How to solve this issue?

1\. Increase understanding of general cryptography. It is a dense subject.

2\. Make implementation of cryptography easier. This is slightly more
difficult though, as it depends on your use-case.

~~~
reaperhulk
The specific tone of this post is purposefully bombastic to call attention to
the fact that RSA is uniquely difficult to implement and utilize correctly.
Newer cryptographic constructs use various methods to reduce the probability
of incorrect implementation and improve misuse resistance. Are they perfect?
Of course not! But we're improving all the time with signature algorithms like
ed25519, NMR constructions like SIV, etc.

~~~
intuitionist
I don’t think the problem is that RSA is harder to implement correctly than,
say, Curve25519. The problem is that it’s much easier to implement _almost_
correctly.

------
mikorym
Unless I am stupid, these are all implementation specific problems (e.g.: bad
key selection, bad key size selection, exploits due to coding errors, etc.)
and this does not tell us anything new about prime number factorisation.

If this assumption is correct, why not just recommend a key size and some
checks for generation than recommending elliptic curves? Elliptic curves have
their own problems especially due to their complications around exploits of
specific curve properties but more importantly the fact that programmers won't
understand what they are calling in their code.

I understand that _libsodium_ has been here now since 2005, but are we really
at the point where we should stop using RSA just because a lot of
Salesforce/Oracle/Azure/<insert boring job> developers are misusing RSA? I
guess this question is really about whether we are at the anecdote stage or
the herd immunity risk stage that OP mentions.

~~~
lvh
It doesn't need to tell you anything new about prime number factorization
because practical RSA cryptosystems get broken with far more boring bugs than
prime number factorization. RSA padding bugs aren't really "coding errors":
RSA padding is just as critical to RSA security as the hardness of number
factoring.

Furthermore, they don't just tell you to use some random curve thing: they
tell you to use a specific implementation with knobs twiddled for security.
You could work hard to maybe get everything right, or you can just do this
thing and everything will be set for safety for you.

~~~
mikorym
So, to be Devil's Advocate, does libsodium also provide an RSA implementation?

~~~
tabletopneedle
There is no place to use RSA instead of Diffie-Hellman. DH provides forward
secrecy, and the ECC variants are much faster and use shorter keys for
equivalent security. They are harder to implement in a wrong way.

------
baby
From my point of view, RSA has been damaged by too many bad implementations
and standards, eventhough it is a legitimate cryptographic algorithm. I even
co-authored a paper[1] with Shamir himself that ended on recommending not to
use RSA in 2019.

I'm currently writing a book targetted to developers[2] and I'm wondering how
much I should write about RSA.

There are two cryptographic primitives (types of algorithm) exposed by RSA:

* Encryption

* Signature

The signature algorithm has two adopted standards usually named RSA PKCS#1v1.5
and RSA-PSS. The latter one is more recent and provides a proof of security
but everyone still use the former. The former hasn't been broken and is still
pretty solid. Most internet certificates are signed using RSA PKCS#1v1.5 I
believe.

The encryption algorithm is the problem (also used to perform key exchanges).
It also has two adopted standards usually called RSA PKCS#1v1.5 (same name as
the signature scheme I know...) and OAEP. OAEP is more recent and quite
secure, but nobody seems to use it. Instead the former is still largely used
in applications, and is often the default algorithm you use when you write RSA
in many cryptographic libraries. Unfortunately it has been broken by
Bleichenbacher in 1998 and it is _practical_ to attack it. There's been many
attempts to "fix" it and they have been repeatidly broken as well. So don't
expect the library you use to implement it correctly.

[1]: [https://eprint.iacr.org/2018/1173](https://eprint.iacr.org/2018/1173)
[2]: [https://www.manning.com/books/real-world-
cryptography](https://www.manning.com/books/real-world-cryptography)

~~~
xucheng
> The former hasn't been broken and is still pretty solid. Most internet
> certificates are signed using RSA PKCS#1v1.5 I believe.

FYI, RSA PKCS#1v1.5 signatures can be broken due to trivial implementation
errors. [1]

[1]:
[https://www.cs.purdue.edu/homes/schau/files/pkcs1v1_5-ndss19...](https://www.cs.purdue.edu/homes/schau/files/pkcs1v1_5-ndss19.pdf)

~~~
baby
Thanks! I hadn't seen that paper :)

From a cursory glance, all of these implementations are in C it seems like a C
systemic issue, not an issue with RSA.

But I might be wrong because I've yet to read the paper.

~~~
tptacek
I'm confident you were aware of the bug in that paper, David, since it's just
the e=3 cube-root attack on unvalidated P1v15 padding.

~~~
baby
Are you talking about the broadcast attack? This is on signatures, and it
seems different from bleichenbacher's signature forgery.

(But again, haven't read the paper, also don't remember how bb signature
forgery works)

(I'll read the paper but right now I'm in Hawaii doing snorkeling)

~~~
tptacek
This is in Cryptopals! You were a Cryptopal! How did you get through that
without implementing the e=3 sig attack?

The bug is straightforward: RSA implementations don't verify all the bits in
the padding, but rather "parse" it to find the digest, and then verify that.
But there are, of course, bajillions of potential padded signature block
representations that contain any given digest, since the block is so much
bigger than the digest. For e=3, and for particularly naive implementations
(like Firefox's, at the time) you can almost literally just formulate the
signature block you want, then take its cube root to forge a signature.

~~~
baby
Oh right. Thanks for the reminder :)

Sorry to disapoint I did not do all the cryptopals :P filippo actually has a
good blogpost on that attack IIRC.

~~~
tptacek
You have, in fact, disappointed me! :|

(There are some set-7 problems I haven't done yet, for whatever that's worth.
But e=3 sigs are a big one!)

~~~
baby
Alright I will do it :D

~~~
tptacek
Honestly, if you can find a broken implementation (or just write one; do the
RSA "decrypt" of the signature block, and then just use a constant offset to
get to the digest bytes), you should be able to knock it out just from the
description I provided in like, 30 minutes.

------
segfaultbuserr
Curve25519 and Curve448 should be strongly favored if you decided to start
using ECC. Not unlike RSA, elliptic-curve cryptography has a lot of of edge
cases, math pitfalls, and side-channel traps.

* Your implementation produces incorrect results for some rare curve points.

* Your implementation leaks secret data when the input isn't a curve point.

* Your implementation leaks secret data through branch timing.

* Your implementation leaks secret data through cache timing.

Curve25519 and Curve448 are designed with secure implementation in mind,
naturally, they trends to have more immunity to pitfalls. There is no invalid
curve attack in Curve25519, every random integer is a valid public key,
secret-dependent branching can be avoided easily, etc.

[https://safecurves.cr.yp.to/](https://safecurves.cr.yp.to/)

~~~
yarg
It's not simply that they were designed to be secure - they utilised
mathematically justifiable constants.

See [https://en.wikipedia.org/wiki/Nothing-up-my-
sleeve_number](https://en.wikipedia.org/wiki/Nothing-up-my-sleeve_number).

There's actually a counter example on that Wiki page - the highly complex
numbers used in the NIST curves, for which no path to derivation was publicly
provided.

~~~
segfaultbuserr
> _There 's actually a counter example on that Wiki page - the highly complex
> numbers used in the NIST curves, for which no path to derivation was
> publicly provided. _

It's _both_. The security of curves are evaluated according a set of criteria:

 _1\. Whether the cost for attackers by the Rho Method is above 2^100?
(security margin against known attack)_

    
    
       - NIST P-Curves: Yes.
    
       - Curve25519/448: Yes.
    

_2\. Whether the curve has resistance against additive and multiplicative
transfer to avoid potential attacks via index calculus? (security margin
against known attack)_

    
    
       - NIST P-Curves: Yes.
    
       - Curve25519/448: Yes.
    

_3\. Whether the absolute value of this complex-multiplication field
discriminant D of the curve is larger than 2^100 to avoid attackers from
benefiting from possible speedups to the Rho Method? (security margin against
known attack)_

    
    
       - NIST P-Curves: Yes.
    
       - Curve25519/448: Yes.
    

Notably,

    
    
       - Bitcoin Curve (secp256k1): No.
    

But it doesn't mean Bitcoin is broken, it just decreases our confidence that
it would be still secure if HUGE speedups to the Rho Method are found for a
practical attack. But finding it seems unlikely.

 _4\. Whether the coefficients of the curve are justified mathematically?
(security criteria against backdoor)_

    
    
       - NIST P-Curves: No (!)
    
       - Curve25519/448: Yes.
    
       - Bitcoin Curve (secp256k1): Okay.
    

For example, coefficients for NIST P-256 (secp256r1, prime256v1) is generated
by hashing random seed:

    
    
        c49d3608 86e70493 6a6678e1 139d26b7 819f7e90
    

Nobody knows what is it. NIST has its own defense: this random seed is only
used as the input of SHA-256, since all cryptographers know that SHA-256 is
secure, nobody, not even the NSA, can invert SHA-256, the output must be
secure. They called it "verifiable randomness". But it's still room of doubts
for sophisticated cryptographers, e.g. See this highly-amusing, satirical
paper with lots of insight on this issue: _How to manipulate curve standards:
a white paper for the black hat_
[https://bada55.cr.yp.to/bada55-20150927.pdf](https://bada55.cr.yp.to/bada55-20150927.pdf)

Coefficients for secp256k1 are not fully explained, but nothing fishy and
generally looks good.

And keep in mind that when Satoshi Nakamoto was developing Bitcoin, secp256k1
was the best choice among available, well-accepted standard curves from this
perspective, obviously, Satoshi must be an experienced hacker and have made a
careful decision.

 _5\. Whether the construction of the curve allows "simple" multiplication and
addition. (security criteria against implementation pitfalls)._

    
    
       - NIST P-Curves: No.
    
       - Curve25519/448: Yes.
    
       - Bitcoin Curve (secp256k1): No.
    

Curve25519 utilizes a mathematical technique called Montgomery Ladder, which
also allowed the practical implementation of constant-time, side-channel
resistance crypto. On the other hand, NIST curves make it difficult.

 _6\. Whether the curve still offers strong security guarantee even if an
attacker has "twisted" the curve, e.g. fooling a program to choose a point
which is not on the actual curve. (security margin against known attack and
implementation pitfalls)_

    
    
       - NIST P-Curves: Yes.
    
       - Curve25519/448: Yes.
    
       - Bitcoin Curve (secp256k1): Yes.
    

_7\. Whether the representation of curve points are indistinguishable from
uniform random strings. (security usefulness in various protocols)_

    
    
       - NIST P-Curves: No.
    
       - Curve25519/448: Yes.
    
       - Bitcoin Curve (secp256k1): No.
    

Therefore, we conclude Curve25519/448 is more robust than NIST curves.

~~~
kwantam
Note that #7 is not actually true anymore, and actually hasn't been for quite
a while.

A paper from Mehdi Tibouchi [1] shows how to represent points on essentially
any curve as uniform random bitstrings.

Another paper by Aranha, Fouque, Qian, Tibouchi, and Zapalowicz [2] gives an
even more efficient construction for curves over binary fields.

(As an aside, there are really good reasons not to use curves over binary
fields. Discrete log has recently been getting easier _much_ faster over
GF(2^k) than over GF(p).)

[1] [https://ia.cr/2014/043](https://ia.cr/2014/043)

[2] [https://ia.cr/2014/486](https://ia.cr/2014/486)

~~~
mti
The hardness of discrete logs over fields doesn't have much to do with the
hardness of elliptic curve discrete logs. At this stage, I don't think we have
any evidence that curves over binary fields are less secure than over prime
fields, especially for cryptographically relevant curve sizes.

(The situation is different for _pairing-friendly_ elliptic curves, of course,
but that's a different kettle of fish).

------
ChrisSD
Indeed. If you're not a cryptographer then you shouldn't be rolling your own
crypto. That includes selecting low level libraries, etc. You want a whole
crypto system that's made by experts. Preferably one that's open to auditing.

~~~
A2017U1
How does one become a cryptographer then?

Do the people who perpetuate this meme with no basis not realise the clear and
present danger it presents to humanity?

Yes certainly don't use homerolled crypto in production.

More importantly do not dissuade human beings with talent to roll their own,
play with others codebases, and in general have a good fucking time with
cryptography.

Straight out of the counter-intel handbook is how it looks when people repeat
this bullshit ad nauseum.

Everyone on Earth should roll their own crypto. Don't listen to this nonsense,
the real world needs you.

~~~
inlined
> Everyone on Earth should roll their own crypto. Don't listen to this
> nonsense, the real world needs you.

This is an interesting exercise to help understand cryptography, but if you
think cryptography is subtle or magical, you haven’t started looking at
cryptanalysis. There are nearly countless possible side channel attacks. This
is why we don’t roll our own practically speaking. It can take advanced
degrees in mathematics to merely give ourselves some sense of assurance that
our home rolled system is safe.

A friend of mine _did_ roll his own security. A decade ago he invented a new
homomorphic encryption algorithm (type of encryption that allows meaningful
operations on cypertext without revealing secrets). His first step? Getting
advanced degrees in mathematics and at least a year of peer review to test
against possible attacks. Only years later did he found a company on it.
Unfortunately while the system was believed secure, a zero-trust system took
too long and too much battery to generate keys on phones.

~~~
sroussey
Any reference to their work?

~~~
inlined
[https://www.google.com/amp/s/www.forbes.com/sites/thomasbrew...](https://www.google.com/amp/s/www.forbes.com/sites/thomasbrewster/2015/09/09/kryptnostic-
homomorphic-encryption/amp/)

------
commandlinefan
And the NSA is recommending that we not use ECC anymore, either:
[https://threatpost.com/nsas-divorce-from-ecc-causing-
crypto-...](https://threatpost.com/nsas-divorce-from-ecc-causing-crypto-hand-
wringing/115150/)

~~~
snarf21
There are some weak curves that may be vulnerable. This is mostly
(conjectured) to be about quantum computing. However, the solution they offer
is RSA 3072. No thanks, I'll stick with ECC. We'll know pretty instantly when
ECC gets cracked as the whole crypto space will collapse like a balloon. You
could also be more cynical and assume that the NSA has a backdoor for even
huge RSA and just want to push people to something they pwn.

~~~
monkeynotes
Given what we know about the NSA, do you have to be 'cynical'? I think a
backdoor is even likely.

~~~
commandlinefan
Koblitz and Menenez took a long look at that - they believe it's possible, but
not necessarily likely:
[https://eprint.iacr.org/2015/1018.pdf](https://eprint.iacr.org/2015/1018.pdf)

~~~
monkeynotes
Given the known motivations of the NSA, and the deep involvement they had in
designing and promoting SHA and its derivatives gives reasonable doubt to
their benevolent credibility.

Look at the amount of trouble the NSA went into to create Stuxnet. They stole
digitally signed certificates from big corporations, completely undetected.

If a known burglar installed your home security system, even if the security
system was from a well known and trusted manufacturer would you trust that
your house was actually secure while you were on vacation?

~~~
tptacek
What's this supposed to mean? SHA-2, which is an NSA design, is one of the
best cryptographic hashes we have. SHA-1 fell, but so did MD4 and MD5, the
other mainstream hashes of that era.

------
gnomewascool
To anybody put off by the clickbaity title, as I initially was — the article
is actually informative and well-written.

~~~
rhacker
Same here, especially considering the 3 men are alive and may read the title
it's a bit rude.

~~~
OJFord
Fully agreed, (alive or not!) and commented to the same effect before I saw
yours.

'RSA is easy to get wrong, stop using it' would be better. More descriptive
too.

[https://news.ycombinator.com/item?id=20382895](https://news.ycombinator.com/item?id=20382895)

------
beefhash
> The common denominator in all of these parameter attacks is that the domain
> of possible parameter choices is much larger than that of secure parameter
> choices.

Parameter selection isn't any easier in elliptic curve land. In fact, by the
point that I believe you can make an educated choice in elliptic curves, you
can also make a reasonable choice in RSA parameters.

You have to:

1\. Pick a curve. Which ones? You'll have to know. This article tells you to
use Curve25519. Do you know if they're right? Not really. Is a Koblitz curve
over GF(2m) a better choice? You sure can't tell. You'll have to rely on other
people's guides, e.g. [1].

2\. Pick a _library_ that supports the curve. This can be easy if you're on
the beaten path, especially in C. This can be very hard on off-beat languages,
which are generally stuck wrapping OpenSSL (and then typically have a weird
interface to match as a cause of having to wrap C).

3\. Interoperability concerns: Sometimes you don't actually control both
halves of the software. You'll also have to pick something that plays nice
with other things.

 _And all of this is putting the cart before the horse_. Programmers must
first understand what kind of algorithm they need, only then they can make a
choice of the actual cryptographic solutions, e.g. Crypto101[2]. I firmly
believe that a basic working knowledge of cryptography is a hard requirement
for a programmer that touches code going into production.

If by some ungodly anti-miracle you're stuck implementing your curve yourself,
you'd better be hiring external help. Ideally, however, you can use an
existing, respected library. What _is_ a "respected" library? Well, now we're
back to “you'll have to know”. Expect to spend upwards of a dozen hours
getting to grips with the basics.

(Incidentally, public key cryptography has always been an implementation
nightmare. ARX ciphers don't scare me as much and most hash functions seems
fairly reasonable to implement, but public key cryptography is when the bignum
math hell comes to bite you—and with elliptic curves, you also get “moon
math”, as the article so aptly puts it, to go with it.)

[1]
[https://news.ycombinator.com/item?id=20382244](https://news.ycombinator.com/item?id=20382244)

[2] [https://www.crypto101.io/](https://www.crypto101.io/)

~~~
lvh
Oh, hey, [2], that's me, glad you liked it.

FWIW: while I clearly subscribe to the notion of cryptographic education, I
also thing that we should give people high-level recipes. Why are they the
right ones? Yep, you gotta trust me. I'm fine with both of those existing
('tptacek and I co-authored our Cryptographic Right Answers doc from last
year) because they have different audiences.

~~~
tabletopneedle
Hey, just wanted to chime in Crypto101 was the ~first book I read on crypto
and it was really well written. Kudos for your work.

------
dwheeler
The CII best practices badge (
[https://bestpractices.coreinfrastructure.org](https://bestpractices.coreinfrastructure.org)
), which identifies key best practices for OSS projects, doesn't forbid the
use of the RSA algorithm. In many situations forbidding the use of RSA (when
using a public key cryptosystem) is completely impractical today. RSA is
really popular, and a lot of OSS projects _must_ be compatible with systems
and organizations that use RSA.

Besides, it appears to me that the _primary_ problem is people who roll their
own RSA implementations. As the article says, "In circumstances where people
implement their own RSA, all bets are off in terms of using standard RSA setup
procedures, and developers will frequently do strange things...". It also
later shows a picture where the disastrous choice is "rolling your own RSA".
Yes, there are a lot of ways to screw up an RSA implementation (as noted in
the article), but that's less important if it's implemented by people who know
what they're doing.

The CII badge _does_ specifically address the problem of people who roll their
own crypto. Specifically, its "crypto_call" criterion says: "If the software
produced by the project is an application or library, and its primary purpose
is not to implement cryptography, then it SHOULD only call on software
specifically designed to implement cryptographic functions; it SHOULD NOT re-
implement its own." [https://github.com/coreinfrastructure/best-practices-
badge/b...](https://github.com/coreinfrastructure/best-practices-
badge/blob/master/doc/criteria.md#crypto_call)

Full disclosure: I lead the CII Best Practices badge project.

~~~
loup-vaillant
> _it appears to me that the primary problem is people who roll their own RSA
> implementations_

And why do you think they do? The article has an explanation for this: RSA
looks easy enough to implement. If you tell people to use RSA, many _will_
roll their own, even if they don't know what they're doing.

And to be honest, after having read this article, I don't trust even the
properly peer reviewed implementations of RSA. And if compatibility is an
issue, I'll first try to convince whoever I must convince to switch to
Curve25519, which is simpler to implement, more secure, _and_ faster in most
cases. (Of course, one should still use an existing implementation.)

~~~
dwheeler
There are many advantages to Curve25519, but in many cases you need to use
RSA. E.g., when you're trying to talk to arbitrary websites securely, you
don't get to choose what was used to sign their certificate. There are many
circumstances where you have to build systems that work with other systems,
and ignoring that doesn't make it go away.

I think the key advice is to use an existing crypto library. A non-expert who
tries to implement ECC themselves will almost certainly screw it up as well.
Sure, it is a little less likely, but it is still possible.

------
alltakendamned
For any of you who want to develop a deeper understanding of what is mentioned
in the blog post, I can recommend the book Serious Cryptography by Jean-
Philippe Aumasson. It's one of the best and most accessible crypto books that
have recently been written.

[https://nostarch.com/seriouscrypto](https://nostarch.com/seriouscrypto)

------
Nursie
> TLS 1.3 no longer supports RSA

This isn't entirely true, is it?

AFAICT it no longer supports RSA as a key-exchange algorithm as earlier
versions did, but it certainly supports RSA authentication. The only systems
that used that for TLS I've known in the last 15(ish) years were government
systems that specifically wanted to prevent PFS in their logged connections.

~~~
lvh
According to the F5 telemetry report (and my own anecdotal evidence), non-PFS
suites were a lot more popular than that, the majority as little as 5 years
ago :-)

[0]:
[https://www.f5.com/content/dam/f5/f5-labs/articles/20180423_...](https://www.f5.com/content/dam/f5/f5-labs/articles/20180423_tls_2017/2017_TLS_Telemetry_Report.pdf)

~~~
tialaramex
Definitely. There are loads of EDCO people in that data.

(EDCO is Nalini Elkins' outfit, the Enterprise Data Centre Operators group -
banks and that sort of thing, they tried pointlessly lobbying the TLS Working
Group to get RSA Key Exchange back into TLS 1.3)

I don't have very good contacts inside that industry any more (I now work for
a startup) so I'll be interested to see what if anything they _actually_ do
about this over the medium term. Trying to promote "alternatives" to TLS?
Deploying DH where the "random" private values are actually from a fixed or
pseudorandom source under their control? No idea yet.

It is definitely true that some big name real world "security" companies will
go out to a big corporation and tell them to mandate RSA key exchange in order
to make the "security" product work because they want to do MITM. They're too
cheap to do all the engineering to actually ship the session keys over the
wire so they want you to just upload the RSA Private Key into their "security"
product.

I got this mandate to require RSA Key Ex (at my old job for a B2B app I wrote)
and was like "That ain't going to work, this here is a mutually authenticated
TLS session". And I ended up in a bunch of calls in which more and more senior
people from the "security" product team were brought on until they eventually
found someone who actually knew how it works to say that yes, of course you
can't MITM a mutually authenticated session without assistance from both
parties, so the product can't work.

~~~
lvh
Total agreement re: groups of bigcos trying to sabotage TLS, but I think a lot
of traffic was de facto using RSA because of default configurations, not
because of a serious mandate. Otherwise, I don't think you'd see such a PFS
uptake in the last 5 (as opposed to 15) years.

Current status is eTLS which, if I understand it correctly, is just static DH.
Unclear why nobody isn't just disclosing session keys/premaster secrets per
SSLKEYFILE, but my money is "organizational incompetence" (as yours is, I'm
guessing from your B2B app experience :-)).

[0]:
[https://www.etsi.org/deliver/etsi_ts/103500_103599/10352303/...](https://www.etsi.org/deliver/etsi_ts/103500_103599/10352303/01.01.01_60/ts_10352303v010101p.pdf)

~~~
rocqua
Disclosing secrets per session requires a lot more work on the endpoints.
Especially because it is an active service. That also leaves a _lot_ more
attack-surface on the end-points. It also creates quite a bit of sensitive
network traffic. Things get more hectic if you want 'live' TLS-inspection.

As such, I can definitely see why TLS inspectors don't like the myriad of
opportunities for mistakes created by disclosing secrets at the end-points.

The counter-argument would be that, if you really need TLS-inspection your
security should be tight enough that disclosing the secrets should not be the
hardest thing you are implementing. Moreover, neither should the world
compromise its own encryption to make your targeted (and rarely required)
ability to break encryption safer.

------
raxxorrax
> developers often choose e = 3

Never seen this in all my failed life. It is basically 65537 everywhere I have
seen RSA used. That actually led me to Fermat numbers and why they are used
because it looked like a conspiracy to me.

I also never generated p,q or d manually and just trust some tools from some
crypt-weirdos. So it is 1 parameter I have to remember, right?

I am only a user of RSA and would never implement it myself. But prominent web
services mostly supply RSA parameters for their encrypted content. Some have
shifted to ed25519, but it is still very rare in my experience.

~~~
commandlinefan
> it looked like a conspiracy to me

Not a conspiracy ; ). It has to do with the exponentiation. Most fast math
libraries exponentiate quickly by squaring and multiplying: if you want to
compute, say, x^23, you can either multiply x by itself 23 times, or you can
compute: ((((x^2)^2)x)^2)x^2)x: four squaring operations and four
multiplications for a savings of 15 operations. You can do this factoring
easily based on the binary representation of the exponent - in this case, 23
is 10111. So I’m going to square x 5 times (since the bit length of the
representation is 5 bits long) and additionally multiply x by the result every
time I encounter a one bit. Now, if I want to speed this up, it’s in my best
interest to choose an exponent with the fewest one bits possible - preferably
with a one at the beginning and a one at the end, so now I only have to square
_n_ times and multiply twice. As it turns out, numbers whose binary
representation have a one at the beginning and a one at the end turn out to be
Fermat primes: 2^n+1.

------
rowanG077
So what is it? Just stop using RSA completely or stop rolling your own RSA?
The article sends mixed signals on this, I completely understand the latter as
bad but I have used the RSA framework within .NET to sign messages before and
I don't recall it being hard at all.

~~~
floatboth
Yes. Stop entirely. Developers in fact MUST NOT use ANY crypto primitives
directly. "If you're typing the letters A-E-S into your code, you're doing it
wrong." You WILL do something subtly (or not so subtly) wrong and it won't be
secure.

Use high-level constructs designed and peer-reviewed by cryptographers who
know what they're doing.

Basically: use libsodium.

~~~
piokoch
I really would like to use libsodium, but I use Java. Looking at
[https://libsodium.gitbook.io/doc/bindings_for_other_language...](https://libsodium.gitbook.io/doc/bindings_for_other_languages)
it seems that there are 5 different ports. The question which one is save to
use?

One implementation docs says:

"I'm experiencing some issues on Windows. Do you have any idea?

I'm sorry but I'm completely clueless about Windows environment, but if you
have any suggestions or PR changes. They will be more than welcome."

Can I trust them? How do I know there are no some Windows-specific issues in
this implementation?

Another library listed on this page does not have a single release? Could it
be trusted?

Next has been abandoned and moved into Apache Foundation incubator. Good but
will it be maintained? Maybe use this, or maybe Lazysodium, which has a nice
Github page?

If I am to verify if any of those ports is a proper one probably I would have
to really become a crypto expert.

Isn't it safer to learn and understand how to use, say, AES algorithm as it is
provided as a part of Java? There is a few important config choices, but still
it looks easier than analyzing someone's libsodium port?

~~~
djsumdog
Honestly on Java, I would stick to Bouncy Castle. It's tried and tested, has
regular releases, good documentation and is regularly maintained.

~~~
floatboth
It's not equivalent in any way. Bouncy Castle is a kitchen sink library that
provides everything _except_ for a high-level, modern construction based,
idiot proof secret_box/crypto_box/crypto_sign API.

------
jupp0r
The article makes good points against rolling your own crypto. Is there
anything in there that can’t be solved by implementing it properly in a
library? Openssl works fine with RSA+TLS. Isn’t the lesson learned from this
that we need higher abstraction level (foolproof) APIs for our crypto
libraries rather than not use RSA?

~~~
dagenix
It's still slow and the keys are large. RSA isn't supported by TLS 1.3, so I
think a blanket statement that it works with TLS is missing a major caveat.

~~~
brohee
Setting up the session key using RSA encryption isn't supported in TLS1.3.
Authenticating with RSA signature sure is, and is the most common case...

~~~
dagenix
Fair enough, I was wrong there - RSA is still used for some things in TLS 1.3.
However, I stand by my point that there are downsides to RSA and that its
misleading to say "RSA + TLS is fine" when TLS 1.3 actively reduced its use of
RSA.

------
nailer
As someone involved in the PKI ecosystem, the biggest thing stopping ECC from
being adopted widely is:

\- AWS, which has incomplete ECC support
[https://docs.aws.amazon.com/elasticloadbalancing/latest/appl...](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-
https-listener.html)

> ACM supports RSA certificates with a 4096 key length and EC certificates.
> However, you cannot install these certificates on your load balancer through
> integration with ACM.

\- Heroku, which is still RSA only
[https://devcenter.heroku.com/articles/keys](https://devcenter.heroku.com/articles/keys)

Edit: not sure why the downmod so I've added references.

~~~
lvh
Fortunately many of the problems associated with RSA are less worrisome when
they're used in a PKI context, where realistically the BRs (or at least CA
praxis), together with the limited set of highly audited clients (browsers,
mostly) prevents the worst from happening.

~~~
nailer
There's still the weak performance of RSA though, especially on mobile
devices.

------
jesseryoung
Note: I am not a cryptographer nor a security developer but I am fascinated by
security and crypto.

I was all onboard with this articles premise, that good crypto is hard to
understand and RSA requires you to make choices about crypto that can easily
you screw things up.

Then I read the "So what should you use instead?" section: > "Developers could
theoretically build an ECC implementation with terrible parameters and fail to
check for things like invalid curve points, but they tend to not do this."

Is this not exactly the authors complaint about RSA? Granted there's fewer
places to screw up, but still, you're required to specify a parameter that
most developers typically don't understand the ramifications of.

~~~
lvh
The article also tells you to use libsodium, which makes safe cryptographic
choices.

(It's absolutely true that ECC can be as much of a footgun, e.g. non-random-k
ECDSA is worse than RSA PKCSv15. But the real takeaway is to use something
that's already set for security, like libsodium.)

~~~
cryptonector
Well, yes, but that's why we have ed25519 and such. ECDSA is a footgun.

------
dmitryminkovsky
> Developers have even used e = 1, which doesn’t actually encrypt the
> plaintext

Ouch

------
mcnichol
The video should definitely be watched.

A little more revealing about the playfulness this team is addressing the
issue, although still filling it in with their strong opinions and data.

The article came across heavy handed which (I feel) distracted from some
really good points.

------
korethr
I would love to eliminate RSA from the environments I am responsible for, and
replace it with something using Curve25519. However, one place I see RSA still
in use is in TLS certificates. Using Curve25519 in TLSv1.3 is great, but the
use of RSA-signed certs in the beginning of setting up that TLS connection
still strikes me as a weak link.

AFAICT, CA vendors don't offer cert signing in anything other than RSA at
present. Is there any motion to getting Curve25519 replacing RSA in the CA
cert system for TLS or code signing, or are we gonna be stuck with RSA for
certs for the next decade?

------
xaduha
> More concretely, that means if the person sitting next to me at work uses a
> smartcard granting them access to private documents, and they leave it on
> their desk during lunch, I can clone the smartcard and give myself access to
> all their sensitive files.

I'm very skeptical that this is actually possible with proper Javacards. In
any case you shouldn't leave your smartcard lying around. And furthermore what
kind of system uses RSA for document/disk encryption?

~~~
LIV2
Indeed the whole point of smartcards are that they're portable HSM's, you
can't simply clone a smartcard. You'd even need the pincode if you stole one
and would have to use it before it was noticed/revoked.

Presumably there are some organisations that use smart cards for EFS
encryption in windows but not sure if BitLocker supports it

~~~
xaduha
Bitlocker supports smartcards just fine (gotta set SelfSignedCertificates and
CertificateOID though).

I don't know much about encryption as a whole, but I have some inkling about
smartcards and this makes me suspect this whole article as FUD.

------
xrd
On a related note: I was recently reviewing the web crypto API and I was
surprised to see that only RSA works for encrypting/decrypting data. They do
offer support for ECDSA to sign and verify messages, but not encrypt data
using public keys with elliptic curves. Is there a reason for this?

For example: encryption: [https://developer.mozilla.org/en-
US/docs/Web/API/SubtleCrypt...](https://developer.mozilla.org/en-
US/docs/Web/API/SubtleCrypto/encrypt#Parameters)

Note that ECDSA is missing.

But, for signing: [https://developer.mozilla.org/en-
US/docs/Web/API/SubtleCrypt...](https://developer.mozilla.org/en-
US/docs/Web/API/SubtleCrypto/sign#Parameters)

Here, ECDSA is an option.

Why the difference?

It means you cannot use your web browser crypto to interact with the majority
of blockchains (like Ethereum).

Is there a good reason why support inside your browser for signing is
available with ECDSA but not encryption?

Is this a patent or IP issue, or perhaps a political issue.

I always thought one reason for not using RSA was that you never know if there
are backdoors the US government has installed, but this article makes it sound
technically poor as well.

~~~
tptacek
You don't normally encrypt with ECC. You use it to establish a symmetric key,
and encrypt with that. Look for WebCrypto examples for ECDH.

In fact, the ability to encrypt directly with RSA is probably a bug, not a
feature. There are too many ways to do it catastrophically wrong, and it
almost guarantees cryptosystems without forward secrecy.

(WebCrypto isn't great and I'd avoid it, but this isn't why).

~~~
xrd
Thanks, this is very clarifying.

Do you have a link to a discussion on why WebCrypto isn't great? More
specifically, are you saying there is no real good way to do encryption with
WebCrypto, or is it that it is too easy to do it wrong?

~~~
tptacek
It doesn't address the core problem with browser encryption, which is that
trust is inevitably rooted in the servers that deliver your content; WebCrypto
bakes more of the "guts" of crypto primitives into the browser, where they
don't have to be remotely programmed through Javascript, but the "joinery" is
still content-controlled Javascript and is more than flexible enough to allow
a malicious server to (very) surreptitiously exfiltrate secrets.

It can make some sense in extensions, or in situations where client-side
cryptography is more an interoperability or offloading concern than an end-to-
end security concern. But ultimately, it's misused more than it's used well.

------
obtino
Kind of off-topic, but why doesn't their site
[https://trailofbits.com/](https://trailofbits.com/) have their certificate
configured correctly? I know that their main site is
[https://www.trailofbits.com](https://www.trailofbits.com) but I didn't expect
their other record to be configured incorrectly.

~~~
dguido
It's a limitation of Github Pages, which we use for securely hosting a static-
content-only website.

------
AlEinstein
Well that title made me click on it and now I’ve bookmarked that page in case
I ever feel the urge to implement my own crypto using RSA. Or at all for that
matter.

~~~
robmccoll
I think if you're interested in learning about the foundations and basic
theory of asymmetric crypto systems, implementing your own RSA is a fun
weekend project. Just never use that implementation or suddenly think "now I
can write my own crypto for everything!" And also strongly consider using
anything other than RSA for real work.

~~~
buildzr
Honestly, I think your time would be better spent learning about different
cryptographic primitives,

\- Hash functions

\- Key derivation functions

\- Public key cryptography

\- Block ciphers

\- Stream ciphers

\- CSPRNGs

Understanding these primitives means you'll know what cryptographic news
means, it means you'll understand how things like NaCl, TLS or the NOISE
protocol are constructed under the hood, it means understanding how things
like proof of work functions and cryptocurrencies work will be much easier.

While I would never recommend constructing your own protocol based on these,
having the understanding of how they work can give you a good idea of some of
the nuances and risks associated with them and help you understand what it
really means when they get broken.

------
m90
Things like this make me phrase the following question (which I never see
answered): if crypto is so incredibly hard - N.B.: I do think it actually is
very hard myself - what is a run-off-the-mill developer to do? Shouldn't I
even try to build a secure application using what is out there, even if it has
possible attack vectors? If I get it 98% right, isn't this a win for users
already?

------
monkeynotes
TIL that the NSA designed SHA and there is at least a chance they
implementation of the elliptic curve has a back-door[1]

[1] [https://arstechnica.com/information-
technology/2014/01/how-t...](https://arstechnica.com/information-
technology/2014/01/how-the-nsa-may-have-put-a-backdoor-in-rsas-cryptography-a-
technical-primer/)

~~~
AaronFriel
The NIST and NSA didn't have a hand in deriving Curve 25519, which was created
by a very well trusted cryptographer Daniel J. Bernstein. One of the goals of
Curve 25519, IIRC, was to use parameters chosen from a handful of mathematical
constants as seeds, as opposed to black box constants which could be chosen by
an attacker with advanced cryptographic knowledge. (e.g.: the largest employer
of mathematicians in the country, the NSA.)

------
OJFord
Given that 'RSA' is derived from real people's initials, the title seems even
more unnecessarily unsavoury than it anyway is.

Can we change it at least here? 'RSA is easy to get wrong; stop using it'
seems harmless, and better describes the content anyway.

~~~
TravHatesMe
I agree with you. Putting expletives in titles is immature. Reminds me of
teenage years, when people overused swear words and thought they were so cool
and edgy. "fuck this" and "fuck that" just sounds childish when speaking about
something technical or academic.

~~~
arendtio
Actually, I found the old title ('Fuck RSA') expressed an extreme emotion. The
new title doesn't transport any emotions ('RSA is a fragile cryptosystem').

Given that the point of the article is that something has to change, I wonder
if that old title wasn't the more appropriate and expressive one.

But hey, who cares...

~~~
TravHatesMe
I see your point but I think it is a matter of professionalism. If you're
going to critique something technical and you want to be taken seriously then
it is best to remove (or reduce) emotion from the equation.

In my opinion introducing swearing/emotion to an argument weakens it,
regardless of its validity.

------
jason0597
It seems to me that this blog post is mostly about parameter choosing and this
criticism could just as easily be applied to AES (there are lots of pitfalls
there too), or really to any cryptography algorithm.

~~~
tptacek
There definitely are similar pitfalls in AES, and nobody should be encrypting
with "AES"; they should be using something like AES-GCM-SIV (or, to extend the
analogy with the post, Chapoly, which has the virtue of _only_ being usable in
a relatively secure fashion). More cryptography has been broken by casual
invocation of AES than has been broken by serious attempts to deploy custom
ciphers.

------
FraKtus
The article conclusion is that picking the wrong parameters (prime numbers, e)
leads to being vulnerable to many attacks.

Are there tools that will assist in choosing or testing those parameters?

~~~
Analemma_
Probably, but why bother? The article explains what you should be doing
instead.

~~~
FraKtus
The article does not say RSA is wrong, but that picking the right parameters
is too tricky.

That's why a script/tool validating against the known attacks mays be helpful.

------
e40
What does this mean for ssh key generation?

~~~
kpcyrd
ssh-keygen -t ed25519

------
jvanderbot
So, is ssh-keygen security theater?

~~~
castis
not if you use a different type, something like -t ecdsa

~~~
jvanderbot
Following my eldritch training in the dark arts: I googled then found a
stackexchange answer on this topic [1]

1\. [https://security.stackexchange.com/questions/143442/what-
are...](https://security.stackexchange.com/questions/143442/what-are-ssh-
keygen-best-practices#144044))

------
SamuelAdams
> When e = 3, or a similarly small number, many things can go wrong. Low
> public exponents often combine with other common mistakes to either allow an
> attacker to decrypt specific ciphertexts or factor N. For instance, the
> Franklin-Reiter attack allows a malicious party to decrypt two messages that
> are related by a known, fixed distance.

Surely anyone who studied a single textbook about crypto knows this? Or anyone
who bothered to do a bit of reading about the crypto library they are using?

After a bit of searching, apparently this is a big issue. Search for
"RSA.gen_key" on any of the following pages:

Exhibit
A:[https://github.com/const586/freestream/blob/ee95c78e85719caa...](https://github.com/const586/freestream/blob/ee95c78e85719caad9f2f421b60a100aa463a0a1/freestream/Core/LiveSourceAuthConfig.py)

Exhibit
B:[https://github.com/lixmgl/Intern_OpenStack_Swift/blob/40c241...](https://github.com/lixmgl/Intern_OpenStack_Swift/blob/40c241319c6b9a7aabacc9d927486864d13b8055/trunk/salt/salt/crypt.py)

Exhibit
C:[https://github.com/egbertbouman/tribler-g/blob/14e5c4eaf66f5...](https://github.com/egbertbouman/tribler-g/blob/14e5c4eaf66f50d5ea54aa8f30ddc8a4a2017504/Tribler/Core/LiveSourceAuthConfig.py)

Exhibit
D:[https://github.com/wizzard/dm-p2player/blob/fb3a89aedc0a2374...](https://github.com/wizzard/dm-p2player/blob/fb3a89aedc0a23741875c454468db9c2fb84e147/Tribler/Core/LiveSourceAuthConfig.py)

Exhibit
E:[https://github.com/mimianddaniel/booksalt/blob/248c2349fd9a6...](https://github.com/mimianddaniel/booksalt/blob/248c2349fd9a6edc30d48d11673ab72bed4583ce/salt/crypt.py)

Exhibit F:[https://github.com/GrandPaRPi/p2ptv-
pi/blob/6f79c00f9055a376...](https://github.com/GrandPaRPi/p2ptv-
pi/blob/6f79c00f9055a3763ddfe1dc41e14d2cb533f4c3/acestream/ACEStream/Core/LiveSourceAuthConfig.py)

Exhibit G:[https://github.com/C6SUMMER/allinclusive-kodi-
pi/blob/8baf24...](https://github.com/C6SUMMER/allinclusive-kodi-
pi/blob/8baf247c79526849c640c6e56ca57a708a65bd11/.kodi/userdata/addon_data/plugin.video.p2p-streams/acestream/ace/ACEStream/Core/LiveSourceAuthConfig.py)

~~~
djsumdog
Ugh, and they're all using M2Crypto, which is terrible and broken anyway. I
had huge issues with encrypting things with it and being able to decrypt or
verify signatures with other libraries.

I switched to PyPi RSA. It took a little bit of digging, but it seems to use a
sane exponent by default:

[https://github.com/sybrenstuvel/python-
rsa/blob/11bf33264c62...](https://github.com/sybrenstuvel/python-
rsa/blob/11bf33264c620684fcae6c248df30c0a444babdf/rsa/key.py#L48)

~~~
lvh
There's a reason we're telling you to use libsodium box instead: even if pyrsa
sets a reasonable exponent, for example, it's still a separate pure Python
implementation (with fewer eyeballs and almost certainly more side channel
vulnerabilities), and still uses PKCSv15, exposing you to Bb98-style padding
oracle attacks.

------
Hitton
Well the article is certainly informative why not to self-implement RSA, but
the conclusion to just use libsodium seems stupid. I don't really know
cryptography, but I'm sure there are libraries that implement RSA correctly
and could be easily used instead.

~~~
tabletopneedle
Even if you were using a perfect implementation of RSA-OAEP, it would still be
less secure than Diffie-Hellman over Curve25519 (called X25519) or Curve448
(called X448).

This is because RSA lacks forward secrecy: If the private RSA key is stolen,
it can be used to retrospectively decrypt all past communication.

Also X448 provides the equivalent security of ~15000-bit RSA with a fraction
of the key size, and key generation takes milliseconds instead of minutes.

tl;dr

For key exchange, use X25519 or X448.

For digital signatures, use Curve25519-based ed25519 signatures.

For authenticating communication, use authenticating encryption like
ChaCha20-Poly1305 or Salsa20-Poly1305 or AES256-GCM.

For hash function, use Blake2 or SHA3-256 or SHA256.

~~~
Hitton
As I said, I don't really know much about, but this is bullshit.

RSA lacks perfect forward secrecy is same as saying that ECDH lacks perfect
forward secrecy. Both is true, and both can be used with ephemeral keys, which
provide forward secrecy to both (and therefore must use other way to
authenticate). Claiming that it's somehow RSA's problem while willfully
pretending that it doesn't concern elliptic curve cryptography is very
dishonest.

------
miguelmota
What's the TLDR for a non cryptographer that simply wants to encrypt messages
for sending? The post was over my head

~~~
lvh
We did a blog post! You might like it.
[https://latacora.micro.blog/2018/04/03/cryptographic-
right-a...](https://latacora.micro.blog/2018/04/03/cryptographic-right-
answers.html)

------
tinus_hn
R, S and A are real people (Rivest, Shamir and Adleman) and I don’t think it
is appropriate to say fuck them, even if the system they designed 40 years ago
doesn’t hold up to today’s standards.

~~~
lou1306
The title is clearly directed at the cryptosystem, not its authors.

~~~
cwyers
I mean, the article includes a YouTube video of a presentation where the
screengrab is a picture of Ron Rivest with his eyes glowing red, I'm not quite
as sure as you that's clear.

~~~
gnulinux
I'm not following, it's very clearly humorous. Red glowing eyes is a very
popular internet meme. E.g. recently people use that for Game of Thrones
memes, or political memes, or for animals etc (like that glowing eye seagull
meme).

------
romaaeterna
TLDR: Cutting out all the fluff about developers screwing themselves when they
try to roll their own solutions, his argument is that it's the necessity of
padding that makes RSA fundamentally insecure, and we should use ECC instead.

It's not a new viewpoint, and there are arguments for and against.

------
Taniwha
In New Zealand the RSA is the equivalent of the VFW, they spent most of my
teenage years trying to get people my age drafted and sent to fight in
Vietnam, apparently it would have made us men - so yeah fuck 'em

------
someguydave
The blog fails to explain why trailofbits are recommending ECC over RSA when
the NSA is now recommending not using ECC and instead recommends RSA.
[https://eprint.iacr.org/2015/1018.pdf](https://eprint.iacr.org/2015/1018.pdf)

~~~
jcranberry
The article you linked is very specifically talking about quantum computing.

 _The NSA seemed to be suggesting that practical quantum computers were coming
so soon that people who had not yet upgraded from RSA to ECC should not bother
to do so, and instead should save their money for the future upgrade to post-
quantum protocols. Shortly thereafter, the NSA released a revised version in
response to numerous queries and requests for clarification. The new wording
was even more explicit in its negative tone on the continuing use of ECC:
“...elliptic curve cryptography is not the long term solution many once hoped
it would be. Thus, we have been obligated to update our strategy.” Although
other parts of the statement assured the public that ECC was still recommended
during the time before the advent of practical quantum computers, the overall
impression was inescapable that the NSA was distancing itself from ECC._

~~~
someguydave
That's one of many possible interpretations.

------
jshowa3
From what I read, the NSA has not recommended most crypto protocols due to
quantum computing. However, they still recommend having a large key size as
being one of the biggest factors in having strong crypto. So why not use RSA
with larger keys? Granted, I'm not an expert either. Let me put a source
against this so people don't state the obvious about large enough quantum
computers not existing and such:
[http://blog.bettercrypto.com/?p=1917](http://blog.bettercrypto.com/?p=1917)

~~~
lvh
You would need an obscenely large key size to make RSA post-quantum secure.
The speedup a quantum computer gives you isn't some linear factor. People have
explored what that would look like:
[https://cr.yp.to/papers/pqrsa-20170419.pdf](https://cr.yp.to/papers/pqrsa-20170419.pdf)

But more importantly:

1\. No, quantum computers that big don't exist.

2\. If they are somewhat practical, you really want perfect forward secrecy so
they at least have to break a classically hard problem _every time_, which is
unlikely with home-rolled RSA systems.

3\. If you do care about post-quantum KEX (because your information needs to
be secret for longer than you can count on quantum computers not being
practical), we have faster alternatives, like SIDH.

~~~
CiPHPerCoder
3a. Doing ECDH (e.g. over Curve25519) and SIDH (or SIKE, the NIST flavor of
SIDH) and hashing both together (e.g. with BLAKE2) is a sensible insurance
policy against breakthrough attacks against SIDH.

------
deathanatos
Because it's supported, not yet broken, and not from a government agency whose
loyalty to its people is questionable.

The EC curves from NIST[1]:

> _cryptography experts have also expressed concern over the security of the
> NIST recommended elliptic curves_

C.f. [this comment and the thread of comments nearby][2], where this, and some
other concerns, are discussed. But the concerns about hidden numbers from a
government agency in a world where we know what we know from Snowden just
kills the NIST curves for me.

I'd happily use Curve25519/Ed25519 over RSA, _if it is supported_ , but that's
the trick. AFAIK, TLS 1.3 supports it, but the CA/B forum does _not_ , meaning
CAs won't issue such certificates, since they're bound by those rules. ACME,
AFIAK, also does not support Ed25519 yet, though I believe there are plans in
motion to do so.

SSH is about the happiest story: it's well supported by OpenSSH.

Aside from that, as a dev, I try to let well-known TLS libraries handle the
encryption for me, as much as possible. (But even that is hard; many
tools/libraries make it incredibly easy to generate invalid certs, short keys,
fail to correctly validate a supplied certificate, etc.) Or push it over SSH.

[1]: [https://en.wikipedia.org/wiki/Elliptic-
curve_cryptography](https://en.wikipedia.org/wiki/Elliptic-curve_cryptography)

[2]:
[https://news.ycombinator.com/item?id=20382720](https://news.ycombinator.com/item?id=20382720)

