Fernet keyset - inspired by tink keyset

[vgrozdanic]

HI all,

inspired by tink keysets, is there an interest in supporting similar functionality within cryptography library?

It would be an upgrade over MultiFernet, where each key would have unique key_id, and encrypted data would contain the info about which key was use to encrypt the data (as a prefix?), so that for decryption would need to go through all of the keys to find out which key was used to encrypt it.

Also it would support standard operations:

• add a key to the keyset
• remove the key from the keyset
• promote the key to be the primary (used for encryption, all other keys in the keyset are used for decryption only).

Might even support enabled/disabled keys, so that the key is first disabled before deletion, in case there is still some encrypted data with it/

If there is an interest and this feature would be welcome, i am happy to discuss it further and put up a PR for this :)

[reaperhulk]

The challenge with modifying Fernet is that it is a spec (albeit a largely dead one) and we're very reluctant to modify it. A keyset-based Fernet would necessarily not interoperate with other Fernet implementations and thus is not really Fernet any more. The MultiFernet model is not good, but it does maintain that compatibility.

Separately, I've been interested in supporting the tink primitives (they're generally good!) in cryptography, which would naturally need tink keysets as well. They have documented the wire format as of a few years ago so this is entirely doable, but no one has tackled it yet.

[vgrozdanic]

Got it, and it makes sense. Thank you very much for the (very fast) response!

I will close this ticket then, since it is resolved :)

I agree that having tink primitives as a part of cryptography library would be really nice, but that is not a small task to tackle.

If one would want to contribute this to the library, what would be the process to do it? Discuss it first in the mailing list as mentioned in the contributing guide?

[reaperhulk]

We generally use issues or the mailing list to propose and discuss API design items. Feel free to stick entirely to issues if you'd like. Once there's a general agreement we invite PRs (draft or otherwise) and then continued iteration until we're ready to land.

I agree that tink in general is not a small task, but keysets + one primitive can be a first pass. 😄