Show HN: Debut – a retro terminal PowerPoint clone - <AUTHOR> https://github.com/tombasche/debut
As part of work I was tasked with doing a presentation on a part of the Agile Manifesto, so as a way to make it interesting I initially decided to do it as an animated CLI app.
Then I remembered curses existed! And a weekend later I ended up with a mini-framework for doing your own presentations in the terminal complete with borders, colours and keyboard interaction.
It's also 100% Python with no external dependencies, so feel free to clone it and run it as the readme states. <comment><USER2> You should add screenshots/gifs so that people can see what it does

<comment><AUTHOR> good point! will do now</comment></comment>


RSA is a fragile cryptosystem - <AUTHOR> https://blog.trailofbits.com/2019/07/08/fuck-rsa/ <comment><USER3> 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)

<comment><USER4> 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.

<comment><USER5> > 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.

<comment><USER6> Do you have ideas for a more secure platform than this that the average person can actually use?

</comment></comment></comment></comment><comment><USER7> 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)

<comment><USER8> While the rule for devs is, "never roll your own crypto", what is the authoritative resource for what we _should_ use?

<comment><USER9> 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.

<comment> 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.

<comment><USER9> 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.

<comment> loup-vaillant Oops, missed that, sorry.

</comment></comment></comment></comment></comment></comment><comment><USER10> 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.

<comment><USER11> 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.

<comment><USER12> 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.

</comment></comment></comment><comment><USER13> 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.

<comment><USER14> 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.

<comment><USER13> So, to be Devil's Advocate, does libsodium also provide an RSA implementation?

<comment><USER15> 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.

</comment></comment></comment></comment><comment><USER16> 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)

<comment><USER17> > 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)

<comment><USER16> 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.

<comment><USER7> 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.

<comment><USER16> 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)

<comment><USER7> 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.

<comment><USER16> 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.

<comment><USER7> 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!)

<comment><USER16> Alright I will do it :D

<comment><USER7> 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.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER18> 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/)

<comment><USER19> 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.

<comment><USER18> > _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.

<comment><USER20> 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)

<comment><USER21> 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).

</comment></comment></comment></comment></comment><comment><USER22> 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.

<comment><USER23> 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.

<comment><USER24> > 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.

<comment><USER25> Any reference to their work?

<comment><USER24> [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/)

</comment></comment></comment></comment></comment><comment><USER26> 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/)

<comment><USER27> 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.

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

<comment><USER26> 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)

<comment><USER28> 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?

<comment><USER7> 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.

</comment></comment></comment></comment></comment></comment><comment><USER29> To anybody put off by the clickbaity title, as I initially was — the article is actually informative and well-written.

<comment><USER30> Same here, especially considering the 3 men are alive and may read the title it's a bit rude.

<comment><USER31> 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)

</comment></comment></comment><comment><USER32> > 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/)

<comment><USER14> 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.

<comment><USER15> 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.

</comment></comment></comment><comment><USER33> 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.

<comment> 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.)

<comment><USER33> 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.

</comment></comment></comment><comment><USER34> 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)

</comment><comment><USER35> > 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.

<comment><USER14> 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)

<comment><USER4> 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.

<comment><USER14> 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)

<comment><USER36> 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.

</comment></comment></comment></comment></comment><comment><USER37> > 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.

<comment><USER26> > 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 - <USER2> 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.

</comment></comment><comment><USER38> 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.

<comment><USER39> 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.

<comment><USER40> 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?

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

<comment><USER39> 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.

</comment></comment></comment></comment></comment><comment><USER42> 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?

<comment><USER43> 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.

<comment><USER44> 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...

<comment><USER43> 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.

</comment></comment></comment></comment><comment><USER45> 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.

<comment><USER14> 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.

<comment><USER45> There's still the weak performance of RSA though, especially on mobile devices.

</comment></comment></comment><comment><USER46> 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.

<comment><USER14> 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.)

<comment><USER47> Well, yes, but that's why we have ed25519 and such. ECDSA is a footgun.

</comment></comment></comment><comment><USER48> > Developers have even used e = 1, which doesn't actually encrypt the > plaintext

Ouch

</comment><comment><USER49> 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.

</comment><comment><USER50> 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?

</comment><comment><USER51> > 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?

<comment><USER52> 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

<comment><USER51> 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.

</comment></comment></comment><comment><USER53> 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.

<comment><USER7> 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).

<comment><USER53> 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?

<comment><USER7> 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.

</comment></comment></comment></comment><comment><USER54> 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.

<comment><USER55> It's a limitation of Github Pages, which we use for securely hosting a static- content-only website.

</comment></comment><comment><USER56> 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.

<comment><USER57> 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.

<comment><USER58> 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.

</comment></comment></comment><comment><USER59> 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?

</comment><comment><USER28> 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/)

<comment><USER60> 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.)

</comment></comment><comment><USER31> 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.

<comment><USER61> 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.

<comment><USER62> 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...

<comment><USER61> 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.

</comment></comment></comment></comment><comment><USER63> 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.

<comment><USER7> 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.

</comment></comment><comment><USER64> 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?

<comment><USER65> Probably, but why bother? The article explains what you should be doing instead.

<comment><USER64> 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.

</comment></comment></comment><comment><USER66> What does this mean for ssh key generation?

<comment><USER67> ssh-keygen -t ed25519

</comment></comment><comment><USER68> So, is ssh-keygen security theater?

<comment><USER69> not if you use a different type, something like -t ecdsa

<comment><USER68> 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))

</comment></comment></comment><comment><USER70> > 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)

<comment><USER41> 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)

<comment><USER14> 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.

</comment></comment></comment><comment><USER71> 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.

<comment><USER15> 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.

<comment><USER71> 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.

</comment></comment></comment><comment><USER72> What's the TLDR for a non cryptographer that simply wants to encrypt messages for sending? The post was over my head

<comment><USER14> 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)

</comment></comment><comment><USER73> 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.

<comment><USER74> The title is clearly directed at the cryptosystem, not its authors.

<comment><USER75> 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.

<comment><USER76> 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).

</comment></comment></comment></comment><comment><USER77> 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.

</comment><comment><USER78> 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

</comment><comment><USER79> 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)

<comment><USER80> 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._

<comment><USER79> That's one of many possible interpretations.

</comment></comment></comment><comment><USER81> 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)

<comment><USER14> 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.

<comment><USER82> 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.

</comment></comment></comment><comment><USER83> 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)</comment>


Ask HN: What do you think the biggest trends will be in 2015-2018? - <AUTHOR> Hey HN,<p>We review and read so many bits of technology that we forecast into the future. I was wondering what everyone thought - explicitly - about what will be happening over the next few years. <comment><USER2> Advertising as entertainment. Brand as identity. Testimonial as opinion. News/catastrophes as entertainment. Dating as a catalogue. Love as a service. Reproduction as a life goal.

These are already trends and will continue sickeningly in the near future. Anything targeting these new facts of life will do well, but at the cost of entrenching this millenial conceptual scheme.

<comment><USER3> _" Reproduction as a life goal"_

Rate dropping in developed countries though? Did you mean consumerism?

<comment><USER4> Probably referring to the idea of having children becoming more "trendy" amongst young people ... whereas previously having a baby was seen as not "cool," i.e. something boring people settle down and do, some "trendsetters / influencers / celebrities" have been having kids and making it seem desirable.

I need a shower after writing this post.

<comment><USER5> I haven't seen this trend, really. Most of my friends want to wait a fair while before having kids.

</comment></comment></comment></comment><comment><USER6> I think it will (or at least should) become easier to meet people online with similar interests - and I'm not talking about dating. Given that there are 2 billion people on the Internet, this shouldn't really be a problem. Yet, social media sites like Facebook limit us, for the most part, to people we know in real life.

With that said, I think we should be careful of where our collective conscious takes us.

<comment><USER7> To expand on this a bit, for better or worse, most of human's collective knowledge is still locked up in people head, be it cutting edge researching knowledge, industrial mainstream knowledge, or obscure hobby one. Notice that how in programming, you only got knowledge of the very basic, and then a glimpse of knowledge on the very high end (multiple distributed huge data center etc.). There is a huge swath of missing information for anything in the middle. That's partly why experience is relevant: there are certain things you just can't know until you meet someone who tell you about it.

There are certain attempts to fix the knowledge gap issue, namely Q&A sites, as well as places where people can share their knowledge. But Q&A doesn't seem to work for most things beyond the basics: there isn't an objective answer, as everything is a trade off, and questions aren't as good as a conversation would be for context and everything else. Even for Quora, where the questions and answers can be subjective, there is an implicit requirement that both of them have to be self-contained (otherwise, it just doesn't make sense). It's evident to see in the "naive" question on Quora: sometimes you can tell the asker knows a bit and wanted to ask for more, but the resulting questions just come out very awkward.

And finally, I think that people are more reluctant to just _share their knowledge_ (directed at no one), for a variety of reasons: it's actually hard to just write about things - there are a big gap between knowing something, and being able to write it down clearly, we mostly can't write a book, but everyone of you will have a thing or two to teach me regardless. It might seem wasteful (who would read this?), or it's just simply never come to our mind that's the knowledge is valuable - familiarity makes everything seems trivial. Most of those issues would not exists in a small group settings.

For a more concrete idea, think of a small but active mailing list, IRC channel, or subreddit, that's approximately the desirable result. If you can, make those mainstream, pretty please :-).

<comment><USER8> Maybe there's a market or an app for the 'Freelance Teacher', if there isn't already and I'm just ignorant.

One-on-One connectivity with a (self proclaimed?) subject matter expert, where the subject could be anything.

Things like Reddit and Quora exist, and Ask HN, how to wikis, guide web pages, etc. etc. but one issue I have with the forum style is that it doesn't foster a student-teacher / master-apprentice experience because there's always someone saying "no, that's wrong" \-- or something to that affect.

Connecting students with teachers, where 'student' means someone wanting to learn and 'teacher' means someone willing to share experience and knowledge.

Does such an app exist?

<comment><USER9> True, also the problem with things like Quora is you end up with dogma or regurgitation accumulating most of the upvotes, like hundreds of answers that say "if you're not paying for it, you are the product."

</comment></comment></comment></comment><comment><USER10> Shift in tech from full-time employment to contracting, working it's way down from the high-end specialties towards generalist programming. Tools and business services that make contracting easier to manage as a sole practitioner. Maybe, if we're lucky, new business systems (insurance?) that de-risks the contracting sales pipeline and utilization volatility.

</comment><comment><USER11> eSports. There was a large CS:GO/LoL/SC2 tournament last weekend, where CS:GO gathered over 1 million concurrent viewers during finals (last tournament had 460K!). While LoL has been a big player for a while, and probably continues to be in Asia, CS:GO is growing rapidly in the west.

<comment><USER12> It's worth noting that Counter-Strike has been around far longer than most games in eSports. But a few tweaks made in Global Offensive, such as more reliance on managing money/economy, made it as compelling to watch as games like LoL or SC2 because it's more than just watching dudes shooting at each other. Now it's getting more playtime in tournaments than ever.

</comment></comment><comment><USER13> VR games.

Smart watches.

Fitness devices. Millenium Generation are putting more money into fitness stuff and Under Armor just bought myfitnesspal app. Google released their own. Those things will amass a good amount of big data for companies so I see that becoming big.

Electric cars. Tesla really pushed it. BMW and Nissan is embracing it. All the hyper cars are moving to hybrid right now. It's easy to see where the direction is going.

Machine learning/ Data science. It's going to grow. As for the tech stack I'm not entirely sure, but I know Spark will be vying for some market share if they keep the momentum up but Flink can be an underdog. Eventually, we might get a good realtime framework/software instead of batches and micro batches.

Scala is going to go down as people are going to see how complicated the language is really. I've seen few move to Clojure. That's the trend I'm predicting for this language.

Autonomous cars ain't going to be here by 2018.

Things I think will not be a trend:

I wouldn't add google glasses type of thing because I don't think the technology is there to make it last more than an hour or two really.

