Mailman 3 August 2013 - Cryptography-dev

Landing AES
by Alex Gaynor Aug. 31, 2013

Aug. 31, 2013

Hey all, We've slowed a bit in the last week or so. I want to get the AES patch landed so we can get the momentum back up ( https://github.com/alex/cryptography/pull/28). There's a few outstanding issues we need to resolve: * How the heck do we test error conditions in OpenSSL? OpenSSL is totally negligent in how we reproduce them. Should we monkeypatching the cffi functions to return error codes so we can at least test our code paths? * Since the BlockCipher object doesn't know if it's in encrypt or decrypt mode until the first call it can't really initialize itself in the constructor. Is that fine? Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero GPG Key fingerprint: 125F 5C67 DFE9 4084

4 6

GitHub organization for us
by Hynek Schlawack Aug. 10, 2013

Aug. 10, 2013

Hi, do we want a GitHub organization for cryptography and if yes, how do we call it? I’d propose PyCA in the proud tradition of PyPA. There is a dead project called pyca but that shouldn’t matter. Solving important problems today, —h

3 2

Verifying our History by Signing Commits
by Donald Stufft Aug. 9, 2013

Aug. 9, 2013

So Jean-Paul brought up in #cryptography-dev about the idea of signing our git commits. Personally I think this is a good idea however if we want to do it it leaves a few open questions with how we do it. Ideally the person who is adding the commit to the repository is the person who signs the commit (think of it similarly to the Signed-Off line). They are claiming responsibility for the commit landing in the tree. So the questions are 1) Do we want to have a policy of requiring GPG signed commits? 2) Do we want to require every commit being signed (which means reviewing every commit of a PR and signing it) or do we just want to require signing of the merge commit? 3) How does this interact with our code review process? Obviously if someone not a maintainer makes a patch whichever one of us commits it will be the signer, does the same follow for code written by us? This will likely require additional infrastructure to check every commit that lands on master is signed by a trusted key however a single Jenkins server should be plenty to ensure that everything is signed. Some additional reading: http://mikegerwitz.com/papers/git-horror-story.html ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

2 5

Low level API for Symmetric Encryption
by Donald Stufft Aug. 8, 2013

Aug. 8, 2013

So to kick things off I'd like to get AES-GCM exposed and figured it could be a good way to start the ball rolling for figuring out how we want to expose symmetric ciphers at the low level API. I'm thinking cryptography.primitives.aes which has classes named like AES128GCM, AES256CBC, etc. The obvious naming scheme being AlgorithmKeysizeMode. classes look something like class AES128GCM: # Information about the Cipher authenticated = True block_size = 128 def __init__(self, key, iv, …) def update(self, plaintext) # Updates an internal buffer as well as returns the encrypted chunk of data def finalize(self) # Updates the internal buffer witth finalized data and returns the same finalized data Some open questions: A lot of these are going to be block ciphers, do we want to do padding for people or expect them to hand us chunks of the correct block size? How do we decrypt vs encrypt. I think that: cipher = AES128GCM(key, iv) enciphered = cipher.update(plaintext) + cipher.finalize() cipher = AES128GCM(key, iv) plaintext = cipher.update(enciphered) + cipher.finalize() Makes a decent API here, but we need a way to make a decryption vs encryption cipher. Possibly something like encrypt=True, or decrypt=True (specifying both being an error)? Some ciphers (AES-GCM included) are authenticated and thus return (and require giving) a MAC in order to authenticate it, some authenticated ciphers also support the ability to pass along unencrypted but still authenticated data as well. I can't think of a decent way of doing this besides just adding functions (or __init__ args) to pass this data in, does anyone else have any ideas? Any other thoughts? I'm just spitballing here so let's see what we can come up with! ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

5 25

New repo
by Alex Gaynor Aug. 7, 2013

Aug. 7, 2013

Hi all, Since there's a bunch of known issues, and we want to have a pretty strict code review standard, I've started a new repo: https://github.com/alex/cryptography/ . Several of you should have commit access on it, and I've sent an initial PR (please review!). Reminder that PR authors should not merge them, someone else must merge all PRs, and never commit to master directly. Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero GPG Key fingerprint: 125F 5C67 DFE9 4084

1 0

Code review policy
by Alex Gaynor Aug. 2, 2013

Aug. 2, 2013

Hi all, Basically, crypto is scary, openssl is a footgun, and humans are fallible. Therefore I think we want have a pretty strict policy that everything needs to go through a PR *and be merged by someone else*. Anyone have a problem with that? Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero GPG Key fingerprint: 125F 5C67 DFE9 4084

3 2