[Cryptography-dev] Fernet NG or alternative simple, high-level, encrypted message module?

[Frank Siebenlist]

> ...snip...
> Questions for the pyca/cryptography community:
>
> * Any others who share the need/dream for such a high-level, simple
> Fernet-style library based on jose/jwt?
>
> There has been some conversation along these lines in
> https://github.com/pyca/cryptography/issues/2900 and continuing in
> https://github.com/pyca/cryptography/issues/2912


Thanks for the links - didn't see those - good to read about the
interest - this discussion should be on the mailing list and not
hidden in github-issues!


> In general I'm in favor of pulling jwcrypto (or something like it) into
> cryptography. The obstacles are going to be figuring out the licensing
> (cryptography is Apache2/BSD dual licensed and any code contributed to it
> needs to be available under those licenses), discussing what (if any) API
> changes need to be made to fit in with the API design of the hazmat layer,
> and general "make the code style match cryptography".
>
> As I've stated in issue 2912 I do feel that the JW{S,E,T} implementations
> belong in hazmat because the IETF specs allow bad algorithm choice. I might
> be okay with exposing a specifically opinionated version (e.g. your choices
> are taken away and cryptography selects a good choice) as a recipe. This
> sounds like it would meet your needs, correct?


Agreed - too many options to deal with - Fernet-like abstraction needs
to work with  (and hide) sane defaults.


> * Did we possibly miss an existing effort that meets (most of) those
> requirements?
>
> I'm not specifically familiar with any, but the world is vast. :)


I've copied a ipython notebook that illustrates the proto-type code
that we have for a Fernet-like message encryption module.

Hopefully that helps a discussion about the different choices at hand.

gist: "https://gist.github.com/franks42/714282ee84b58727c4e9a143d19071b8"


> * Comments? Suggestions?
>
> Be wary of algorithmic agility. :) Fernet bakes its algorithms into the
> version, so a future version can change them but it will result in a version
> bump (a system DJB frequently argues for:
> https://twitter.com/hashbreaker/status/601074008013037568). I personally
> believe it to be a better solution than what the JOSE specs choose to
> provide, but I also concede there's value in something being highly
> interoperable even if it isn't the platonic ideal. :)


I can relate to the concern and although I have an enormous amount of
respect for djb... I don't believe his code relates very well to your
average application developer ;-)
Not sure what the right answer is - but if you get agility (almost)
for free, whether you like it or not, by choosing jwk/e/s token
formats...

Regards, Frank.