Open Source Graph data base. Titan is going to going to die and there won't be any promising open source one in the horizon and I'm sadden by this.

Front side js rendering is going to be still fighting for dominance. React, angular, ember, etc... It'll have massive code base shift with ECMA 6 and nothing will settle and everything is still wild wild west in this frontier.

<comment><USER14> >Scala is going to go down as people are going to see how complicated the language is really. I've seen few move to Clojure. That's the trend I'm predicting for this language.

Interesting prediction. What do you think will be the fate of other JVM languages?

>Open Source Graph data base. Titan is going to going to die and there won't be any promising open source one in the horizon and I'm sadden by this.

Why not OrientDB?

</comment></comment><comment><USER15> Consumer health testing. Tech has advanced to the point where a tiny sample can be used to look for all sorts of chemical markers. This will lead to people getting tests done much more frequently than currently, and being informed on a running basis.

Had a chat with a founder about it today.

</comment><comment><USER16> Microinvesting - ordinary people able to invest in a share of company (startup or established but unfloated) or land in an easy and realistic way. Conversely any company, new, small or large can attract money this way. Caveat emptor!

Middle finger to the city - smart people use big cities for networking and to meet people, then start up their businesses in a town miles away and say fuck you to those overheads. Tech could facilitate this. Previously unknown small towns around the world become the next silicon valleys.

<comment><USER10> I have a blog post I've been playing with for about 4 months now about how broader, more diverse investor communities for startups is likely to backfire. The right people to be investing in them is probably the group that's doing it now. They could be smarter, but it's unclear to me that there should be more of them.

What set me off was the Startup Podcast episode on equity crowdfunding platforms.

</comment></comment><comment><USER17> Here are some of mine -

Emergence of VR and related technologies (it's a trend in this thread as well)

Failing startups in the hundreds, who've exhausted their funding by then.

Smartwatches/health bands

Beginning or mobile phone stagnancy

4K TVs and displays may start picking up

</comment><comment><USER18> Things that we think of as programming and engineering will increasingly trickle down as digestible packages sold to masses. As has been happening for decades.

</comment><comment><USER19> Internet of things seems to be one of the buzzwords for nowdays, with wearables and smart watches and everything controlling your home

<comment><USER20> Internet of Things will have somehow the same fate as IPv6. Some will adopt it, manufacturers will push for it, but nobody will care about it. It will be a niche for a few years before the market is ready for it.

</comment></comment><comment><USER21> No one can predict this, but in my opinion (in no particular order):

1) Health (e.g. theranos)

2) Artificial Intelligence

3) Virtual Reality

4) Internet of things

</comment><comment><USER22> VR in particular gaming

Podcasting will get even bigger

Wearables

eSports</comment>


Digg censors saltwater - <AUTHOR> http://digg.com/news/science/architect_proposes_tower_that_uses_saltwater_hot_sun_to_grow_its_own_skin

<comment><USER2> Ah, the clbuttic mistake.

<comment><USER3> How much of a performance hit would they really take if they included word boundary metacharacters in their filtering regexes? Is this something people have benchmarked? Can anyone make a reasonable guess?

(I'm honestly curious, and wondering if this isn't an engineering trade-off as opposed to just a dumb mistake.)</comment></comment>


Boom has orders for 76 of its future supersonic passenger jets - <AUTHOR> https://techcrunch.com/2017/06/20/boom-has-orders-for-76-of-its-future-supersonic-passenger-jets/ <comment><USER2> I love that a small company is and can challenge the big guys faster flight.

For risks, aside from generally achieving the promised goals is there a big risk Boeing or Airbus copy this and have better sale channels to take over this as soon as the concept is proven. Boom development seems to have happened really quickly. I imagine the resources of the bigger companies can throw with their fiance and general engineer/production systems at this quickly if boom proves the concept.

<comment><USER3> For the end consumer in this realm there is only victory, regardless of what happens to Boom. If 4 hour transatlantic flights become a viable option again I frankly don't care who succeeded or failed to get to that point.

