Mailman 3 July 2016 - Cryptography-dev

Fernet NG or alternative simple, high-level, encrypted message module?
by Frank Siebenlist July 20, 2016

July 20, 2016

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

3 8

hash.SHA256 cpu expensive per byte versus byte-string?
by Frank Siebenlist July 14, 2016

July 14, 2016

I ran in some unexpected timing issues while using pyca/cryptography’s hash.SHA256, and I’m wondering if there is something wrong with the timing discrepancy I see between two different hashing approaches. When I hash a single byte-string of 10million bytes, it seems to take 2-3 orders of magnitude less time than when I loop over the bytes and hash them one by one. Please look at the following bare-bone snippet: — from __future__ import absolute_import, division, print_function import time from cryptography.hazmat.primitives import hashes from cryptography.hazmat.backends import default_backend # d1 = hashes.Hash(algorithm=hashes.SHA256(),backend=default_backend()) d2 = d1.copy() # n = 10000000 print('n:', n) # b = b'a' ba = bytearray(n*b'a') bs = bytes(ba) # s = time.time() d1.update(bs) t = time.time() - s print('ba: ', t) print(d1.finalize()) # s = time.time() for i in range(n): d2.update(b) t = time.time() - s print('b: ', t) print(d2.finalize()) # — The output is: — /usr/local/Cellar/python3/3.5.1/Frameworks/Python.framework/Versions/3.5/bin/python3.5 /Users/franksiebenlist/git/pyvate23/src/pyvate/messagedigest_tst.py n: 10000000 ba: 0.027185916900634766 b'\x01\xf4\xa8|\x04\xb4\n\xf5\x9a\xad\xc0\xe8\x12)5\tp\x9c\x9a\x87c\xa6\x0b\x7f\x9e\x1903"\xf8\xb0<' b: 15.677960872650146 b'\x01\xf4\xa8|\x04\xb4\n\xf5\x9a\xad\xc0\xe8\x12)5\tp\x9c\x9a\x87c\xa6\x0b\x7f\x9e\x1903"\xf8\xb0<' Process finished with exit code 0 — Results for python 2 and 3 are similar. I understand that there may be a few more object-creations and casts involved in the looping, but 500 times slower… that was un unexpected surprise. Comments? Observation? Thanks, Frank.

3 6

"intrinsic" symmetric key identifier?
by Frank Siebenlist July 7, 2016

July 7, 2016

Many times you will have two parties with a shared symmetric key that they will use to communicate authenticated and private messages to each other. If you have multiple keys, then you somehow have to match the key to the received message based on the context, the sender, or some key identifier that both parties associate with the used key. I'm looking for a good symmetric key identifier to use without the need for context or any pre-shared key-identifier. Some standardized way to derive a key-id from the key itself, such that both parties can derive it independently without any pre-shared key specific knowledge. Of course that key identifier shouldn't reveal anything that could compromise the key itself. I haven't been able to find a well-established way to achieve this (yet)... One possible solution could be to just taking the sha256 of the key. As long as the key is truly random... that should be ok (?). It could conflict with possible derived keys that are generated that way. Or maybe using one of the available KDFs? Those should be one-way-functions that wouldn't leak anything(?) Maybe use a well-known nonce to avoid any possible collisions with derived-keys. Any suggestions? Anything I missed? Regards, Frank.

4 14