Hacker News new | past | comments | ask | show | jobs | submit login

We're not talking about taking a venerable tool that's been sitting around for years and rewriting it though. We're talking about an actively-maintained and extremely highly-used library. I'm sure it's still bogged down by tech debt, but I'm also sure that any easy performance wins have already been taken.



A lot of time is spend on the assembler versions doing the crypto, which is why they get used by various other projects like ring, boringssl, and the Linux kernel.

Less or no time is spend on improving the performance of the SSL library. From the article, it seems that the SSL library might have easy fixes.


From the article it sounds like there are some simplistic reasons why OpenSSL may be slower, such as making an extra copy of the plaintext, but that doesn't necessarily mean that fixing it is easy.


Highly used yes. But there are only two full time developers on this and funding was flakey. There was giant discussion about this during Heartbleed vulnerability.


That's true, but performance improvements don't require fulltime developers. Many companies are directly impacted by OpenSSL performance (maybe moreso in the past when a big question about HTTPS adoption was the performance overhead of adding SSL to all requests, whereas today it's generally considered not a problem) which means companies have an incentive to submit patches to fix identifiable performance issues.




Applications are open for YC Winter 2020

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: