Skip to content

Ephemeral keystore should not be used in protocol or service implementations

IMO the ephemeral keystore should not be used in a protocol implementation.

It should not be used when the code handling the key knows that it is ephemeral, and could use a plain Rust struct field instead.

Doctrine (IMO)

Ephemeral keystores should not be used for cryptographic keys that the protocol doesn't need to be persistent. Such keys should be stored as normal native Rust types, in the protocol implementation's data structures. Such a key should have a field name in some struct, not a KeySpecifier.

Rationale (IMO)

This is because an ephemeral keystore used in this way is simply a

  • shared mutable data structure
  • without any useful synchronisation or locking primitives
  • without automatic RAII cleanup (risking memory leaks)
  • with an inconvenient global namespace for naming its elements
  • and with an inconvenient and complex API for access.

Conversely, storing the private key in a field in a struct provides us with all the usual benefits of Rust's RAII and ownership model.

Just having a field is also less code:

  • There is no need to define a KeySpecifier
  • There is no need to explicitly delete a key when its containing structures go out of scope, since Rust's Drop impl will do that
  • Probably, less plumbing of KeyMgrs is needed
  • This avoids the presence of two KeyMgrs (real and ephemeral) in principal implementation code.

Controversy

I believe @nickm agrees with me on the points above. But in discussion it's clear that this view is controversial.

We have decided to defer resolving this disagreement, rather than get hung up on resolving it. The implication is that code can be added in-tree which violates the principle stated in this ticket.

People who agree with this ticket regard such code as technical debt; presumably people who disagree with this ticket think it's fine.

At some future point we will want to resolve this debate. We have decided to do this when we are under less time pressure to deliver a big project. At that time, there are multiple strategies we could use to have a constructive, structured, and pleasant conversation.

In the meantime this ticket stands as a record of the situation.

CC @ahf