Hi pyca/cryptography community, We're looking to migrate away from pycrypto - most probably to pyca/cryptography. Pretty sure there will be no objections to that choice on this mailing list. ;-)
We also have internally developed libraries for symmetric-key message encryption and such, which we’d love to migrate to some simple, high-level Fernet/KeyCzar-like lib for our developers to use. Our requirements for such a high-level, simple, symmetric-key message encryption library are: — * based on pyca/cryptography * simple interface that hides all low-level crypto, like algo, mode, iv, tag, and their respective sizes ** transparently uses the “correct" defaults for the developers. ** ideally just new_key, encrypt & decrypt functions with opaque tokens ** although implementation could hard-code choices, changes over time should be compatible with already encrypted tokens * make the keys and encrypted messages opaque tokens for developers ** no need to know what’s inside - just move those tokens from Alice to Bob and vice versa. * make both key and encrypted message tokens html&url-friendly ** base64url * token format enables/allows for algo/mode/size policy changes over time ** ideally a change of policy should not affect existing tokens and code ** (I’ve been bitten one time too many by hard-coded message formats…) * key versioning ** not sure yet about the details… ** maybe something like aws-kms: use newest key version by default and transparently decrypt any message encrypted with older versions (?). * key time-to-live ** Fernet has that TTL feature built-in for encrypted messages… but we haven’t seen that requirement yet (encrypted cookie life-time maybe?) * make key-management as transparent as possible ** use key-identifiers (kid) under-the-covers ** all keys should have identifiers ** all encrypted message tokes should include the associated key-identifier ** possible transparently deploy a default kid-key-db — The current Fernet module does not meet a number of those requirements, like the flexibility of transparently changing ciphers or sizes, no key-tokens, and no key-management help. Changing key-sizes or modes (AES256GCM anyone…), would brake the current implementation because the iv, cipher text and tag are essentially byte-concatenated in the token. Looking at the recent standards, an implementation based on jose's json web tokens would give you a lot of primitives to work with: well defined token format, enough meta-data about keys and encrypted messages to ensure the ability to change policies over time, overhead and increased message size acceptable for most (somewhat bigger than concatenating bare-bytes but not as overly verbose as XML-Encryption). Unfortunately, there is no jose library included in pyca/cryptography (yet)… The best jose library based on cryptography that I found seems to be jwcrypto, but its GNU GPL is less friendly (just observation - not a religious statement (I actually contributed to jwcrypto…)). Furthermore, it’s a lot of code to pull-in. We have prototype code that shows that a simple Fernet-style interface based on AES256GCM and jose’s jwt should be feasible. The coding was an exercise to test our requirements and possible token formats - production quality code was not aimed for. Ideally, we would prefer to leverage those kind of crypto libraries from efforts like pyca/cryptography… happy to help or contribute, but we’re very hesitant to take on the support of a crypto library as it’s not core to our business. 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? * Did we possibly miss an existing effort that meets (most of) those requirements? * Comments? Suggestions? Thanks, Frank. "From a security perspective, if you're connected, you're screwed." - Daniel J. Bernstein _______________________________________________ Cryptography-dev mailing list Cryptography-dev@python.org https://mail.python.org/mailman/listinfo/cryptography-dev
