In general, I am very open to adding functionality that people need into ring. But at least for now, I encourage one way and discourage the other way.

Here's the way I discourage: I need to do something. The minimal thing to add to ring needed to do that is Y, so I'll ask for Y to be added to ring so I can implement the rest of the construct outside of ring.

Here's the way I encourage: I need to do something. I'll add a misuse-resistant way of doing that to ring.

Let me given an example:

Some people want to implement Noise protocols using ring, and I want to encourage them to do so. Noise usually uses a combination of static and ephemeral Diffie-Hellman. ring currently only supports ephemeral Diffie-Hellman. So, we need to add something to ring:

The discouraged way: Add a static Diffie-Hellman API to ring.

The encouraged way: Add a hard(er)-to-misuse ephemeral-static API to ring. Maybe this requires putting X3DH and other ephemeral-static Diffie-Hellman constructs directly into ring, but I hope instead there's a more general safe(r) construct on top of which X3DH and other things can be implemented.

In terms of what @Philipp91 mentions, ring does have a "hazardous materials" API already, but it is intentionally restricted to internal use within ring.

Another way of thinking about this is that ring is a framework for implementing useful and interoperable crypto protocols, not a framework for implementing crypto primitives.

Also, if you need a feature added to ring and you don't want to publicly talk about your use case(s) in detail (e.g. because your project isn't open source), you can always email me at brian@briansmith.org and I'll explain how that works.

AES in CTR mode? #414

Description

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions