Mailman 3 September 2013 - Cryptography-dev

"Streaming" APIs
by Donald Stufft Sept. 19, 2013

Sept. 19, 2013

So one thing that's really handy to do with encryption is to be able to (de|en)crypt things without needing to load the entire thing into memory. Currently we support this in the encrypt API by doing: cipher = BlockCipher() enciphered = cipher.encrypt(block1) enciphered += cipher.encrypt(block2) enciphered += cipher.encrypt(block3) enciphered += cipher.finalize() We needed to do this because we need to be able to call finalize() before the encryption is "done". When I was messing with padding I ended up with an API that (for padding) got around the need for an explicit finalize step but instead it required passing the entire data stream into the function. However it supports generators/iterators so you can still efficiently process large datasets. This api looks something like padder = Padding() padded1 = "".join(padder.pad("1234")) padded2 = "".join(padder.pad(c for c in "1234")) However the downside of this API is that You need to call "".join() to get actual strings or you need to do some ugly hacks inside of the pad() function so it returns a string if given a string and returns a generator if given a generator. A third option is similar to dictionaries on Python 2.x where you have something like iterpad() and pad(). This could work for encryption as well so we'd have iter_encrypt(), iter_decrypt(), encrypt() and decrypt(). So I guess the question is how do we want to handle these streaming sorts of APIs? 1) Thing.action() + Thing.finalize() 2a) "".join(Thing.action(iterator)) 2b) Thing.action(terator OR string) - Magic return types 3) Thing.action and Thing.iter_action 4) ???? ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

3 6

"For Humans" Message Layout
by Donald Stufft Sept. 13, 2013

Sept. 13, 2013

So I've been looking at playing around with the start of the "for humans" API. I figure we need to either do a PyNaCl style "this is what the algorithms are and that's that" or a more flexible layout. I've opted to make the format itself flexible. So here's my proposal for a the message layout for an encrypted message: https://gist.github.com/dstufft/62473d7ae4b6f8b83577 I tried to make it flexible, it makes it possible for the format itself to specify things such as the algorithm, MAC, etc. The protocol is versioned, up to 65,535 versions, so if we ever need to change it we can. All in all with some assumptions as to cipher names, block size, MAC type an estimated overhead would be 107bytes on top of the encrypted data itself and the AAD. This will require 3 passes with the standard python struct module to parse (Once for the version number, once for the sizes, once for the data). I've sent this out to a few other people to get their opinions of it as well as to this list to get everyone's opinion here. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

2 2

CFB Modes
by Paul Kehrer Sept. 10, 2013

Sept. 10, 2013

I've been implementing some of the basic modes the past two days. I'm going to be putting in a PR for CFB/OFB soon, but wanted to see if people have any opinions about supporting the 1-bit and 8-bit CFB modes. There are two ways we can approach this. The easy way just means we declare two additional mode classes (CFB1 and CFB8) and those will correspond to 1-bit and 8-bit CFB modes that OpenSSL supports in addition to the standard CFB mode (which has a bit length of the block cipher's block size). The alternate way would be to create a single class: class CFB(object): def __init__(self, initialization_vector, bit_length=None): super(CFB, self).__init__() self.initialization_vector = initialization_vector self._determine_mode(bit_length) def _determine_mode(self, bit_length): if bit_length is None: self.name = 'CFB' elif int(bit_length) == 8 self.name = 'CFB8' elif int(bit_length) == 1 self.name = 'CFB1' else: raise ValueError According to NIST SP800-38A CFB can technically take an integer parameter 1 <= s <= b where b is the block length, but OpenSSL only supports 1, 8, and block length. Other backends we may choose to implement might be more flexible, but the _determine_mode method above is OpenSSL specific. Which approach do we prefer/is there another path we should consider looking at?

2 1

Let the flood gates open!
by Alex Gaynor Sept. 9, 2013

Sept. 9, 2013

Hynek just merged the AES patch, so now we have some actual crypto. I think it's time for us to get moving forwards: * More ciphers / modes (particularly I think a bunch of us want to make GCM a thing) * Starting to think about primitives that aren't block ciphers Let's do it! 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

6 12

Operating System Support
by Donald Stufft Sept. 9, 2013

Sept. 9, 2013

So I don't think we ever clarified this but what Operating Systems are we planning on supporting? For me I think *nix and Windows should be supported. The other question is are we ok with some things only working on a particular OS? If say we implement bcrypt and the library for that doesn't work on Windows (And assuming we support Windows) is that Ok? ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

5 5