Hacker News Reader

Comment by JanisErdmanis | Hacker News Reader

I personally don’t like that every single cryptography scheme is included in a single library. This creates a fake sense of powerfulness, but breaks down once some more complicated things need to be done such as zero knowledge proofs or homomorphic computations when it can become awkward at best. In a sensible language one makes seperate modules for hashing, cryptographic group library, pseudorandom number generation, cryptographic signatures, various zero knowledge proofs and TLS and uses package manager to install what one needs.

View on HN

Why? It's better if it's in one place and the overall quality is maintained there, than having different libraries with different authors, quality levels and guidelines.

Small libraries are easier to get into and contribute. Also, let’s say one develops some zero knowledge crypto system with Botan and then latter finds out that their elliptic curve implementation is not that performant. Improving performance of elliptic curves is one of the dark arts that only few know to do hence he decides to wrap one that OpenSSL library provides.

The essential question is whether he would be able to use OpenSSL implementation without changing internals of Botan or his own zero knowledge crypto system implementation. In modular libraries this is less of an issue as itself generally implies working with abstract groups and writing wrappers or implementations outside.

Small libraries are the biggest contributors to supply chain problems, and that is the last thing you want in your crypto libraries!

If you assemble your own system out of random components found on the web, there is a good chance that one of those components will either disappear or stop being supported. A single monolithic library is much likely to survive once it gets a critical mass of developers.

Every developer is responsible for verifying the trustworthiness of given components when bringing the dependencies in and their upgrades. If the libraries are with a small API surface that is much easier to do than verifying for a big monoliths. One can simply check the specs for inputs and outputs to remain unchanged and that already provides assurances for incorrect implementations.

Regarding supply chain attacks one of the important points is to establish consensus on dependency versions and their hashes via distributed replication or transparency logs (like in go). The big monolith then does not offer any advantages in this aspect.

(1) The small API surface does not mean small complexity. A high-level package like "curl" or some SSL library might have a very small API hiding lots of complexity

(2) How come "simply check the specs for inputs and outputs to remain unchanged" helps with trustworthiness or gives _any_ assurance of the incorrect implementations? (unless it's agda/coq, but we are not talking about them). The specs can say whatever, and yet the program might full of bugs.

(3) How do you select a library in an area you are not familiar with? It seems you know cryptography well, so let's choose a different topic - what would you examine to find, say, good audio capture library, or a good OpenGL wrapper? For me, I'd look at popularity (by number of reverse dependencies in my repo, mentions on the web, or github stats); liveness (activity in repo and mailing list, open/closed bugs); general quality (commit history, CI logs if they are public, etc..). All of those would be _vastly_ easier with a single large repo vs tons of smaller one.

(4) Think of few supply chain compromises that come to your mind. How many of those would be prevented by "distributed replication or transparency logs"? I've thought of xz compromise, left-pad pull and Marak's colors.js. _None_ of them would be fixed by "consensus on dependency versions and their hashes". All of them would be fixed if people just kept packages bigger, so that every one has actual CI, release team, and so on.

High level packages generally have much more users hence their inherent complexity is somewhat looked after by their users. Also curl has only a small user API, but once you consider implicit certificate store that is passed with every request and it’s countless variations it is in a sense untestable.

On the other hand libraries for hashes, encryptions, cryptographic groups, pseudorandom number generators are much more testable on their own. One can take specs and other engineered tests and check that inputs corespond to outputs. The rest is solved via memory safe languages and common sense of not having tests commented out or made special cases for them.

> How do you select a library in an area you are not familiar with?

By either having popularity or by being able to read the code and seeing that there are clear expectations communicated to the user via API or documentation. I wouldn’t consider security much when chosing user facing libraries much, but for network facing libraries popularity would be essential to me.

> All of them would be fixed if people just kept packages bigger, so that every one has actual CI, release team, and so on.

A bunch of small libraries can still be maintained by a large organization. It does not make difference if the are installed seperatelly. However modularity does add the benefit of being able to break into complexity to contributue and also gives more transparency for new users who can see what parts of the library are actually widely tested in the production and which are not and need more care.

Regarding xz, the lesson here is that one should not use programming languages where it’s limitations are deferred to preprocessors and complex build systems that only few can read. Similarly lesson from Log4j is that readability and language base features like string interpolation is much more preferable to having simply popularity.

tbh i'm just happy to see "crypto" and have it mean cryptography.

sic transit gloria mundi or something. :)

It's good for most use cases for it to be a black box. TLS apis that were designed in the 90s still work with the newest protocols and ciphers and bug fixes. Consumers of the library can blindly and transparently adopt 30 years of research into the topic.

TLS APIs with moving cryptography targets have proven quite useful. I'm only sad that more low-level cryptography never got popular. In a perfect world, you tell the OS what key/trust store to use, what domain to connect to, and you just get a plaintext socket that'll do all the cryptography for you, regardless of whether you're using TLS 1.0 or TLS 1.3.

I know the layered network protocol design is flawed, but I really like the elegance of the old design where TLS/IPSec/DTLS/WireGuard is just an option you pass to connect() rather than a library you need to pull in and maintain. Windows has something like that and it feels like somewhat of a missed opportunity for the internet.

connect(2) and these other kernel mode interfaces are definitely the wrong layer. Should be done in user mode. You also want to be able to replace the transport layer with whatever you want.

I think an opaque layer that lets you poke at internals when you decide you know what you're doing is the way to go. Eg. About 10 years ago I implemented certificate pinning atop a 1990s Microsoft API... you can use the api the "dumb" way and not touch it, and then optionally you can easily switch to implementing features the API vendor never envisioned.

Cannot be done in suer mode if you have "hardware" implementation inside your NIC.

And it is only way to performant TLS.

You don't really need NIC TLS unless your bitrate is rather high and you're serving data that is stored on disk / in disk cache rather than data that was just generated on the CPU.

Bulk ciphering is pretty inexpensive since Intel Haswell (2014) where there was a big improvement in AES-NI, but the load and store around ciphering static content that could otherwise avoid a trip through the CPU can be a significant bottleneck at 100gbps+. I'm sure there are measurable gains from TLS offload in other situations, but it's only critical for static content at high bit rates.

TLS 1.0 and TLS 1.1 are both a bad idea. If the far end of the connection isn't on a trip out of the solar system or buried under the ocean it needs to be upgraded. TLS 1.0 is from last century.

That's not the point. The point is that the application could've been written when TLS 1.0 was state of the art and now works over TLS 1.3 by simply updating the operating system. The OS can pick a safe set of communication protocols for you (unless manually override by user config to make broken old TLS 1.0 connections still work).

Reply on news.ycombinator.com