I do enjoy watching companies like Boom, because this is the kind of underdog chutzpah that the word "courage" is supposed to describe.

<comment><USER4> 4 hours combined with airport waits ends up becoming something like 6 hours right?

Is there a big difference in practicality between 6 hours and 10 hours? Feels like you still lose the day to travel for the most part.

<comment><USER5> If you have your routine down, fly during the work week (most business travel), and have precheck you can pretty reliably have your wait down to 45 minutes. I fly a lot and usually breeze through the airport.

<comment><USER4> Is that possible for international flights? My impression is that you're kinda forced to get there super early. But maybe I'm doing this wrong.

I'm also used to doing international flights from cities where the airport is super far away. For example Charles De Gaulle is still a 45 minute train ride away from a lot of useful stuff. DFW's a bit out there too.

The dream is obstensibly Shinkansen-style "get there in the morning, leave in the evening and be back before bedtime" flows. Is that doable with smaller international flights already?

<comment><USER6> Depends on the airport. 100% possible at LCY, which is also only 20m from Canary Wharf.

<comment><USER3> It really does. I can reasonably go to Houston Hobby or Austin Bergstrom and with Precheck expect to be at the gate within 15 minutes of when I walked in the door (assuming no checked baggage). DFW or O'Hare or George Bush is an entirely different ballgame.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> There were over 100 orders for the Concorde in the 1960s and when the first prototype was flying this already went down to 74, but most of them were canceled, so only 14 commercial planes were ever build. I would be sceptical about this project.

<comment><USER8> I once read they had serious overheating problems.

<comment><USER9> They had serious problems, period.

As you say, one major problem was that the aircraft skin got really hot from friction - hot enough that they had to build it out of a special titanium alloy, and paint it with heat resistant paint - but that was inadequate. Due to the heating and cooling that occurred each cycle the entire airframe would expand and contract very substantially - over repeat cycles this lead to metal fatigue, and would lead to failure but not for incessant expensive maintenance. For an idea of how much the thing expands, on the final flight of the model now at RNAS Yeovilton, the flight engineer stuck his cap between the engineering console and the bulkhead, where it remains sandwiched by pressure today.

Apart from the thermal issues, the entire craft suffered from "so cutting edge it barely works" all over, from special tyre compounds to window seals to the famous drop nose. It was an engineering marvel and nightmare, in one improbable package. It's frankly surprising it even ever existed.

I think the major difference will be that Concorde was a space age plane built with 60's tech, and these will Be space age planes built with space age tech.

<comment><USER10> > space age plane built with 60's tech

Wasn't the 60's the space age, though? :)

<comment><USER8> Was it?

I have the feeling much of the tech of the last century was too much for the people living at the time.

Yes, they found out about fusion and fission, but there are no viable fusion reactors out there and even the fission ones are highly problematic.

Yes, they build super sonic planes but they barely held together or did cost a fortune.

Yes, the send people to space, but how many and at what price?

We even had super computers and main frames, but it took half a century to get this tech in every home AND then some time to get it in everyones pocket.

Last century was more of a industrial mass market thing. The stuff from the 1800 was finally available for the rest of us.

The whole high tech stuff was discovered at the time but it wasn't really usable, even if it was still used, see concord or fission based power plants.

On the other hand, the risk we took for the power plants was probably set off by getting electricity to everyone and allowing the industrial age tech to work more wide spread.

Anyway, I think we are in more of a space age now than we were back in the days.

<comment><USER11> Now just wait for 2 billion+ people to actually get working on our future problems. Say what you will about China and India industrializing, but if we manage to transition fast enough to renewables, having so many middle class people will have a huge impact on the world history, more than anyone is expecting right now, I think.

</comment></comment></comment></comment></comment></comment><comment><USER12> > these reservations include non-refundable down payments

Interesting that they forgot to say how large is the down payment

<comment><USER13> In absence of a specific number the only sane thing to assume is that it's way closer to $1 than to the cost of the plane. Such an easy and obvious marketing tactic.

<comment><USER14> Probably closer to $1 million than the cost of the plane as well, though. I can't imagine Delta putting down 10x $500 deposits or something.

<comment><USER15> There could also be terms and conditions that they only are committed if Boom deliver by so so and so date for so and so price.

</comment></comment></comment></comment><comment><USER16> I am typically quite skeptical about these kinds of products, but the phrase "non-refundable deposit" made me read on. I hope they pull it off!

</comment><comment><USER17> I wonder about noise concerns. The concorde only reached supersonic flight on the ocean, not on land because of the sonic boom.

<comment><USER18> In USA, all supersonic flight over land by civil aircraft has been prohibited by regulation introduced in March 1973. [0] Without changes in the legislation, airlines can only offer supersonic flights over the ocean.

[0] [https://www.faa.gov/about/office_org/headquarters_offices/ap...](https://www.faa.gov/about/office_org/headquarters_offices/apl/noise_emissions/supersonic_aircraft_noise/media/noise_policy_on_supersonics.pdf)

<comment><USER3> Not necessarily a dealbreaker. Concorde did ok with British airways flying out of NY. Assuming the rules don't change there are plenty of viable routes out of Houston, NY, and SFO.

<comment><USER19> Concorde was a British-French aircaft, so it was allowed to fly over the UK. If it had been American, it would have been banned instantly. It was horrifically noisy.

<comment><USER20> > It was horrifically noisy.

I saw it land/take off a handful of times as a kid. The noise was unlike anything else I've ever experienced - you could hear it many kilometers away and up close (on the airport boundary) you'd feel every internal cavity vibrating when it departed. As a child it was marvellous!

</comment></comment></comment></comment></comment><comment><USER21> Aerion, Boom, Gulfstream, HyperMach and more. It seems crowded for such a niche product with a lengthy, costly and uncertain development cycle.

</comment><comment><USER22> What I'm really curious about is how they're going to deal with radiation. At the required altitude your pilots and attendants can't do a normal routine. You'd get too high of a dosage, unless things are shielded. But that is heavier.

<comment><USER23> Extra radiation exposure is minor at those altitudes.

<comment><USER22> For passengers, yes. Workers, no.

The Concord had 12-15uSv/hr [1] (2-3x a long haul flight). The lower bound and best case, workers are fine. Upper bound and European (which are stricter than American, but we're talking international flights) standards are 1mSv (whole body) or 50mSv (effective to skin) [2]. So we're between 4166hrs/yr and 66.6hrs/yr working that would be allowed.

Because it is international they'd probably go with the lowest common denominator, at 1mSv/yr dosage allowed (50mSv/yr for American radiation workers, 150 for Astronauts). And we're just talking flight, not adding the nominal background radiation, which is going to reduce the number of hours even more.

So in short, no, the extra radiation exposure at those altitudes is not minor. It has to be considered if you are going to hire people to fly your plane and attend to your passengers. Airlines already consider radiation exposure. No one wants to do massive medical payouts 30 years from now.

[1] [http://aviationknowledge.wikidot.com/aviation:in-flight- heal...](http://aviationknowledge.wikidot.com/aviation:in-flight-health-cabin- radiation)

[2] [http://www.radioactivity.eu.com/site/pages/Doses_Limits.htm](http://www.radioactivity.eu.com/site/pages/Doses_Limits.htm)

Addendum: 1Sv in a year is a 5.5% increase of cancer over your entire lifetime. 1Sv in an hour will probably kill you.

<comment><USER24> The dose limits for radiation workers (which includes airline flight crews) is 20 mSv/yr. This is supported by the ICRP [1] and the EU [3].

British Airways carried out and published data from radiation monitoring of Concorde crews: "Supersonic transport (SST) flights The Concorde SST... was designed to fly at the... operating altitude of around 18 km (about 59 000 ft). Concern for potential hazards... led to monitoring equipment... being installed in all Concorde aircraft. Many data have been derived from this, including more than 20 years experience of the radiological environment. ...these flights indicate that the radiation exposure of Concorde flying crew is unlikely to exceed 6 mSv/y." [2]

I will also suggest the interested reader look into "radiation hormesis" and what data really exists to support the linear-no-threshold (LNT) model, or the idea that any amount of radiation raises risk, below certain dose rates. [https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2889502/](https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2889502/)

[1] [http://www.icrp.org/icrpaedia/limits.asp](http://www.icrp.org/icrpaedia/limits.asp) [2] [https://www.ncbi.nlm.nih.gov/pmc/articles/PMC1128520/pdf/oen...](https://www.ncbi.nlm.nih.gov/pmc/articles/PMC1128520/pdf/oenvmed00079-0063.pdf) [3] [http://eur-lex.europa.eu/legal- content/EN/TXT/PDF/?uri=OJ:L:...](http://eur-lex.europa.eu/legal- content/EN/TXT/PDF/?uri=OJ:L:2014:013:FULL&from=EN)

<comment><USER22> Thanks for that. I didn't see that paper when I was quick googling for Concord levels. That's not bad, 7.8hrs/day is the max (given the 7uSv/hr dosage they are estimating). So no flight crew is going to undergo that.

Though it still begs the question, is Boom going to get that. As I understand it, Concord had nickel-aluminum throughout its body, which has better shielding properties than CF. They are also introducing more flights. Transpolar flights means more dosages.

But given that paper I'm less concerned with the radiation dosages now. I'll still be interested to see what the data says when they start gathering it. We've also learned a lot more about radiation exposure, especially in flight since '96 [1][2]. And note that these values vary quite a lot.

The real interest here will be in solar storms. I also wouldn't be surprised if NASA straps detectors to those planes, if Boom becomes commercial. I'd be very interested to see that.

[1] [https://www.nasa.gov/topics/earth/features/AGU- NAIRAS.html](https://www.nasa.gov/topics/earth/features/AGU-NAIRAS.html)

[2] [https://www.nasa.gov/topics/aeronautics/features/airline- rad...](https://www.nasa.gov/topics/aeronautics/features/airline- radiation.html)

</comment></comment></comment></comment></comment><comment><USER25> I'm highly skeptical considering Boeing and Airbus haven't been able to make a supersonic plane. This is not software where a couple of smart guys can code something decent up over a pizza-fueled weekend.

<comment><USER26> Some skepticism is justified, sure, but at this point making supersonic aircraft isnt rocket science any more. It's a well understood problem domain and they are using well proven engines.

Even if it were rocket science Boeing has been making rockets a lot longer than SpaceX, who are still handed my them their ass.

</comment></comment><comment><USER27> I wish Boom the best of luck in getting a working product, but they need to fix their marketing. There is absolutely no way that plane tickets will cost 75% less than Concorde tickets, unless something drastic changes from the norm of air travel- either severe baggage restrictions, extremely cramped seating, or different fuel.

Even with all the greatest computer model, one thing remains the same: it takes a massive amount of thrust to maintain supersonic flight. EVERY airplane that is/was capable of supersonic cruise (SR-71, XB-70, F-22, Concorde) have/had comically oversized engines compared to what design rules of thumb would suggest. New technologies enable slightly more efficient airframes and slightly more efficient engines, we are talking about a few percent overall. So, I can see tickets being 20% less than they were in the Concorde's day.

Part of the reason I think they have mis-calculated a number is that they might be calculating a flight cost that includes fuel only and doesn't include other things an airline has to price into a ticket- namely insurance and maintenance. Insurance for the first supersonic passenger plane since the Concorde is guaranteed to be higher than a 767. Maintenance is going to be crazy as well- flying at Mach 2.2 places different stresses on an airplane, and they break a lot. All of the current supercruising airplanes are/were maintenance nightmares. Don't think that technology can "magic away" all the maintenance issues that come up with sustained stress on your engines, skin friction, and cooling issues.

Unless something else changes, there is no way you'll be able to buy a NY to London plane ticket for 75% less than a Concorde. How might they get there? Packing people in like sardines, or replacing normal baggage space with extra seats, would both get more paying seats on board, but would be a big setback from what business class passengers expect. Or maybe there is some magic fuel out there that is lighter than Jet-A/B and delivers more thrust and is safe enough for use in a passenger jet. The existence of magic fuel is unlikely, so be prepared for one of two things- 1. your tickets cost more than expected, or 2. you are packed in like a sardine.

Again, I'm glad that _someone_ is trying to make a supersonic passenger jet, but hyperbolic marketing ultimately hurts you in the long run when it becomes obvious that you can't live up to expectations.

<comment><USER28> This is the standard "engineers other than software are idiots" type HN FUD. For the record, Boom is staffed by aerospace veterans from the likes of Scaled Composites, P&W, Adam Aircraft, SpaceX and Boeing. [https://boomsupersonic.com/about/](https://boomsupersonic.com/about/) They might know thing or two about cost analysis.

<comment><USER29> In fairness, HN usually assumes software engineers are idiots too. The general sentiment is more "engineers other than me are idiots".

<comment><USER30> Not here. My sentiment is 'I have no idea what I am doing'

</comment></comment></comment></comment><comment><USER31> And no mention of how bad this will be for the environment?

<comment> King-Aaron I'm not sure if a business-focused article discussing an order of the aircraft really _needs to_ make mention of it?

<comment><USER32> Simplistic counter-argument: At this point, any article _needs to_ mention the environment if we're going to cut back on carbon pollution as much as we need to.

<comment><USER23> Nope. You can increase carbon pollution in one area while still reducing total net carbon emissions.

<comment><USER31> You can also give food to every hungry child on earth.

</comment></comment></comment></comment></comment><comment><USER33> If they can make these planes, I don't think selling them will be the problem.

</comment><comment><USER34> So excited about this but I do think they may want to re-think their name, especially given Concorde's end.

</comment><comment><USER35> So, has anyone wondered what happens when a Boom plane goes "boom!" ?

How could they call a plane something that means "explosion"?

<comment><USER36> My assumption is the "boom" refers to the sonic boom encountered when transitioning to supersonic speeds.

<comment><USER37> Not when transitioning -- sonic booms ("a sonic boom"?) are/is emitted continually at supersonic speeds.

<comment><USER38> This is true, but there's also a significant shock when crossing the sound barrier as the shockwave front draws up against the body of the plane. That was one of the biggest factors in why it took so long to break the sound barrier- you've gotta blast right through it. Around the sound barrier the rapidly changing air pressure pulls on the plane in weird ways, for instance literally twisting the wings off spitfires. They couldn't predict most of those problems ahead of time.

</comment></comment></comment></comment><comment><USER39> Whoever chose that name for the company really didn't think things through.

<comment><USER40> How did you figure that out? Looks like getting permission to make quiet sonic booms over land is a key part of their business model:

> Boom's airliner is designed to maximize efficiency while producing a "boom" > at least 30 times quieter than Concorde's.

Did you also predict the failure of the iPad in the marketplace, due to its unfortunate name?

<comment><USER41> I think he was referring to the fact that the name might make people think the planes explode.

<comment><USER40> I got that. Some people thought that iPad would fail because it sounded like a feminine sanitary product.

</comment></comment></comment></comment><comment><USER42> Why are they designing a plane with pilots? Why not automate that, perhaps with a remote option where a pilot sitting on the ground can take over in emergency/unusual situations?

<comment><USER43> Because we simply can't trust computers & systems engineering 100%. Go read about Flight QF72:

[http://www.theherald.com.au/story/4659526/the-untold- story-o...](http://www.theherald.com.au/story/4659526/the-untold-story-of- qf72-what-happens-when-psycho-automation-leaves-pilots-powerless/)

<comment><USER42> You've mentioned one story, but how about the countless cases where the pilots are the problem?

<comment><USER44> As with any automated transport discussion, there's the question of liability. If a pilot is at fault, there's an obvious liability on them. People have an intrinsic trust of a human pilot to sort out an issue if it arises, versus relying on a computer which is a complete black box to the passengers. If a pilot is at fault, it's a forgivable thing - in the worst cases the families have some closure, some level of "the pilot messed up, such is life". If a machine or system is at fault, who's to blame? The engineer? The programmer? The maintenance worker? The airline for procuring a cheap contract?</comment></comment></comment></comment>