From alex.gaynor at gmail.com Thu Aug 1 22:39:21 2013 From: alex.gaynor at gmail.com (Alex Gaynor) Date: Thu, 1 Aug 2013 13:39:21 -0700 Subject: [Cryptography-dev] Code review policy Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From _ at lvh.io Thu Aug 1 22:41:12 2013 From: _ at lvh.io (Laurens Van Houtven) Date: Thu, 1 Aug 2013 22:41:12 +0200 Subject: [Cryptography-dev] Code review policy In-Reply-To: References: Message-ID: On Thu, Aug 1, 2013 at 10:39 PM, Alex Gaynor wrote: > 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? > I don't even need any of those arguments to think code review is great. lvh -------------- next part -------------- An HTML attachment was scrubbed... URL: From hs at ox.cx Fri Aug 2 12:50:31 2013 From: hs at ox.cx (Hynek Schlawack) Date: Fri, 2 Aug 2013 12:50:31 +0200 Subject: [Cryptography-dev] Code review policy In-Reply-To: References: Message-ID: <16521B7C-BB3D-4A21-A03D-9DBFF0670E6D@ox.cx> > 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? > > I don't even need any of those arguments to think code review is great. Aye. We?re trying nothing less than giving canonical crypto tools to the Python community. Strict is good. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 235 bytes Desc: Message signed with OpenPGP using GPGMail URL: From alex.gaynor at gmail.com Wed Aug 7 04:47:35 2013 From: alex.gaynor at gmail.com (Alex Gaynor) Date: Tue, 6 Aug 2013 19:47:35 -0700 Subject: [Cryptography-dev] New repo Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From donald at stufft.io Thu Aug 8 00:16:19 2013 From: donald at stufft.io (Donald Stufft) Date: Wed, 7 Aug 2013 18:16:19 -0400 Subject: [Cryptography-dev] Low level API for Symmetric Encryption Message-ID: 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From alex.gaynor at gmail.com Thu Aug 8 00:21:29 2013 From: alex.gaynor at gmail.com (Alex Gaynor) Date: Wed, 7 Aug 2013 15:21:29 -0700 Subject: [Cryptography-dev] Low level API for Symmetric Encryption In-Reply-To: References: Message-ID: A few thoughts: a) I don't like each call to update() returning data, it seems like it should all be buffered in the cipher and then returned at the end. b) I assume it raises an error if you try to do anything after finalization? c) I think params like a MAC should just be added to __init__ for ciphers which need them d) I don't have any ideas about specifying encrypt vs. decrypt. Alex On Wed, Aug 7, 2013 at 3:16 PM, Donald Stufft wrote: > 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 > > > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > http://mail.python.org/mailman/listinfo/cryptography-dev > > -- "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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From donald at stufft.io Thu Aug 8 00:27:24 2013 From: donald at stufft.io (Donald Stufft) Date: Wed, 7 Aug 2013 18:27:24 -0400 Subject: [Cryptography-dev] Low level API for Symmetric Encryption In-Reply-To: References: Message-ID: On Aug 7, 2013, at 6:21 PM, Alex Gaynor wrote: > A few thoughts: > > a) I don't like each call to update() returning data, it seems like it should all be buffered in the cipher and then returned at the end. The idea behind returning data is it enables the ability to stream the cipher (albeit at whatever the block size is for block ciphers). If you just buffer it and return it at the end then you can't really do that. Like a list comprehension vs an generator. > > b) I assume it raises an error if you try to do anything after finalization? That'd make the most sense I think, the other alternative is garbage but I think that's bad. > > c) I think params like a MAC should just be added to __init__ for ciphers which need them Well for instance for AES-GCM when encrypting you wouldn't add anything to __init__, you'd just need a way to fetch the MAC data that you can use to authenticate the ciphertext. When decrypting you need a way to pass the MAC data in so it can be authenticated (so this could use __init__). The same sort of thing exists for authenticated plaintext too, when encrypting you need to pass it in, when decrypting you get it back out. > > d) I don't have any ideas about specifying encrypt vs. decrypt. > > Alex > > > On Wed, Aug 7, 2013 at 3:16 PM, Donald Stufft wrote: > 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 > > > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > http://mail.python.org/mailman/listinfo/cryptography-dev > > > > > -- > "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 > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > http://mail.python.org/mailman/listinfo/cryptography-dev ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From alex.gaynor at gmail.com Thu Aug 8 00:31:05 2013 From: alex.gaynor at gmail.com (Alex Gaynor) Date: Wed, 7 Aug 2013 15:31:05 -0700 Subject: [Cryptography-dev] Low level API for Symmetric Encryption In-Reply-To: References: Message-ID: On Wed, Aug 7, 2013 at 3:27 PM, Donald Stufft wrote: > > On Aug 7, 2013, at 6:21 PM, Alex Gaynor wrote: > > A few thoughts: > > a) I don't like each call to update() returning data, it seems like it > should all be buffered in the cipher and then returned at the end. > > > The idea behind returning data is it enables the ability to stream the > cipher (albeit at whatever the block size is for block ciphers). If you > just buffer it and return it at the end then you can't really do that. Like > a list comprehension vs an generator. > > Different API then? I think most people assume update() won't return anything (also they'll do bufferring slowly with stuff like += on bytes). > > b) I assume it raises an error if you try to do anything after > finalization? > > > That'd make the most sense I think, the other alternative is garbage but I > think that's bad. > > Garbage bad. > > c) I think params like a MAC should just be added to __init__ for ciphers > which need them > > > Well for instance for AES-GCM when encrypting you wouldn't add anything to > __init__, you'd just need a way to fetch the MAC data that you can use to > authenticate the ciphertext. When decrypting you need a way to pass the MAC > data in so it can be authenticated (so this could use __init__). > > The same sort of thing exists for authenticated plaintext too, when > encrypting you need to pass it in, when decrypting you get it back out. > Yeah I think passing MAC on decrypt to __init__, and a method to get the mac makes the most sense (or have finalize return a tuple?). > > > d) I don't have any ideas about specifying encrypt vs. decrypt. > > Alex > > > On Wed, Aug 7, 2013 at 3:16 PM, Donald Stufft wrote: > >> 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 >> >> >> _______________________________________________ >> Cryptography-dev mailing list >> Cryptography-dev at python.org >> http://mail.python.org/mailman/listinfo/cryptography-dev >> >> > > > -- > "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 > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > http://mail.python.org/mailman/listinfo/cryptography-dev > > > > ----------------- > Donald Stufft > PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 > DCFA > > > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > http://mail.python.org/mailman/listinfo/cryptography-dev > > -- "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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From donald at stufft.io Thu Aug 8 00:40:03 2013 From: donald at stufft.io (Donald Stufft) Date: Wed, 7 Aug 2013 18:40:03 -0400 Subject: [Cryptography-dev] Low level API for Symmetric Encryption In-Reply-To: References: Message-ID: <63334B7C-EF41-438C-9966-31D7986088E5@stufft.io> On Aug 7, 2013, at 6:31 PM, Alex Gaynor wrote: > > > > On Wed, Aug 7, 2013 at 3:27 PM, Donald Stufft wrote: > > On Aug 7, 2013, at 6:21 PM, Alex Gaynor wrote: > >> A few thoughts: >> >> a) I don't like each call to update() returning data, it seems like it should all be buffered in the cipher and then returned at the end. > > The idea behind returning data is it enables the ability to stream the cipher (albeit at whatever the block size is for block ciphers). If you just buffer it and return it at the end then you can't really do that. Like a list comprehension vs an generator. > > > Different API then? I think most people assume update() won't return anything (also they'll do bufferring slowly with stuff like += on bytes). Yea we probably need two separate API's now that I think about it, because you likely want to either do streaming OR internal buffering. As suggested if I was trying to stream 50GB of data through encryption I'd be pretty upset if it was getting stored in an internal buffer chewing up 50Gb worth of ram by the time we're done. The other option is to just always have the api take data in, operate on it, and return data and never worry about doing any internal buffering. Probably need a different name than update though. This might be a bad idea but we could do ``decrypt()`` and ``encrypt()`` which function as above (take data in, operate on it, return it) and whichever one you call first sets the encrypt vs decrypt flag on that instance (so calling one and than the other would be an error). > >> >> b) I assume it raises an error if you try to do anything after finalization? > > That'd make the most sense I think, the other alternative is garbage but I think that's bad. > > > Garbage bad. > >> >> c) I think params like a MAC should just be added to __init__ for ciphers which need them > > Well for instance for AES-GCM when encrypting you wouldn't add anything to __init__, you'd just need a way to fetch the MAC data that you can use to authenticate the ciphertext. When decrypting you need a way to pass the MAC data in so it can be authenticated (so this could use __init__). > > The same sort of thing exists for authenticated plaintext too, when encrypting you need to pass it in, when decrypting you get it back out. > > Yeah I think passing MAC on decrypt to __init__, and a method to get the mac makes the most sense (or have finalize return a tuple?). > > >> >> d) I don't have any ideas about specifying encrypt vs. decrypt. >> >> Alex >> >> >> On Wed, Aug 7, 2013 at 3:16 PM, Donald Stufft wrote: >> 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 >> >> >> _______________________________________________ >> Cryptography-dev mailing list >> Cryptography-dev at python.org >> http://mail.python.org/mailman/listinfo/cryptography-dev >> >> >> >> >> -- >> "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 >> _______________________________________________ >> Cryptography-dev mailing list >> Cryptography-dev at python.org >> http://mail.python.org/mailman/listinfo/cryptography-dev > > > > ----------------- > Donald Stufft > PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA > > > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > http://mail.python.org/mailman/listinfo/cryptography-dev > > > > > -- > "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 > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > http://mail.python.org/mailman/listinfo/cryptography-dev ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From alex.gaynor at gmail.com Thu Aug 8 00:41:17 2013 From: alex.gaynor at gmail.com (Alex Gaynor) Date: Wed, 7 Aug 2013 15:41:17 -0700 Subject: [Cryptography-dev] Low level API for Symmetric Encryption In-Reply-To: <63334B7C-EF41-438C-9966-31D7986088E5@stufft.io> References: <63334B7C-EF41-438C-9966-31D7986088E5@stufft.io> Message-ID: I'm not sure I totally follow what you said, can you show an example of using such an API? Alex On Wed, Aug 7, 2013 at 3:40 PM, Donald Stufft wrote: > > On Aug 7, 2013, at 6:31 PM, Alex Gaynor wrote: > > > > > On Wed, Aug 7, 2013 at 3:27 PM, Donald Stufft wrote: > >> >> On Aug 7, 2013, at 6:21 PM, Alex Gaynor wrote: >> >> A few thoughts: >> >> a) I don't like each call to update() returning data, it seems like it >> should all be buffered in the cipher and then returned at the end. >> >> >> The idea behind returning data is it enables the ability to stream the >> cipher (albeit at whatever the block size is for block ciphers). If you >> just buffer it and return it at the end then you can't really do that. Like >> a list comprehension vs an generator. >> >> > Different API then? I think most people assume update() won't return > anything (also they'll do bufferring slowly with stuff like += on bytes). > > > Yea we probably need two separate API's now that I think about it, because > you likely want to either do streaming OR internal buffering. As suggested > if I was trying to stream 50GB of data through encryption I'd be pretty > upset if it was getting stored in an internal buffer chewing up 50Gb worth > of ram by the time we're done. > > The other option is to just always have the api take data in, operate on > it, and return data and never worry about doing any internal buffering. > Probably need a different name than update though. > > This might be a bad idea but we could do ``decrypt()`` and ``encrypt()`` > which function as above (take data in, operate on it, return it) and > whichever one you call first sets the encrypt vs decrypt flag on that > instance (so calling one and than the other would be an error). > > > >> >> b) I assume it raises an error if you try to do anything after >> finalization? >> >> >> That'd make the most sense I think, the other alternative is garbage but >> I think that's bad. >> >> > Garbage bad. > > >> >> c) I think params like a MAC should just be added to __init__ for ciphers >> which need them >> >> >> Well for instance for AES-GCM when encrypting you wouldn't add anything >> to __init__, you'd just need a way to fetch the MAC data that you can use >> to authenticate the ciphertext. When decrypting you need a way to pass the >> MAC data in so it can be authenticated (so this could use __init__). >> >> The same sort of thing exists for authenticated plaintext too, when >> encrypting you need to pass it in, when decrypting you get it back out. >> > > Yeah I think passing MAC on decrypt to __init__, and a method to get the > mac makes the most sense (or have finalize return a tuple?). > > >> >> >> d) I don't have any ideas about specifying encrypt vs. decrypt. >> >> Alex >> >> >> On Wed, Aug 7, 2013 at 3:16 PM, Donald Stufft wrote: >> >>> 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 >>> >>> >>> _______________________________________________ >>> Cryptography-dev mailing list >>> Cryptography-dev at python.org >>> http://mail.python.org/mailman/listinfo/cryptography-dev >>> >>> >> >> >> -- >> "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 >> _______________________________________________ >> Cryptography-dev mailing list >> Cryptography-dev at python.org >> http://mail.python.org/mailman/listinfo/cryptography-dev >> >> >> >> ----------------- >> Donald Stufft >> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 >> DCFA >> >> >> _______________________________________________ >> Cryptography-dev mailing list >> Cryptography-dev at python.org >> http://mail.python.org/mailman/listinfo/cryptography-dev >> >> > > > -- > "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 > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > http://mail.python.org/mailman/listinfo/cryptography-dev > > > > ----------------- > Donald Stufft > PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 > DCFA > > > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > http://mail.python.org/mailman/listinfo/cryptography-dev > > -- "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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From donald at stufft.io Thu Aug 8 00:55:30 2013 From: donald at stufft.io (Donald Stufft) Date: Wed, 7 Aug 2013 18:55:30 -0400 Subject: [Cryptography-dev] Low level API for Symmetric Encryption In-Reply-To: References: <63334B7C-EF41-438C-9966-31D7986088E5@stufft.io> Message-ID: <785613F6-916A-4CEE-80B0-5BFBCC9C2017@stufft.io> Using an Unauthenticated cipher to remove the distraction of the MAC and AAD. cipher = AES128CBC(key, iv) enciphered = "".join(cipher.encrypt(chunk) for chunk in CHUNKS) + cipher.finalize() cipher = AES128CBC(key, iv) plaintext = "".join(cipher.decrypt(chunk) for chunk in make_chunks(enciphered)) + cipher.finalize() There is no internal buffer. If you do cipher = AES128CBC(key, iv) cipher.encrypt(data) cipher.decrypt(enciphered) You'll get an error calling decrypt() because the first call to encrypt() toggled the cipher into "encryption mode". And if you call either of them after it's been finalized you'll get an error because it's been finalized. On Aug 7, 2013, at 6:41 PM, Alex Gaynor wrote: > I'm not sure I totally follow what you said, can you show an example of using such an API? > > Alex > > > On Wed, Aug 7, 2013 at 3:40 PM, Donald Stufft wrote: > > On Aug 7, 2013, at 6:31 PM, Alex Gaynor wrote: > >> >> >> >> On Wed, Aug 7, 2013 at 3:27 PM, Donald Stufft wrote: >> >> On Aug 7, 2013, at 6:21 PM, Alex Gaynor wrote: >> >>> A few thoughts: >>> >>> a) I don't like each call to update() returning data, it seems like it should all be buffered in the cipher and then returned at the end. >> >> The idea behind returning data is it enables the ability to stream the cipher (albeit at whatever the block size is for block ciphers). If you just buffer it and return it at the end then you can't really do that. Like a list comprehension vs an generator. >> >> >> Different API then? I think most people assume update() won't return anything (also they'll do bufferring slowly with stuff like += on bytes). > > Yea we probably need two separate API's now that I think about it, because you likely want to either do streaming OR internal buffering. As suggested if I was trying to stream 50GB of data through encryption I'd be pretty upset if it was getting stored in an internal buffer chewing up 50Gb worth of ram by the time we're done. > > The other option is to just always have the api take data in, operate on it, and return data and never worry about doing any internal buffering. Probably need a different name than update though. > > This might be a bad idea but we could do ``decrypt()`` and ``encrypt()`` which function as above (take data in, operate on it, return it) and whichever one you call first sets the encrypt vs decrypt flag on that instance (so calling one and than the other would be an error). > >> >>> >>> b) I assume it raises an error if you try to do anything after finalization? >> >> That'd make the most sense I think, the other alternative is garbage but I think that's bad. >> >> >> Garbage bad. >> >>> >>> c) I think params like a MAC should just be added to __init__ for ciphers which need them >> >> Well for instance for AES-GCM when encrypting you wouldn't add anything to __init__, you'd just need a way to fetch the MAC data that you can use to authenticate the ciphertext. When decrypting you need a way to pass the MAC data in so it can be authenticated (so this could use __init__). >> >> The same sort of thing exists for authenticated plaintext too, when encrypting you need to pass it in, when decrypting you get it back out. >> >> Yeah I think passing MAC on decrypt to __init__, and a method to get the mac makes the most sense (or have finalize return a tuple?). >> >> >>> >>> d) I don't have any ideas about specifying encrypt vs. decrypt. >>> >>> Alex >>> >>> >>> On Wed, Aug 7, 2013 at 3:16 PM, Donald Stufft wrote: >>> 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 >>> >>> >>> _______________________________________________ >>> Cryptography-dev mailing list >>> Cryptography-dev at python.org >>> http://mail.python.org/mailman/listinfo/cryptography-dev >>> >>> >>> >>> >>> -- >>> "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 >>> _______________________________________________ >>> Cryptography-dev mailing list >>> Cryptography-dev at python.org >>> http://mail.python.org/mailman/listinfo/cryptography-dev >> >> >> >> ----------------- >> Donald Stufft >> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA >> >> >> _______________________________________________ >> Cryptography-dev mailing list >> Cryptography-dev at python.org >> http://mail.python.org/mailman/listinfo/cryptography-dev >> >> >> >> >> -- >> "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 >> _______________________________________________ >> Cryptography-dev mailing list >> Cryptography-dev at python.org >> http://mail.python.org/mailman/listinfo/cryptography-dev > > > > ----------------- > Donald Stufft > PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA > > > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > http://mail.python.org/mailman/listinfo/cryptography-dev > > > > > -- > "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 > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > http://mail.python.org/mailman/listinfo/cryptography-dev ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From alex.gaynor at gmail.com Thu Aug 8 00:56:49 2013 From: alex.gaynor at gmail.com (Alex Gaynor) Date: Wed, 7 Aug 2013 15:56:49 -0700 Subject: [Cryptography-dev] Low level API for Symmetric Encryption In-Reply-To: <785613F6-916A-4CEE-80B0-5BFBCC9C2017@stufft.io> References: <63334B7C-EF41-438C-9966-31D7986088E5@stufft.io> <785613F6-916A-4CEE-80B0-5BFBCC9C2017@stufft.io> Message-ID: Sounds sane, I guess for primitives we really don't have to include buffering. You can always do SomeClass(cipher) which adds buffering on top. Alex On Wed, Aug 7, 2013 at 3:55 PM, Donald Stufft wrote: > Using an Unauthenticated cipher to remove the distraction of the MAC and > AAD. > > cipher = AES128CBC(key, iv) > enciphered = "".join(cipher.encrypt(chunk) for chunk in CHUNKS) + > cipher.finalize() > > cipher = AES128CBC(key, iv) > plaintext = "".join(cipher.decrypt(chunk) for chunk in > make_chunks(enciphered)) + cipher.finalize() > > There is no internal buffer. > > If you do > > cipher = AES128CBC(key, iv) > cipher.encrypt(data) > cipher.decrypt(enciphered) > > You'll get an error calling decrypt() because the first call to encrypt() > toggled the cipher into "encryption mode". And if you call either of them > after it's been finalized you'll get an error because it's been finalized. > > > On Aug 7, 2013, at 6:41 PM, Alex Gaynor wrote: > > I'm not sure I totally follow what you said, can you show an example of > using such an API? > > Alex > > > On Wed, Aug 7, 2013 at 3:40 PM, Donald Stufft wrote: > >> >> On Aug 7, 2013, at 6:31 PM, Alex Gaynor wrote: >> >> >> >> >> On Wed, Aug 7, 2013 at 3:27 PM, Donald Stufft wrote: >> >>> >>> On Aug 7, 2013, at 6:21 PM, Alex Gaynor wrote: >>> >>> A few thoughts: >>> >>> a) I don't like each call to update() returning data, it seems like it >>> should all be buffered in the cipher and then returned at the end. >>> >>> >>> The idea behind returning data is it enables the ability to stream the >>> cipher (albeit at whatever the block size is for block ciphers). If you >>> just buffer it and return it at the end then you can't really do that. Like >>> a list comprehension vs an generator. >>> >>> >> Different API then? I think most people assume update() won't return >> anything (also they'll do bufferring slowly with stuff like += on bytes). >> >> >> Yea we probably need two separate API's now that I think about it, >> because you likely want to either do streaming OR internal buffering. As >> suggested if I was trying to stream 50GB of data through encryption I'd be >> pretty upset if it was getting stored in an internal buffer chewing up 50Gb >> worth of ram by the time we're done. >> >> The other option is to just always have the api take data in, operate on >> it, and return data and never worry about doing any internal buffering. >> Probably need a different name than update though. >> >> This might be a bad idea but we could do ``decrypt()`` and ``encrypt()`` >> which function as above (take data in, operate on it, return it) and >> whichever one you call first sets the encrypt vs decrypt flag on that >> instance (so calling one and than the other would be an error). >> >> >> >>> >>> b) I assume it raises an error if you try to do anything after >>> finalization? >>> >>> >>> That'd make the most sense I think, the other alternative is garbage but >>> I think that's bad. >>> >>> >> Garbage bad. >> >> >>> >>> c) I think params like a MAC should just be added to __init__ for >>> ciphers which need them >>> >>> >>> Well for instance for AES-GCM when encrypting you wouldn't add anything >>> to __init__, you'd just need a way to fetch the MAC data that you can use >>> to authenticate the ciphertext. When decrypting you need a way to pass the >>> MAC data in so it can be authenticated (so this could use __init__). >>> >>> The same sort of thing exists for authenticated plaintext too, when >>> encrypting you need to pass it in, when decrypting you get it back out. >>> >> >> Yeah I think passing MAC on decrypt to __init__, and a method to get the >> mac makes the most sense (or have finalize return a tuple?). >> >> >>> >>> >>> d) I don't have any ideas about specifying encrypt vs. decrypt. >>> >>> Alex >>> >>> >>> On Wed, Aug 7, 2013 at 3:16 PM, Donald Stufft wrote: >>> >>>> 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 >>>> >>>> >>>> _______________________________________________ >>>> Cryptography-dev mailing list >>>> Cryptography-dev at python.org >>>> http://mail.python.org/mailman/listinfo/cryptography-dev >>>> >>>> >>> >>> >>> -- >>> "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 >>> _______________________________________________ >>> Cryptography-dev mailing list >>> Cryptography-dev at python.org >>> http://mail.python.org/mailman/listinfo/cryptography-dev >>> >>> >>> >>> ----------------- >>> Donald Stufft >>> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 >>> DCFA >>> >>> >>> _______________________________________________ >>> Cryptography-dev mailing list >>> Cryptography-dev at python.org >>> http://mail.python.org/mailman/listinfo/cryptography-dev >>> >>> >> >> >> -- >> "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 >> _______________________________________________ >> Cryptography-dev mailing list >> Cryptography-dev at python.org >> http://mail.python.org/mailman/listinfo/cryptography-dev >> >> >> >> ----------------- >> Donald Stufft >> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 >> DCFA >> >> >> _______________________________________________ >> Cryptography-dev mailing list >> Cryptography-dev at python.org >> http://mail.python.org/mailman/listinfo/cryptography-dev >> >> > > > -- > "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 > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > http://mail.python.org/mailman/listinfo/cryptography-dev > > > > ----------------- > Donald Stufft > PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 > DCFA > > > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > http://mail.python.org/mailman/listinfo/cryptography-dev > > -- "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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jean-paul at hybridcluster.com Thu Aug 8 00:32:31 2013 From: jean-paul at hybridcluster.com (Jean-Paul Calderone) Date: Wed, 07 Aug 2013 18:32:31 -0400 Subject: [Cryptography-dev] Low level API for Symmetric Encryption In-Reply-To: References: Message-ID: <5202CAFF.4040504@hybridcluster.com> On 08/07/2013 06:16 PM, Donald Stufft wrote: > 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. > > GCM (CBC, etc) is a mode of operation that is applicable to arbitrary block ciphers. Why should it be tied to "AES128"? Why wouldn't you GCM(AES128())? If you're talking about primitives, AES128 is more primitive than GCM on AES128. And GCM isn't specific to AES, so I don't see cryptography.primitives.aes as the proper home for it. I hope these aren't questions with highly obvious answers. Jean-Paul -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 900 bytes Desc: OpenPGP digital signature URL: From paul.l.kehrer at gmail.com Thu Aug 8 01:08:37 2013 From: paul.l.kehrer at gmail.com (Paul Kehrer) Date: Wed, 7 Aug 2013 18:08:37 -0500 Subject: [Cryptography-dev] Low level API for Symmetric Encryption In-Reply-To: <5202CAFF.4040504@hybridcluster.com> References: <5202CAFF.4040504@hybridcluster.com> Message-ID: That's an interesting angle. Obviously block cipher modes are applicable outside the realm of AES, but most crypto toolkits have used the cipher-key_len-mode convention when specifying ciphers (e.g. OpenSSL's EVP_aes_256_gcm). Is it worth trying to upend that convention? On Wed, Aug 7, 2013 at 5:32 PM, Jean-Paul Calderone wrote: > On 08/07/2013 06:16 PM, Donald Stufft wrote: >> 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. >> >> > > GCM (CBC, etc) is a mode of operation that is applicable to arbitrary > block ciphers. > > Why should it be tied to "AES128"? Why wouldn't you GCM(AES128())? If > you're talking about primitives, AES128 is more primitive than GCM on > AES128. And GCM isn't specific to AES, so I don't see > cryptography.primitives.aes as the proper home for it. > > I hope these aren't questions with highly obvious answers. > > Jean-Paul > > > > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > http://mail.python.org/mailman/listinfo/cryptography-dev > From donald at stufft.io Thu Aug 8 01:12:46 2013 From: donald at stufft.io (Donald Stufft) Date: Wed, 7 Aug 2013 19:12:46 -0400 Subject: [Cryptography-dev] Low level API for Symmetric Encryption In-Reply-To: <5202CAFF.4040504@hybridcluster.com> References: <5202CAFF.4040504@hybridcluster.com> Message-ID: <3F3C3CB4-BEC8-4DC9-B800-834DCA1FF805@stufft.io> On Aug 7, 2013, at 6:32 PM, Jean-Paul Calderone wrote: > On 08/07/2013 06:16 PM, Donald Stufft wrote: >> 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. >> >> > > GCM (CBC, etc) is a mode of operation that is applicable to arbitrary > block ciphers. > > Why should it be tied to "AES128"? Why wouldn't you GCM(AES128())? If > you're talking about primitives, AES128 is more primitive than GCM on > AES128. And GCM isn't specific to AES, so I don't see > cryptography.primitives.aes as the proper home for it. > > I hope these aren't questions with highly obvious answers. As far as I know (and I could be wrong? I don't know OpenSSL guts that well) OpenSSL doesn't do composition like that, in order to get AES-128-GCM you pass that in. Is there a way to access openssl where you're composing GCM with AES128? If not I think we'd be stuck do some sort of "combine variables of the classes AES128 and GCM to make the name AES-128-GCM to pass into openssl" thing which doesn't feel particularly clean to me? ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From alex.gaynor at gmail.com Thu Aug 8 01:18:31 2013 From: alex.gaynor at gmail.com (Alex Gaynor) Date: Wed, 7 Aug 2013 16:18:31 -0700 Subject: [Cryptography-dev] Low level API for Symmetric Encryption In-Reply-To: <3F3C3CB4-BEC8-4DC9-B800-834DCA1FF805@stufft.io> References: <5202CAFF.4040504@hybridcluster.com> <3F3C3CB4-BEC8-4DC9-B800-834DCA1FF805@stufft.io> Message-ID: Another option is to compose them in the constructor: AES(keysize=256, mode=GCM) or so. Alex On Wed, Aug 7, 2013 at 4:12 PM, Donald Stufft wrote: > > On Aug 7, 2013, at 6:32 PM, Jean-Paul Calderone < > jean-paul at hybridcluster.com> wrote: > > > On 08/07/2013 06:16 PM, Donald Stufft wrote: > >> 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. > >> > >> > > > > GCM (CBC, etc) is a mode of operation that is applicable to arbitrary > > block ciphers. > > > > Why should it be tied to "AES128"? Why wouldn't you GCM(AES128())? If > > you're talking about primitives, AES128 is more primitive than GCM on > > AES128. And GCM isn't specific to AES, so I don't see > > cryptography.primitives.aes as the proper home for it. > > > > I hope these aren't questions with highly obvious answers. > > As far as I know (and I could be wrong? I don't know OpenSSL guts that > well) OpenSSL doesn't do composition like that, in order to get AES-128-GCM > you pass that in. > > Is there a way to access openssl where you're composing GCM with AES128? > If not I think we'd be stuck do some sort of "combine variables of the > classes AES128 and GCM to make the name AES-128-GCM to pass into openssl" > thing which doesn't feel particularly clean to me? > > > ----------------- > Donald Stufft > PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 > DCFA > > > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > http://mail.python.org/mailman/listinfo/cryptography-dev > > -- "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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From donald at stufft.io Thu Aug 8 02:12:45 2013 From: donald at stufft.io (Donald Stufft) Date: Wed, 7 Aug 2013 20:12:45 -0400 Subject: [Cryptography-dev] Low level API for Symmetric Encryption In-Reply-To: References: <5202CAFF.4040504@hybridcluster.com> <3F3C3CB4-BEC8-4DC9-B800-834DCA1FF805@stufft.io> Message-ID: On Aug 7, 2013, at 7:18 PM, Alex Gaynor wrote: > Another option is to compose them in the constructor: AES(keysize=256, mode=GCM) or so. > > Alex We'd still essentially be passing AES-256-GCM into OpenSSL afaik. So afaik it'd only look like composing. We're not handling (most) of the differences between the modes (and none of the differences for key size). The mode classes could be stuff that handles the slight differences in how you call the API (for instance GCM has an additional call to EVP_EncryptUpdate to give it the AAD and a different calls to handle getting the MAC data. I'm not sure how well that'd translate? It might work ok. > > > On Wed, Aug 7, 2013 at 4:12 PM, Donald Stufft wrote: > > On Aug 7, 2013, at 6:32 PM, Jean-Paul Calderone wrote: > > > On 08/07/2013 06:16 PM, Donald Stufft wrote: > >> 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. > >> > >> > > > > GCM (CBC, etc) is a mode of operation that is applicable to arbitrary > > block ciphers. > > > > Why should it be tied to "AES128"? Why wouldn't you GCM(AES128())? If > > you're talking about primitives, AES128 is more primitive than GCM on > > AES128. And GCM isn't specific to AES, so I don't see > > cryptography.primitives.aes as the proper home for it. > > > > I hope these aren't questions with highly obvious answers. > > As far as I know (and I could be wrong? I don't know OpenSSL guts that well) OpenSSL doesn't do composition like that, in order to get AES-128-GCM you pass that in. > > Is there a way to access openssl where you're composing GCM with AES128? If not I think we'd be stuck do some sort of "combine variables of the classes AES128 and GCM to make the name AES-128-GCM to pass into openssl" thing which doesn't feel particularly clean to me? > > > ----------------- > Donald Stufft > PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA > > > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > http://mail.python.org/mailman/listinfo/cryptography-dev > > > > > -- > "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 > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > http://mail.python.org/mailman/listinfo/cryptography-dev ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From alex.gaynor at gmail.com Thu Aug 8 02:16:30 2013 From: alex.gaynor at gmail.com (Alex Gaynor) Date: Wed, 7 Aug 2013 17:16:30 -0700 Subject: [Cryptography-dev] Low level API for Symmetric Encryption In-Reply-To: References: <5202CAFF.4040504@hybridcluster.com> <3F3C3CB4-BEC8-4DC9-B800-834DCA1FF805@stufft.io> Message-ID: I guess the fact that different modes have fundamentally different APIs (e.g. GCM needs a MAC, CTR needs the counter, etc.) really points to that they should have different classes. How about keysize, do we need a class for each? Alex On Wed, Aug 7, 2013 at 5:12 PM, Donald Stufft wrote: > > On Aug 7, 2013, at 7:18 PM, Alex Gaynor wrote: > > Another option is to compose them in the constructor: AES(keysize=256, > mode=GCM) or so. > > Alex > > > We'd still essentially be passing AES-256-GCM into OpenSSL afaik. So afaik > it'd only look like composing. We're not handling (most) of the differences > between the modes (and none of the differences for key size). > > The mode classes could be stuff that handles the slight differences in how > you call the API (for instance GCM has an additional call > to EVP_EncryptUpdate to give it the AAD and a different calls to handle > getting the MAC data. I'm not sure how well that'd translate? It might work > ok. > > > > On Wed, Aug 7, 2013 at 4:12 PM, Donald Stufft wrote: > >> >> On Aug 7, 2013, at 6:32 PM, Jean-Paul Calderone < >> jean-paul at hybridcluster.com> wrote: >> >> > On 08/07/2013 06:16 PM, Donald Stufft wrote: >> >> 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. >> >> >> >> >> > >> > GCM (CBC, etc) is a mode of operation that is applicable to arbitrary >> > block ciphers. >> > >> > Why should it be tied to "AES128"? Why wouldn't you GCM(AES128())? If >> > you're talking about primitives, AES128 is more primitive than GCM on >> > AES128. And GCM isn't specific to AES, so I don't see >> > cryptography.primitives.aes as the proper home for it. >> > >> > I hope these aren't questions with highly obvious answers. >> >> As far as I know (and I could be wrong? I don't know OpenSSL guts that >> well) OpenSSL doesn't do composition like that, in order to get AES-128-GCM >> you pass that in. >> >> Is there a way to access openssl where you're composing GCM with AES128? >> If not I think we'd be stuck do some sort of "combine variables of the >> classes AES128 and GCM to make the name AES-128-GCM to pass into openssl" >> thing which doesn't feel particularly clean to me? >> >> >> ----------------- >> Donald Stufft >> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 >> DCFA >> >> >> _______________________________________________ >> Cryptography-dev mailing list >> Cryptography-dev at python.org >> http://mail.python.org/mailman/listinfo/cryptography-dev >> >> > > > -- > "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 > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > http://mail.python.org/mailman/listinfo/cryptography-dev > > > > ----------------- > Donald Stufft > PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 > DCFA > > > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > http://mail.python.org/mailman/listinfo/cryptography-dev > > -- "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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From donald at stufft.io Thu Aug 8 02:30:24 2013 From: donald at stufft.io (Donald Stufft) Date: Wed, 7 Aug 2013 20:30:24 -0400 Subject: [Cryptography-dev] Low level API for Symmetric Encryption In-Reply-To: References: <5202CAFF.4040504@hybridcluster.com> <3F3C3CB4-BEC8-4DC9-B800-834DCA1FF805@stufft.io> Message-ID: On Aug 7, 2013, at 8:16 PM, Alex Gaynor wrote: > I guess the fact that different modes have fundamentally different APIs (e.g. GCM needs a MAC, CTR needs the counter, etc.) really points to that they should have different classes. > > How about keysize, do we need a class for each? AFAIK there's no API differences for key size, it's just the size of the key and the name you tell openssl. OTOH now that I think about it more, maybe I'm looking at it backwards, I'm thinking about it like AES is the important part of GCM(AES128()) that Jean-Paul mentioned, but really it's the other way around. The differences between GCM vs CBC vs Whatever are not specific to key size or cipher. So if GCM/CBC/etc were the driving forces of the API interaction with OpenSSL and there is (I believe) no difference other than parameters you call the API's with for algo/key size instead of the way I was thinking of it where AES128() were the driving I think it would work assuming I'm right about that. > > Alex > > > On Wed, Aug 7, 2013 at 5:12 PM, Donald Stufft wrote: > > On Aug 7, 2013, at 7:18 PM, Alex Gaynor wrote: > >> Another option is to compose them in the constructor: AES(keysize=256, mode=GCM) or so. >> >> Alex > > We'd still essentially be passing AES-256-GCM into OpenSSL afaik. So afaik it'd only look like composing. We're not handling (most) of the differences between the modes (and none of the differences for key size). > > The mode classes could be stuff that handles the slight differences in how you call the API (for instance GCM has an additional call to EVP_EncryptUpdate to give it the AAD and a different calls to handle getting the MAC data. I'm not sure how well that'd translate? It might work ok. > >> >> >> On Wed, Aug 7, 2013 at 4:12 PM, Donald Stufft wrote: >> >> On Aug 7, 2013, at 6:32 PM, Jean-Paul Calderone wrote: >> >> > On 08/07/2013 06:16 PM, Donald Stufft wrote: >> >> 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. >> >> >> >> >> > >> > GCM (CBC, etc) is a mode of operation that is applicable to arbitrary >> > block ciphers. >> > >> > Why should it be tied to "AES128"? Why wouldn't you GCM(AES128())? If >> > you're talking about primitives, AES128 is more primitive than GCM on >> > AES128. And GCM isn't specific to AES, so I don't see >> > cryptography.primitives.aes as the proper home for it. >> > >> > I hope these aren't questions with highly obvious answers. >> >> As far as I know (and I could be wrong? I don't know OpenSSL guts that well) OpenSSL doesn't do composition like that, in order to get AES-128-GCM you pass that in. >> >> Is there a way to access openssl where you're composing GCM with AES128? If not I think we'd be stuck do some sort of "combine variables of the classes AES128 and GCM to make the name AES-128-GCM to pass into openssl" thing which doesn't feel particularly clean to me? >> >> >> ----------------- >> Donald Stufft >> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA >> >> >> _______________________________________________ >> Cryptography-dev mailing list >> Cryptography-dev at python.org >> http://mail.python.org/mailman/listinfo/cryptography-dev >> >> >> >> >> -- >> "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 >> _______________________________________________ >> Cryptography-dev mailing list >> Cryptography-dev at python.org >> http://mail.python.org/mailman/listinfo/cryptography-dev > > > > ----------------- > Donald Stufft > PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA > > > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > http://mail.python.org/mailman/listinfo/cryptography-dev > > > > > -- > "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 > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > http://mail.python.org/mailman/listinfo/cryptography-dev ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From paul.l.kehrer at gmail.com Thu Aug 8 02:36:54 2013 From: paul.l.kehrer at gmail.com (Paul Kehrer) Date: Wed, 7 Aug 2013 19:36:54 -0500 Subject: [Cryptography-dev] Low level API for Symmetric Encryption In-Reply-To: References: <5202CAFF.4040504@hybridcluster.com> <3F3C3CB4-BEC8-4DC9-B800-834DCA1FF805@stufft.io> Message-ID: GCM is only defined for block ciphers of 128/192/256 bit block lengths. So a construction of GCM(DES()) would have to throw an exception since DES uses a 64-bit block size. On Wed, Aug 7, 2013 at 7:30 PM, Donald Stufft wrote: > > On Aug 7, 2013, at 8:16 PM, Alex Gaynor wrote: > > I guess the fact that different modes have fundamentally different APIs > (e.g. GCM needs a MAC, CTR needs the counter, etc.) really points to that > they should have different classes. > > How about keysize, do we need a class for each? > > > AFAIK there's no API differences for key size, it's just the size of the key > and the name you tell openssl. > > OTOH now that I think about it more, maybe I'm looking at it backwards, I'm > thinking about it like AES is the important part of GCM(AES128()) that > Jean-Paul mentioned, but really it's the other way around. The differences > between GCM vs CBC vs Whatever are not specific to key size or cipher. > > So if GCM/CBC/etc were the driving forces of the API interaction with > OpenSSL and there is (I believe) no difference other than parameters you > call the API's with for algo/key size instead of the way I was thinking of > it where AES128() were the driving I think it would work assuming I'm right > about that. > > > > Alex > > > On Wed, Aug 7, 2013 at 5:12 PM, Donald Stufft wrote: >> >> >> On Aug 7, 2013, at 7:18 PM, Alex Gaynor wrote: >> >> Another option is to compose them in the constructor: AES(keysize=256, >> mode=GCM) or so. >> >> Alex >> >> >> We'd still essentially be passing AES-256-GCM into OpenSSL afaik. So afaik >> it'd only look like composing. We're not handling (most) of the differences >> between the modes (and none of the differences for key size). >> >> The mode classes could be stuff that handles the slight differences in how >> you call the API (for instance GCM has an additional call to >> EVP_EncryptUpdate to give it the AAD and a different calls to handle getting >> the MAC data. I'm not sure how well that'd translate? It might work ok. >> >> >> >> On Wed, Aug 7, 2013 at 4:12 PM, Donald Stufft wrote: >>> >>> >>> On Aug 7, 2013, at 6:32 PM, Jean-Paul Calderone >>> wrote: >>> >>> > On 08/07/2013 06:16 PM, Donald Stufft wrote: >>> >> 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. >>> >> >>> >> >>> > >>> > GCM (CBC, etc) is a mode of operation that is applicable to arbitrary >>> > block ciphers. >>> > >>> > Why should it be tied to "AES128"? Why wouldn't you GCM(AES128())? If >>> > you're talking about primitives, AES128 is more primitive than GCM on >>> > AES128. And GCM isn't specific to AES, so I don't see >>> > cryptography.primitives.aes as the proper home for it. >>> > >>> > I hope these aren't questions with highly obvious answers. >>> >>> As far as I know (and I could be wrong? I don't know OpenSSL guts that >>> well) OpenSSL doesn't do composition like that, in order to get AES-128-GCM >>> you pass that in. >>> >>> Is there a way to access openssl where you're composing GCM with AES128? >>> If not I think we'd be stuck do some sort of "combine variables of the >>> classes AES128 and GCM to make the name AES-128-GCM to pass into openssl" >>> thing which doesn't feel particularly clean to me? >>> >>> >>> ----------------- >>> Donald Stufft >>> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 >>> DCFA >>> >>> >>> _______________________________________________ >>> Cryptography-dev mailing list >>> Cryptography-dev at python.org >>> http://mail.python.org/mailman/listinfo/cryptography-dev >>> >> >> >> >> -- >> "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 >> _______________________________________________ >> Cryptography-dev mailing list >> Cryptography-dev at python.org >> http://mail.python.org/mailman/listinfo/cryptography-dev >> >> >> >> ----------------- >> Donald Stufft >> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 >> DCFA >> >> >> _______________________________________________ >> Cryptography-dev mailing list >> Cryptography-dev at python.org >> http://mail.python.org/mailman/listinfo/cryptography-dev >> > > > > -- > "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 > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > http://mail.python.org/mailman/listinfo/cryptography-dev > > > > ----------------- > Donald Stufft > PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA > > > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > http://mail.python.org/mailman/listinfo/cryptography-dev > From alex.gaynor at gmail.com Thu Aug 8 02:37:39 2013 From: alex.gaynor at gmail.com (Alex Gaynor) Date: Wed, 7 Aug 2013 17:37:39 -0700 Subject: [Cryptography-dev] Low level API for Symmetric Encryption In-Reply-To: References: <5202CAFF.4040504@hybridcluster.com> <3F3C3CB4-BEC8-4DC9-B800-834DCA1FF805@stufft.io> Message-ID: That makes sense, InvalidCipher or something. Alex On Wed, Aug 7, 2013 at 5:36 PM, Paul Kehrer wrote: > GCM is only defined for block ciphers of 128/192/256 bit block > lengths. So a construction of GCM(DES()) would have to throw an > exception since DES uses a 64-bit block size. > > On Wed, Aug 7, 2013 at 7:30 PM, Donald Stufft wrote: > > > > On Aug 7, 2013, at 8:16 PM, Alex Gaynor wrote: > > > > I guess the fact that different modes have fundamentally different APIs > > (e.g. GCM needs a MAC, CTR needs the counter, etc.) really points to that > > they should have different classes. > > > > How about keysize, do we need a class for each? > > > > > > AFAIK there's no API differences for key size, it's just the size of the > key > > and the name you tell openssl. > > > > OTOH now that I think about it more, maybe I'm looking at it backwards, > I'm > > thinking about it like AES is the important part of GCM(AES128()) that > > Jean-Paul mentioned, but really it's the other way around. The > differences > > between GCM vs CBC vs Whatever are not specific to key size or cipher. > > > > So if GCM/CBC/etc were the driving forces of the API interaction with > > OpenSSL and there is (I believe) no difference other than parameters you > > call the API's with for algo/key size instead of the way I was thinking > of > > it where AES128() were the driving I think it would work assuming I'm > right > > about that. > > > > > > > > Alex > > > > > > On Wed, Aug 7, 2013 at 5:12 PM, Donald Stufft wrote: > >> > >> > >> On Aug 7, 2013, at 7:18 PM, Alex Gaynor wrote: > >> > >> Another option is to compose them in the constructor: AES(keysize=256, > >> mode=GCM) or so. > >> > >> Alex > >> > >> > >> We'd still essentially be passing AES-256-GCM into OpenSSL afaik. So > afaik > >> it'd only look like composing. We're not handling (most) of the > differences > >> between the modes (and none of the differences for key size). > >> > >> The mode classes could be stuff that handles the slight differences in > how > >> you call the API (for instance GCM has an additional call to > >> EVP_EncryptUpdate to give it the AAD and a different calls to handle > getting > >> the MAC data. I'm not sure how well that'd translate? It might work ok. > >> > >> > >> > >> On Wed, Aug 7, 2013 at 4:12 PM, Donald Stufft wrote: > >>> > >>> > >>> On Aug 7, 2013, at 6:32 PM, Jean-Paul Calderone > >>> wrote: > >>> > >>> > On 08/07/2013 06:16 PM, Donald Stufft wrote: > >>> >> 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. > >>> >> > >>> >> > >>> > > >>> > GCM (CBC, etc) is a mode of operation that is applicable to arbitrary > >>> > block ciphers. > >>> > > >>> > Why should it be tied to "AES128"? Why wouldn't you GCM(AES128())? > If > >>> > you're talking about primitives, AES128 is more primitive than GCM on > >>> > AES128. And GCM isn't specific to AES, so I don't see > >>> > cryptography.primitives.aes as the proper home for it. > >>> > > >>> > I hope these aren't questions with highly obvious answers. > >>> > >>> As far as I know (and I could be wrong? I don't know OpenSSL guts that > >>> well) OpenSSL doesn't do composition like that, in order to get > AES-128-GCM > >>> you pass that in. > >>> > >>> Is there a way to access openssl where you're composing GCM with > AES128? > >>> If not I think we'd be stuck do some sort of "combine variables of the > >>> classes AES128 and GCM to make the name AES-128-GCM to pass into > openssl" > >>> thing which doesn't feel particularly clean to me? > >>> > >>> > >>> ----------------- > >>> Donald Stufft > >>> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 > >>> DCFA > >>> > >>> > >>> _______________________________________________ > >>> Cryptography-dev mailing list > >>> Cryptography-dev at python.org > >>> http://mail.python.org/mailman/listinfo/cryptography-dev > >>> > >> > >> > >> > >> -- > >> "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 > >> _______________________________________________ > >> Cryptography-dev mailing list > >> Cryptography-dev at python.org > >> http://mail.python.org/mailman/listinfo/cryptography-dev > >> > >> > >> > >> ----------------- > >> Donald Stufft > >> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 > >> DCFA > >> > >> > >> _______________________________________________ > >> Cryptography-dev mailing list > >> Cryptography-dev at python.org > >> http://mail.python.org/mailman/listinfo/cryptography-dev > >> > > > > > > > > -- > > "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 > > _______________________________________________ > > Cryptography-dev mailing list > > Cryptography-dev at python.org > > http://mail.python.org/mailman/listinfo/cryptography-dev > > > > > > > > ----------------- > > Donald Stufft > > PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 > DCFA > > > > > > _______________________________________________ > > Cryptography-dev mailing list > > Cryptography-dev at python.org > > http://mail.python.org/mailman/listinfo/cryptography-dev > > > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > http://mail.python.org/mailman/listinfo/cryptography-dev > -- "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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From donald at stufft.io Thu Aug 8 02:57:16 2013 From: donald at stufft.io (Donald Stufft) Date: Wed, 7 Aug 2013 20:57:16 -0400 Subject: [Cryptography-dev] Low level API for Symmetric Encryption In-Reply-To: References: <5202CAFF.4040504@hybridcluster.com> <3F3C3CB4-BEC8-4DC9-B800-834DCA1FF805@stufft.io> Message-ID: <10B09E87-8C63-4E9D-8750-4D3F8BBB7FD2@stufft.io> On Aug 7, 2013, at 8:36 PM, Paul Kehrer wrote: > GCM is only defined for block ciphers of 128/192/256 bit block > lengths. So a construction of GCM(DES()) would have to throw an > exception since DES uses a 64-bit block size. Yea the modes would need to know what properties the cipher needs to have in order to work with it. So GCM would need to check that it is a block cipher with a block size of 128, 192, or 256. It shouldn't check based on name of course. > > On Wed, Aug 7, 2013 at 7:30 PM, Donald Stufft wrote: >> >> On Aug 7, 2013, at 8:16 PM, Alex Gaynor wrote: >> >> I guess the fact that different modes have fundamentally different APIs >> (e.g. GCM needs a MAC, CTR needs the counter, etc.) really points to that >> they should have different classes. >> >> How about keysize, do we need a class for each? >> >> >> AFAIK there's no API differences for key size, it's just the size of the key >> and the name you tell openssl. >> >> OTOH now that I think about it more, maybe I'm looking at it backwards, I'm >> thinking about it like AES is the important part of GCM(AES128()) that >> Jean-Paul mentioned, but really it's the other way around. The differences >> between GCM vs CBC vs Whatever are not specific to key size or cipher. >> >> So if GCM/CBC/etc were the driving forces of the API interaction with >> OpenSSL and there is (I believe) no difference other than parameters you >> call the API's with for algo/key size instead of the way I was thinking of >> it where AES128() were the driving I think it would work assuming I'm right >> about that. >> >> >> >> Alex >> >> >> On Wed, Aug 7, 2013 at 5:12 PM, Donald Stufft wrote: >>> >>> >>> On Aug 7, 2013, at 7:18 PM, Alex Gaynor wrote: >>> >>> Another option is to compose them in the constructor: AES(keysize=256, >>> mode=GCM) or so. >>> >>> Alex >>> >>> >>> We'd still essentially be passing AES-256-GCM into OpenSSL afaik. So afaik >>> it'd only look like composing. We're not handling (most) of the differences >>> between the modes (and none of the differences for key size). >>> >>> The mode classes could be stuff that handles the slight differences in how >>> you call the API (for instance GCM has an additional call to >>> EVP_EncryptUpdate to give it the AAD and a different calls to handle getting >>> the MAC data. I'm not sure how well that'd translate? It might work ok. >>> >>> >>> >>> On Wed, Aug 7, 2013 at 4:12 PM, Donald Stufft wrote: >>>> >>>> >>>> On Aug 7, 2013, at 6:32 PM, Jean-Paul Calderone >>>> wrote: >>>> >>>>> On 08/07/2013 06:16 PM, Donald Stufft wrote: >>>>>> 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. >>>>>> >>>>>> >>>>> >>>>> GCM (CBC, etc) is a mode of operation that is applicable to arbitrary >>>>> block ciphers. >>>>> >>>>> Why should it be tied to "AES128"? Why wouldn't you GCM(AES128())? If >>>>> you're talking about primitives, AES128 is more primitive than GCM on >>>>> AES128. And GCM isn't specific to AES, so I don't see >>>>> cryptography.primitives.aes as the proper home for it. >>>>> >>>>> I hope these aren't questions with highly obvious answers. >>>> >>>> As far as I know (and I could be wrong? I don't know OpenSSL guts that >>>> well) OpenSSL doesn't do composition like that, in order to get AES-128-GCM >>>> you pass that in. >>>> >>>> Is there a way to access openssl where you're composing GCM with AES128? >>>> If not I think we'd be stuck do some sort of "combine variables of the >>>> classes AES128 and GCM to make the name AES-128-GCM to pass into openssl" >>>> thing which doesn't feel particularly clean to me? >>>> >>>> >>>> ----------------- >>>> Donald Stufft >>>> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 >>>> DCFA >>>> >>>> >>>> _______________________________________________ >>>> Cryptography-dev mailing list >>>> Cryptography-dev at python.org >>>> http://mail.python.org/mailman/listinfo/cryptography-dev >>>> >>> >>> >>> >>> -- >>> "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 >>> _______________________________________________ >>> Cryptography-dev mailing list >>> Cryptography-dev at python.org >>> http://mail.python.org/mailman/listinfo/cryptography-dev >>> >>> >>> >>> ----------------- >>> Donald Stufft >>> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 >>> DCFA >>> >>> >>> _______________________________________________ >>> Cryptography-dev mailing list >>> Cryptography-dev at python.org >>> http://mail.python.org/mailman/listinfo/cryptography-dev >>> >> >> >> >> -- >> "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 >> _______________________________________________ >> Cryptography-dev mailing list >> Cryptography-dev at python.org >> http://mail.python.org/mailman/listinfo/cryptography-dev >> >> >> >> ----------------- >> Donald Stufft >> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA >> >> >> _______________________________________________ >> Cryptography-dev mailing list >> Cryptography-dev at python.org >> http://mail.python.org/mailman/listinfo/cryptography-dev >> > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > http://mail.python.org/mailman/listinfo/cryptography-dev ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From paul.l.kehrer at gmail.com Thu Aug 8 03:15:53 2013 From: paul.l.kehrer at gmail.com (Paul Kehrer) Date: Wed, 7 Aug 2013 20:15:53 -0500 Subject: [Cryptography-dev] Low level API for Symmetric Encryption In-Reply-To: <10B09E87-8C63-4E9D-8750-4D3F8BBB7FD2@stufft.io> References: <5202CAFF.4040504@hybridcluster.com> <3F3C3CB4-BEC8-4DC9-B800-834DCA1FF805@stufft.io> <10B09E87-8C63-4E9D-8750-4D3F8BBB7FD2@stufft.io> Message-ID: That sounds workable. A few more questions around Jean-Paul's proposal then... Are people comfortable significantly changing the standard conventions for instantiation of block ciphers? I'm not aware of any major crypto APIs that currently build via mode(cipher()), although that might just be my ignorance. Since the underlying library is still OpenSSL this means constructs like CBC(AES(key_size=256), iv) will result in a BlockCipherMode object that holds an EVP_CIPHER, correct? For methods that can take an EVP_CIPHER (such as PEM_write_bio_RSAPrivateKey) you would need to pass in that BlockCipherMode object then. The AES() object itself would be used primarily for setting the key, getting the block size of the cipher, and being passed as a parameter into the mode constructor. It could not have an EVP_CIPHER since that implies a chosen mode. On Wed, Aug 7, 2013 at 7:57 PM, Donald Stufft wrote: > > On Aug 7, 2013, at 8:36 PM, Paul Kehrer wrote: > >> GCM is only defined for block ciphers of 128/192/256 bit block >> lengths. So a construction of GCM(DES()) would have to throw an >> exception since DES uses a 64-bit block size. > > Yea the modes would need to know what properties the cipher needs to have > in order to work with it. So GCM would need to check that it is a block cipher > with a block size of 128, 192, or 256. It shouldn't check based on name of > course. > >> >> On Wed, Aug 7, 2013 at 7:30 PM, Donald Stufft wrote: >>> >>> On Aug 7, 2013, at 8:16 PM, Alex Gaynor wrote: >>> >>> I guess the fact that different modes have fundamentally different APIs >>> (e.g. GCM needs a MAC, CTR needs the counter, etc.) really points to that >>> they should have different classes. >>> >>> How about keysize, do we need a class for each? >>> >>> >>> AFAIK there's no API differences for key size, it's just the size of the key >>> and the name you tell openssl. >>> >>> OTOH now that I think about it more, maybe I'm looking at it backwards, I'm >>> thinking about it like AES is the important part of GCM(AES128()) that >>> Jean-Paul mentioned, but really it's the other way around. The differences >>> between GCM vs CBC vs Whatever are not specific to key size or cipher. >>> >>> So if GCM/CBC/etc were the driving forces of the API interaction with >>> OpenSSL and there is (I believe) no difference other than parameters you >>> call the API's with for algo/key size instead of the way I was thinking of >>> it where AES128() were the driving I think it would work assuming I'm right >>> about that. >>> >>> >>> >>> Alex >>> >>> >>> On Wed, Aug 7, 2013 at 5:12 PM, Donald Stufft wrote: >>>> >>>> >>>> On Aug 7, 2013, at 7:18 PM, Alex Gaynor wrote: >>>> >>>> Another option is to compose them in the constructor: AES(keysize=256, >>>> mode=GCM) or so. >>>> >>>> Alex >>>> >>>> >>>> We'd still essentially be passing AES-256-GCM into OpenSSL afaik. So afaik >>>> it'd only look like composing. We're not handling (most) of the differences >>>> between the modes (and none of the differences for key size). >>>> >>>> The mode classes could be stuff that handles the slight differences in how >>>> you call the API (for instance GCM has an additional call to >>>> EVP_EncryptUpdate to give it the AAD and a different calls to handle getting >>>> the MAC data. I'm not sure how well that'd translate? It might work ok. >>>> >>>> >>>> >>>> On Wed, Aug 7, 2013 at 4:12 PM, Donald Stufft wrote: >>>>> >>>>> >>>>> On Aug 7, 2013, at 6:32 PM, Jean-Paul Calderone >>>>> wrote: >>>>> >>>>>> On 08/07/2013 06:16 PM, Donald Stufft wrote: >>>>>>> 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. >>>>>>> >>>>>>> >>>>>> >>>>>> GCM (CBC, etc) is a mode of operation that is applicable to arbitrary >>>>>> block ciphers. >>>>>> >>>>>> Why should it be tied to "AES128"? Why wouldn't you GCM(AES128())? If >>>>>> you're talking about primitives, AES128 is more primitive than GCM on >>>>>> AES128. And GCM isn't specific to AES, so I don't see >>>>>> cryptography.primitives.aes as the proper home for it. >>>>>> >>>>>> I hope these aren't questions with highly obvious answers. >>>>> >>>>> As far as I know (and I could be wrong? I don't know OpenSSL guts that >>>>> well) OpenSSL doesn't do composition like that, in order to get AES-128-GCM >>>>> you pass that in. >>>>> >>>>> Is there a way to access openssl where you're composing GCM with AES128? >>>>> If not I think we'd be stuck do some sort of "combine variables of the >>>>> classes AES128 and GCM to make the name AES-128-GCM to pass into openssl" >>>>> thing which doesn't feel particularly clean to me? >>>>> >>>>> >>>>> ----------------- >>>>> Donald Stufft >>>>> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 >>>>> DCFA >>>>> >>>>> >>>>> _______________________________________________ >>>>> Cryptography-dev mailing list >>>>> Cryptography-dev at python.org >>>>> http://mail.python.org/mailman/listinfo/cryptography-dev >>>>> >>>> >>>> >>>> >>>> -- >>>> "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 >>>> _______________________________________________ >>>> Cryptography-dev mailing list >>>> Cryptography-dev at python.org >>>> http://mail.python.org/mailman/listinfo/cryptography-dev >>>> >>>> >>>> >>>> ----------------- >>>> Donald Stufft >>>> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 >>>> DCFA >>>> >>>> >>>> _______________________________________________ >>>> Cryptography-dev mailing list >>>> Cryptography-dev at python.org >>>> http://mail.python.org/mailman/listinfo/cryptography-dev >>>> >>> >>> >>> >>> -- >>> "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 >>> _______________________________________________ >>> Cryptography-dev mailing list >>> Cryptography-dev at python.org >>> http://mail.python.org/mailman/listinfo/cryptography-dev >>> >>> >>> >>> ----------------- >>> Donald Stufft >>> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA >>> >>> >>> _______________________________________________ >>> Cryptography-dev mailing list >>> Cryptography-dev at python.org >>> http://mail.python.org/mailman/listinfo/cryptography-dev >>> >> _______________________________________________ >> Cryptography-dev mailing list >> Cryptography-dev at python.org >> http://mail.python.org/mailman/listinfo/cryptography-dev > > > ----------------- > Donald Stufft > PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA > > > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > http://mail.python.org/mailman/listinfo/cryptography-dev > From alex.gaynor at gmail.com Thu Aug 8 03:17:13 2013 From: alex.gaynor at gmail.com (Alex Gaynor) Date: Wed, 7 Aug 2013 18:17:13 -0700 Subject: [Cryptography-dev] Low level API for Symmetric Encryption In-Reply-To: References: <5202CAFF.4040504@hybridcluster.com> <3F3C3CB4-BEC8-4DC9-B800-834DCA1FF805@stufft.io> <10B09E87-8C63-4E9D-8750-4D3F8BBB7FD2@stufft.io> Message-ID: Yeah, the composition between the mode and cipher objects would be purely at the python layer, what you end up with is a single object which has an EVP_CIPHER. Alex On Wed, Aug 7, 2013 at 6:15 PM, Paul Kehrer wrote: > That sounds workable. > > A few more questions around Jean-Paul's proposal then... > > Are people comfortable significantly changing the standard conventions > for instantiation of block ciphers? I'm not aware of any major crypto > APIs that currently build via mode(cipher()), although that might just > be my ignorance. > > Since the underlying library is still OpenSSL this means constructs > like CBC(AES(key_size=256), iv) will result in a BlockCipherMode > object that holds an EVP_CIPHER, correct? For methods that can take an > EVP_CIPHER (such as PEM_write_bio_RSAPrivateKey) you would need to > pass in that BlockCipherMode object then. > > The AES() object itself would be used primarily for setting the key, > getting the block size of the cipher, and being passed as a parameter > into the mode constructor. It could not have an EVP_CIPHER since that > implies a chosen mode. > > On Wed, Aug 7, 2013 at 7:57 PM, Donald Stufft wrote: > > > > On Aug 7, 2013, at 8:36 PM, Paul Kehrer wrote: > > > >> GCM is only defined for block ciphers of 128/192/256 bit block > >> lengths. So a construction of GCM(DES()) would have to throw an > >> exception since DES uses a 64-bit block size. > > > > Yea the modes would need to know what properties the cipher needs to have > > in order to work with it. So GCM would need to check that it is a block > cipher > > with a block size of 128, 192, or 256. It shouldn't check based on name > of > > course. > > > >> > >> On Wed, Aug 7, 2013 at 7:30 PM, Donald Stufft wrote: > >>> > >>> On Aug 7, 2013, at 8:16 PM, Alex Gaynor wrote: > >>> > >>> I guess the fact that different modes have fundamentally different APIs > >>> (e.g. GCM needs a MAC, CTR needs the counter, etc.) really points to > that > >>> they should have different classes. > >>> > >>> How about keysize, do we need a class for each? > >>> > >>> > >>> AFAIK there's no API differences for key size, it's just the size of > the key > >>> and the name you tell openssl. > >>> > >>> OTOH now that I think about it more, maybe I'm looking at it > backwards, I'm > >>> thinking about it like AES is the important part of GCM(AES128()) that > >>> Jean-Paul mentioned, but really it's the other way around. The > differences > >>> between GCM vs CBC vs Whatever are not specific to key size or cipher. > >>> > >>> So if GCM/CBC/etc were the driving forces of the API interaction with > >>> OpenSSL and there is (I believe) no difference other than parameters > you > >>> call the API's with for algo/key size instead of the way I was > thinking of > >>> it where AES128() were the driving I think it would work assuming I'm > right > >>> about that. > >>> > >>> > >>> > >>> Alex > >>> > >>> > >>> On Wed, Aug 7, 2013 at 5:12 PM, Donald Stufft > wrote: > >>>> > >>>> > >>>> On Aug 7, 2013, at 7:18 PM, Alex Gaynor > wrote: > >>>> > >>>> Another option is to compose them in the constructor: AES(keysize=256, > >>>> mode=GCM) or so. > >>>> > >>>> Alex > >>>> > >>>> > >>>> We'd still essentially be passing AES-256-GCM into OpenSSL afaik. So > afaik > >>>> it'd only look like composing. We're not handling (most) of the > differences > >>>> between the modes (and none of the differences for key size). > >>>> > >>>> The mode classes could be stuff that handles the slight differences > in how > >>>> you call the API (for instance GCM has an additional call to > >>>> EVP_EncryptUpdate to give it the AAD and a different calls to handle > getting > >>>> the MAC data. I'm not sure how well that'd translate? It might work > ok. > >>>> > >>>> > >>>> > >>>> On Wed, Aug 7, 2013 at 4:12 PM, Donald Stufft > wrote: > >>>>> > >>>>> > >>>>> On Aug 7, 2013, at 6:32 PM, Jean-Paul Calderone > >>>>> wrote: > >>>>> > >>>>>> On 08/07/2013 06:16 PM, Donald Stufft wrote: > >>>>>>> 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. > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> GCM (CBC, etc) is a mode of operation that is applicable to > arbitrary > >>>>>> block ciphers. > >>>>>> > >>>>>> Why should it be tied to "AES128"? Why wouldn't you GCM(AES128())? > If > >>>>>> you're talking about primitives, AES128 is more primitive than GCM > on > >>>>>> AES128. And GCM isn't specific to AES, so I don't see > >>>>>> cryptography.primitives.aes as the proper home for it. > >>>>>> > >>>>>> I hope these aren't questions with highly obvious answers. > >>>>> > >>>>> As far as I know (and I could be wrong? I don't know OpenSSL guts > that > >>>>> well) OpenSSL doesn't do composition like that, in order to get > AES-128-GCM > >>>>> you pass that in. > >>>>> > >>>>> Is there a way to access openssl where you're composing GCM with > AES128? > >>>>> If not I think we'd be stuck do some sort of "combine variables of > the > >>>>> classes AES128 and GCM to make the name AES-128-GCM to pass into > openssl" > >>>>> thing which doesn't feel particularly clean to me? > >>>>> > >>>>> > >>>>> ----------------- > >>>>> Donald Stufft > >>>>> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 > 3372 > >>>>> DCFA > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> Cryptography-dev mailing list > >>>>> Cryptography-dev at python.org > >>>>> http://mail.python.org/mailman/listinfo/cryptography-dev > >>>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> "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 > >>>> _______________________________________________ > >>>> Cryptography-dev mailing list > >>>> Cryptography-dev at python.org > >>>> http://mail.python.org/mailman/listinfo/cryptography-dev > >>>> > >>>> > >>>> > >>>> ----------------- > >>>> Donald Stufft > >>>> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 > 3372 > >>>> DCFA > >>>> > >>>> > >>>> _______________________________________________ > >>>> Cryptography-dev mailing list > >>>> Cryptography-dev at python.org > >>>> http://mail.python.org/mailman/listinfo/cryptography-dev > >>>> > >>> > >>> > >>> > >>> -- > >>> "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 > >>> _______________________________________________ > >>> Cryptography-dev mailing list > >>> Cryptography-dev at python.org > >>> http://mail.python.org/mailman/listinfo/cryptography-dev > >>> > >>> > >>> > >>> ----------------- > >>> Donald Stufft > >>> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 > 3372 DCFA > >>> > >>> > >>> _______________________________________________ > >>> Cryptography-dev mailing list > >>> Cryptography-dev at python.org > >>> http://mail.python.org/mailman/listinfo/cryptography-dev > >>> > >> _______________________________________________ > >> Cryptography-dev mailing list > >> Cryptography-dev at python.org > >> http://mail.python.org/mailman/listinfo/cryptography-dev > > > > > > ----------------- > > Donald Stufft > > PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 > DCFA > > > > > > _______________________________________________ > > Cryptography-dev mailing list > > Cryptography-dev at python.org > > http://mail.python.org/mailman/listinfo/cryptography-dev > > > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > http://mail.python.org/mailman/listinfo/cryptography-dev > -- "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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From donald at stufft.io Thu Aug 8 03:24:44 2013 From: donald at stufft.io (Donald Stufft) Date: Wed, 7 Aug 2013 21:24:44 -0400 Subject: [Cryptography-dev] Low level API for Symmetric Encryption In-Reply-To: References: <5202CAFF.4040504@hybridcluster.com> <3F3C3CB4-BEC8-4DC9-B800-834DCA1FF805@stufft.io> <10B09E87-8C63-4E9D-8750-4D3F8BBB7FD2@stufft.io> Message-ID: On Aug 7, 2013, at 9:15 PM, Paul Kehrer wrote: > That sounds workable. > > A few more questions around Jean-Paul's proposal then... > > Are people comfortable significantly changing the standard conventions > for instantiation of block ciphers? I'm not aware of any major crypto > APIs that currently build via mode(cipher()), although that might just > be my ignorance. I think it will be ok. I'm no aware of any that do it this way either, but I think it ends up being a nicely pythonic interface. > > Since the underlying library is still OpenSSL this means constructs > like CBC(AES(key_size=256), iv) will result in a BlockCipherMode > object that holds an EVP_CIPHER, correct? For methods that can take an > EVP_CIPHER (such as PEM_write_bio_RSAPrivateKey) you would need to > pass in that BlockCipherMode object then. Are there any methods like this for Block Ciphers? We'd need to figure something like that out of course if there were and obviously it'd be nice to keep a composition style API throughout the library. > > The AES() object itself would be used primarily for setting the key, > getting the block size of the cipher, and being passed as a parameter > into the mode constructor. It could not have an EVP_CIPHER since that > implies a chosen mode. In my mind the bulk of the logic would live in the MODE() class and the cipher class would primarily be for setting cipher/key size. As far as I know OpenSSL doesn't really change the API between different cipher or key size, just modes. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From paul.l.kehrer at gmail.com Thu Aug 8 04:02:44 2013 From: paul.l.kehrer at gmail.com (Paul Kehrer) Date: Wed, 7 Aug 2013 21:02:44 -0500 Subject: [Cryptography-dev] Low level API for Symmetric Encryption In-Reply-To: References: <5202CAFF.4040504@hybridcluster.com> <3F3C3CB4-BEC8-4DC9-B800-834DCA1FF805@stufft.io> <10B09E87-8C63-4E9D-8750-4D3F8BBB7FD2@stufft.io> Message-ID: On Wed, Aug 7, 2013 at 8:24 PM, Donald Stufft wrote: > > Are there any methods like this for Block Ciphers? We'd need to figure > something like that out of course if there were and obviously it'd be > nice to keep a composition style API throughout the library. > The method I mentioned takes a block cipher as an argument to determine what (if any) encryption is applied to the (incidentally asymmetric) key. It's more common for an EVP_MD object to be passed in to another function though. > > In my mind the bulk of the logic would live in the MODE() class and the > cipher class would primarily be for setting cipher/key size. As far as I > know OpenSSL doesn't really change the API between different cipher > or key size, just modes. > Yeah, that's my experience as well. In your original email you mentioned padding, but the thread hasn't discussed it yet. With the API we're pitching now if we wanted to include padding I suppose it could look something like: padding = cryptography.primitives.padding.pkcs7() cipher = CBC(AES(),iv,padding) You could specify a different padding object (ansi x.923, etc) or leave it default and modes that don't require padding (GCM, CCM, XTS) would not have the parameter. From donald at stufft.io Thu Aug 8 04:25:31 2013 From: donald at stufft.io (Donald Stufft) Date: Wed, 7 Aug 2013 22:25:31 -0400 Subject: [Cryptography-dev] Low level API for Symmetric Encryption In-Reply-To: References: <5202CAFF.4040504@hybridcluster.com> <3F3C3CB4-BEC8-4DC9-B800-834DCA1FF805@stufft.io> <10B09E87-8C63-4E9D-8750-4D3F8BBB7FD2@stufft.io> Message-ID: On Aug 7, 2013, at 10:02 PM, Paul Kehrer wrote: > On Wed, Aug 7, 2013 at 8:24 PM, Donald Stufft wrote: >> >> Are there any methods like this for Block Ciphers? We'd need to figure >> something like that out of course if there were and obviously it'd be >> nice to keep a composition style API throughout the library. >> > > The method I mentioned takes a block cipher as an argument to > determine what (if any) encryption is applied to the (incidentally > asymmetric) key. It's more common for an EVP_MD object to be passed in > to another function though. > >> >> In my mind the bulk of the logic would live in the MODE() class and the >> cipher class would primarily be for setting cipher/key size. As far as I >> know OpenSSL doesn't really change the API between different cipher >> or key size, just modes. >> > > Yeah, that's my experience as well. > > > In your original email you mentioned padding, but the thread hasn't > discussed it yet. With the API we're pitching now if we wanted to > include padding I suppose it could look something like: > > padding = cryptography.primitives.padding.pkcs7() > > cipher = CBC(AES(),iv,padding) > > You could specify a different padding object (ansi x.923, etc) or > leave it default and modes that don't require padding (GCM, CCM, XTS) > would not have the parameter. Speaking of the Padding made me wonder if we're overloading the constructor of the mode too much, i'm not sure though because wether or not you want padding is dependent on the mode. Maybe we want:: cipher = BlockCipher(AES(key), CBC(iv), PKCS7()) ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From donald at stufft.io Thu Aug 8 05:20:33 2013 From: donald at stufft.io (Donald Stufft) Date: Wed, 7 Aug 2013 23:20:33 -0400 Subject: [Cryptography-dev] Low level API for Symmetric Encryption In-Reply-To: References: <5202CAFF.4040504@hybridcluster.com> <3F3C3CB4-BEC8-4DC9-B800-834DCA1FF805@stufft.io> <10B09E87-8C63-4E9D-8750-4D3F8BBB7FD2@stufft.io> Message-ID: <258906A4-EFBF-4FB9-8B36-C823567FB296@stufft.io> On Aug 7, 2013, at 10:25 PM, Donald Stufft wrote: > Speaking of the Padding made me wonder if we're overloading the constructor of the mode too much, i'm not sure though because wether or not you want padding is dependent on the mode. > > Maybe we want:: > > cipher = BlockCipher(AES(key), CBC(iv), PKCS7()) More thought on this, I'm not sure if the padding should be an argument to the mode or not, but one thing I do particularly like about this is it feels more like "AES-128-CBC" than CBC(AES(key), iv, ?) does. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From hs at ox.cx Thu Aug 8 08:10:08 2013 From: hs at ox.cx (Hynek Schlawack) Date: Thu, 8 Aug 2013 08:10:08 +0200 Subject: [Cryptography-dev] Low level API for Symmetric Encryption In-Reply-To: <3F3C3CB4-BEC8-4DC9-B800-834DCA1FF805@stufft.io> References: <5202CAFF.4040504@hybridcluster.com> <3F3C3CB4-BEC8-4DC9-B800-834DCA1FF805@stufft.io> Message-ID: Am 08.08.2013 um 01:12 schrieb Donald Stufft : >> GCM (CBC, etc) is a mode of operation that is applicable to arbitrary >> block ciphers. >> >> Why should it be tied to "AES128"? Why wouldn't you GCM(AES128())? If >> you're talking about primitives, AES128 is more primitive than GCM on >> AES128. And GCM isn't specific to AES, so I don't see >> cryptography.primitives.aes as the proper home for it. >> >> I hope these aren't questions with highly obvious answers. > > As far as I know (and I could be wrong? I don't know OpenSSL guts that well) OpenSSL doesn't do composition like that, in order to get AES-128-GCM you pass that in. > > Is there a way to access openssl where you're composing GCM with AES128? If not I think we'd be stuck do some sort of "combine variables of the classes AES128 and GCM to make the name AES-128-GCM to pass into openssl" thing which doesn't feel particularly clean to me? Please, don?t use OpenSSL?s atrocious APIs as a reason to make our API suck too. Composition is awesome and concatenating strings not that hard. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 235 bytes Desc: Message signed with OpenPGP using GPGMail URL: From paul.l.kehrer at gmail.com Thu Aug 8 14:51:56 2013 From: paul.l.kehrer at gmail.com (Paul Kehrer) Date: Thu, 8 Aug 2013 07:51:56 -0500 Subject: [Cryptography-dev] Low level API for Symmetric Encryption In-Reply-To: <258906A4-EFBF-4FB9-8B36-C823567FB296@stufft.io> References: <5202CAFF.4040504@hybridcluster.com> <3F3C3CB4-BEC8-4DC9-B800-834DCA1FF805@stufft.io> <10B09E87-8C63-4E9D-8750-4D3F8BBB7FD2@stufft.io> <258906A4-EFBF-4FB9-8B36-C823567FB296@stufft.io> Message-ID: I like this as it doesn't expect the mode class to hold all the important contexts. This is a nitpick since we're just discussing, but I'd like a different term than BlockCipher. Something that implies it is a complete set of the constructs needed. Maybe SymmetricEncryption? > On Aug 7, 2013, at 10:20 PM, Donald Stufft wrote: > > >> On Aug 7, 2013, at 10:25 PM, Donald Stufft wrote: >> >> Speaking of the Padding made me wonder if we're overloading the constructor of the mode too much, i'm not sure though because wether or not you want padding is dependent on the mode. >> >> Maybe we want:: >> >> cipher = BlockCipher(AES(key), CBC(iv), PKCS7()) > > More thought on this, I'm not sure if the padding should be an argument to > the mode or not, but one thing I do particularly like about this is it feels more > like "AES-128-CBC" than CBC(AES(key), iv, ?) does. > > ----------------- > Donald Stufft > PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA > > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > http://mail.python.org/mailman/listinfo/cryptography-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From donald at stufft.io Fri Aug 9 02:50:54 2013 From: donald at stufft.io (Donald Stufft) Date: Thu, 8 Aug 2013 20:50:54 -0400 Subject: [Cryptography-dev] Verifying our History by Signing Commits Message-ID: <67460F58-488C-4419-9A9F-076B24D94389@stufft.io> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From donald at stufft.io Fri Aug 9 03:11:43 2013 From: donald at stufft.io (Donald Stufft) Date: Thu, 8 Aug 2013 21:11:43 -0400 Subject: [Cryptography-dev] Verifying our History by Signing Commits In-Reply-To: <67460F58-488C-4419-9A9F-076B24D94389@stufft.io> References: <67460F58-488C-4419-9A9F-076B24D94389@stufft.io> Message-ID: <5F7706BD-17B1-44D9-925A-766FF472BA90@stufft.io> On Aug 8, 2013, at 8:50 PM, Donald Stufft wrote: > 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? One solution to this is simply have us sign our own commits, and the person who performs the merge signs the merge commit. Commits authored by people other than us we still need to decide between simply signing merge commits or needing to review each commit and one of us signing it. > > 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 > > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > http://mail.python.org/mailman/listinfo/cryptography-dev ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From _ at lvh.io Fri Aug 9 12:42:35 2013 From: _ at lvh.io (Laurens Van Houtven) Date: Fri, 9 Aug 2013 12:42:35 +0200 Subject: [Cryptography-dev] Verifying our History by Signing Commits In-Reply-To: <5F7706BD-17B1-44D9-925A-766FF472BA90@stufft.io> References: <67460F58-488C-4419-9A9F-076B24D94389@stufft.io> <5F7706BD-17B1-44D9-925A-766FF472BA90@stufft.io> Message-ID: Is this orthogonal to release tagging and signing? I mean, the signed tag also implies a signed DAG up to a point... Code review should fix the horror story, I think. Signing merge commits definitely makes sense to me; signing individual commits is okay, but that's what Fossil does by default, and let me tell you, typing your key in all the time gets boring quick :) cheers lvh -------------- next part -------------- An HTML attachment was scrubbed... URL: From donald at stufft.io Fri Aug 9 12:56:27 2013 From: donald at stufft.io (Donald Stufft) Date: Fri, 9 Aug 2013 06:56:27 -0400 Subject: [Cryptography-dev] Verifying our History by Signing Commits In-Reply-To: References: <67460F58-488C-4419-9A9F-076B24D94389@stufft.io> <5F7706BD-17B1-44D9-925A-766FF472BA90@stufft.io> Message-ID: On Aug 9, 2013, at 6:42 AM, Laurens Van Houtven <_ at lvh.io> wrote: > Is this orthogonal to release tagging and signing? I mean, the signed tag also implies a signed DAG up to a point... Code review should fix the horror story, I think. Yes it's orthogonal. The supposed problem with simply signing the tag is it verifies the DAG yes, but did you verify it? Did you go through each commit and make sure it wasn't maliciously added when the release was tagged? If Github has a breach we currently have no way to verify each commit in our tree. Really even if one of our computers gets breached. AFAIK nobody bothers to review each commit between the last signed tag and the soon to be tagged release to ensure nothing bad was added without our knowing. > > Signing merge commits definitely makes sense to me; signing individual commits is okay, but that's what Fossil does by default, and let me tell you, typing your key in all the time gets boring quick :) Yes, the obvious problem being if you don't squash the merges then again you're trusting that nothing was slipped into the tree unless you're verifying each commit. We may or may not care (or may care to some level), but JP brought it up and I thought it was an interesting enough idea to warrant discussion. > > cheers > lvh > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > http://mail.python.org/mailman/listinfo/cryptography-dev ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From _ at lvh.io Fri Aug 9 12:59:11 2013 From: _ at lvh.io (Laurens Van Houtven) Date: Fri, 9 Aug 2013 12:59:11 +0200 Subject: [Cryptography-dev] Verifying our History by Signing Commits In-Reply-To: References: <67460F58-488C-4419-9A9F-076B24D94389@stufft.io> <5F7706BD-17B1-44D9-925A-766FF472BA90@stufft.io> Message-ID: On Fri, Aug 9, 2013 at 12:56 PM, Donald Stufft wrote: > We may or may not care (or may care to some level), but JP brought it up > and I thought it was an interesting enough idea to warrant discussion. > Absolutely! This is just kind of like those PyPI situations where people tell you "hurr durr gee pee gee" and that doesn't really magically fix everything ;) Anyway, signing merge commits is cool, the reviewer is responsible for that, although I guess that means no more magical pull-review-merge-button? cheers lvh -------------- next part -------------- An HTML attachment was scrubbed... URL: From donald at stufft.io Fri Aug 9 13:00:53 2013 From: donald at stufft.io (Donald Stufft) Date: Fri, 9 Aug 2013 07:00:53 -0400 Subject: [Cryptography-dev] Verifying our History by Signing Commits In-Reply-To: References: <67460F58-488C-4419-9A9F-076B24D94389@stufft.io> <5F7706BD-17B1-44D9-925A-766FF472BA90@stufft.io> Message-ID: <3F4E5167-BB38-4221-9DB7-39F3334EED3B@stufft.io> On Aug 9, 2013, at 6:59 AM, Laurens Van Houtven <_ at lvh.io> wrote: > Anyway, signing merge commits is cool, the reviewer is responsible for that, although I guess that means no more magical pull-review-merge-button? Yes this would mean no more merge button, we'd have to manually merge again. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From hs at ox.cx Sat Aug 10 21:59:40 2013 From: hs at ox.cx (Hynek Schlawack) Date: Sat, 10 Aug 2013 21:59:40 +0200 Subject: [Cryptography-dev] GitHub organization for us Message-ID: 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 235 bytes Desc: Message signed with OpenPGP using GPGMail URL: From alex.gaynor at gmail.com Sat Aug 10 22:00:24 2013 From: alex.gaynor at gmail.com (Alex Gaynor) Date: Sat, 10 Aug 2013 13:00:24 -0700 Subject: [Cryptography-dev] GitHub organization for us In-Reply-To: References: Message-ID: +1 on an org, don't care what we call it. Alex On Sat, Aug 10, 2013 at 12:59 PM, Hynek Schlawack wrote: > 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 > > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > http://mail.python.org/mailman/listinfo/cryptography-dev > > -- "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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From donald at stufft.io Sat Aug 10 22:05:37 2013 From: donald at stufft.io (Donald Stufft) Date: Sat, 10 Aug 2013 16:05:37 -0400 Subject: [Cryptography-dev] GitHub organization for us In-Reply-To: References: Message-ID: <2D1D7C78-2D67-43CC-99BC-0A80798CD5A1@stufft.io> An organization sounds good, also don't care what we call it. On Aug 10, 2013, at 3:59 PM, Hynek Schlawack wrote: > 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 > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > http://mail.python.org/mailman/listinfo/cryptography-dev ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From alex.gaynor at gmail.com Tue Aug 27 04:25:33 2013 From: alex.gaynor at gmail.com (Alex Gaynor) Date: Mon, 26 Aug 2013 19:25:33 -0700 Subject: [Cryptography-dev] Landing AES Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hs at ox.cx Tue Aug 27 14:50:42 2013 From: hs at ox.cx (Hynek Schlawack) Date: Tue, 27 Aug 2013 13:50:42 +0100 Subject: [Cryptography-dev] Landing AES In-Reply-To: References: Message-ID: <1474292F-5902-46F6-B0A1-BB0136184577@ox.cx> > 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? That sounds rather sketchy TBH but I don't know the innards of both. > * 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? I see two options: 1. Explicit factory methods. 2. Init on first use. I tend to prefer 1., ideally with separate types. I love me some types. ?h -------------- next part -------------- An HTML attachment was scrubbed... URL: From donald at stufft.io Tue Aug 27 14:53:59 2013 From: donald at stufft.io (Donald Stufft) Date: Tue, 27 Aug 2013 08:53:59 -0400 Subject: [Cryptography-dev] Landing AES In-Reply-To: <1474292F-5902-46F6-B0A1-BB0136184577@ox.cx> References: <1474292F-5902-46F6-B0A1-BB0136184577@ox.cx> Message-ID: <83CBBB09-9FCD-4E5A-BBFB-039C2AB4A789@stufft.io> On Aug 27, 2013, at 8:50 AM, Hynek Schlawack wrote: > >> 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? > > That sounds rather sketchy TBH but I don't know the innards of both. I agree on this sounding sketchy but it might be the best way forward. > >> * 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? > > I see two options: > > 1. Explicit factory methods. > 2. Init on first use. > > I tend to prefer 1., ideally with separate types. I love me some types. I prefer just init on first use, it's currently setup to switch into decrypt or encrypt modes based on if you call BlockCipher.decrypt() or BlockCipher.encrypt() first. FWIW Encrypt/Decrypt mode only makes sense for certain combinations of things, some block ciphers can use the same operation. > > ?h > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > http://mail.python.org/mailman/listinfo/cryptography-dev FWIW there are a few outstanding issues inside the Pull Request comments as well. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From alex.gaynor at gmail.com Sat Aug 31 07:47:58 2013 From: alex.gaynor at gmail.com (Alex Gaynor) Date: Fri, 30 Aug 2013 22:47:58 -0700 Subject: [Cryptography-dev] Landing AES In-Reply-To: <83CBBB09-9FCD-4E5A-BBFB-039C2AB4A789@stufft.io> References: <1474292F-5902-46F6-B0A1-BB0136184577@ox.cx> <83CBBB09-9FCD-4E5A-BBFB-039C2AB4A789@stufft.io> Message-ID: So I gave up on trying to test the paths, until we know how they're supposed to fail, I just made them asserts, this way errors do not pass silently, and we have coverage (this is particularly important since we'd further have untested code for figuring out what the current openssl error is). We still need an answer to "change the API" vs. init on first method. Anyone have strong opinions? Alex On Tue, Aug 27, 2013 at 5:53 AM, Donald Stufft wrote: > > On Aug 27, 2013, at 8:50 AM, Hynek Schlawack wrote: > > > 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? > > > That sounds rather sketchy TBH but I don't know the innards of both. > > > I agree on this sounding sketchy but it might be the best way forward. > > > * 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? > > > I see two options: > > 1. Explicit factory methods. > 2. Init on first use. > > I tend to prefer 1., ideally with separate types. I love me some types. > > > I prefer just init on first use, it's currently setup to switch into > decrypt or encrypt modes based on if you call BlockCipher.decrypt() or > BlockCipher.encrypt() first. FWIW Encrypt/Decrypt mode only makes sense for > certain combinations of things, some block ciphers can use the same > operation. > > > ?h > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > http://mail.python.org/mailman/listinfo/cryptography-dev > > > FWIW there are a few outstanding issues inside the Pull Request comments > as well. > > ----------------- > Donald Stufft > PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 > DCFA > > > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > http://mail.python.org/mailman/listinfo/cryptography-dev > > -- "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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.v.diaz at gmail.com Sat Aug 31 13:16:11 2013 From: vladimir.v.diaz at gmail.com (Vladimir Diaz) Date: Sat, 31 Aug 2013 07:16:11 -0400 Subject: [Cryptography-dev] Landing AES In-Reply-To: References: <1474292F-5902-46F6-B0A1-BB0136184577@ox.cx> <83CBBB09-9FCD-4E5A-BBFB-039C2AB4A789@stufft.io> Message-ID: On Sat, Aug 31, 2013 at 1:47 AM, Alex Gaynor wrote: > So I gave up on trying to test the paths, until we know how they're > supposed to fail, I just made them asserts, this way errors do not pass > silently, and we have coverage (this is particularly important since we'd > further have untested code for figuring out what the current openssl error > is). > Might OpenSSL's ERR_get_error() and ERR_GET_REASON() help in figuring out what the current OpenSSL error is? http://www.openssl.org/docs/crypto/ERR_get_error.html http://www.openssl.org/docs/crypto/ERR_GET_LIB.html > > We still need an answer to "change the API" vs. init on first method. > Anyone have strong opinions? > > Alex > > > On Tue, Aug 27, 2013 at 5:53 AM, Donald Stufft wrote: > >> >> On Aug 27, 2013, at 8:50 AM, Hynek Schlawack wrote: >> >> >> 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? >> >> >> That sounds rather sketchy TBH but I don't know the innards of both. >> >> >> I agree on this sounding sketchy but it might be the best way forward. >> >> >> * 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? >> >> >> I see two options: >> >> 1. Explicit factory methods. >> 2. Init on first use. >> >> I tend to prefer 1., ideally with separate types. I love me some types. >> >> >> I prefer just init on first use, it's currently setup to switch into >> decrypt or encrypt modes based on if you call BlockCipher.decrypt() or >> BlockCipher.encrypt() first. FWIW Encrypt/Decrypt mode only makes sense for >> certain combinations of things, some block ciphers can use the same >> operation. >> >> >> ?h >> _______________________________________________ >> Cryptography-dev mailing list >> Cryptography-dev at python.org >> http://mail.python.org/mailman/listinfo/cryptography-dev >> >> >> FWIW there are a few outstanding issues inside the Pull Request comments >> as well. >> >> ----------------- >> Donald Stufft >> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 >> DCFA >> >> >> _______________________________________________ >> Cryptography-dev mailing list >> Cryptography-dev at python.org >> http://mail.python.org/mailman/listinfo/cryptography-dev >> >> > > > -- > "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 > > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > http://mail.python.org/mailman/listinfo/cryptography-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.gaynor at gmail.com Sat Aug 31 17:27:56 2013 From: alex.gaynor at gmail.com (Alex Gaynor) Date: Sat, 31 Aug 2013 08:27:56 -0700 Subject: [Cryptography-dev] Landing AES In-Reply-To: References: <1474292F-5902-46F6-B0A1-BB0136184577@ox.cx> <83CBBB09-9FCD-4E5A-BBFB-039C2AB4A789@stufft.io> Message-ID: Sure, but the problem is triggering errors in the first place in the tests. Alex On Sat, Aug 31, 2013 at 4:16 AM, Vladimir Diaz wrote: > > > > On Sat, Aug 31, 2013 at 1:47 AM, Alex Gaynor wrote: > >> So I gave up on trying to test the paths, until we know how they're >> supposed to fail, I just made them asserts, this way errors do not pass >> silently, and we have coverage (this is particularly important since we'd >> further have untested code for figuring out what the current openssl error >> is). >> > > Might OpenSSL's ERR_get_error() and ERR_GET_REASON() help in figuring out > what the current OpenSSL error is? > > http://www.openssl.org/docs/crypto/ERR_get_error.html > http://www.openssl.org/docs/crypto/ERR_GET_LIB.html > > >> >> We still need an answer to "change the API" vs. init on first method. >> Anyone have strong opinions? >> >> Alex >> >> >> On Tue, Aug 27, 2013 at 5:53 AM, Donald Stufft wrote: >> >>> >>> On Aug 27, 2013, at 8:50 AM, Hynek Schlawack wrote: >>> >>> >>> 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? >>> >>> >>> That sounds rather sketchy TBH but I don't know the innards of both. >>> >>> >>> I agree on this sounding sketchy but it might be the best way forward. >>> >>> >>> * 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? >>> >>> >>> I see two options: >>> >>> 1. Explicit factory methods. >>> 2. Init on first use. >>> >>> I tend to prefer 1., ideally with separate types. I love me some types. >>> >>> >>> I prefer just init on first use, it's currently setup to switch into >>> decrypt or encrypt modes based on if you call BlockCipher.decrypt() or >>> BlockCipher.encrypt() first. FWIW Encrypt/Decrypt mode only makes sense for >>> certain combinations of things, some block ciphers can use the same >>> operation. >>> >>> >>> ?h >>> _______________________________________________ >>> Cryptography-dev mailing list >>> Cryptography-dev at python.org >>> http://mail.python.org/mailman/listinfo/cryptography-dev >>> >>> >>> FWIW there are a few outstanding issues inside the Pull Request comments >>> as well. >>> >>> ----------------- >>> Donald Stufft >>> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 >>> DCFA >>> >>> >>> _______________________________________________ >>> Cryptography-dev mailing list >>> Cryptography-dev at python.org >>> http://mail.python.org/mailman/listinfo/cryptography-dev >>> >>> >> >> >> -- >> "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 >> >> _______________________________________________ >> Cryptography-dev mailing list >> Cryptography-dev at python.org >> http://mail.python.org/mailman/listinfo/cryptography-dev >> >> > > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > http://mail.python.org/mailman/listinfo/cryptography-dev > > -- "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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.v.diaz at gmail.com Sat Aug 31 20:41:00 2013 From: vladimir.v.diaz at gmail.com (Vladimir Diaz) Date: Sat, 31 Aug 2013 14:41:00 -0400 Subject: [Cryptography-dev] Landing AES In-Reply-To: References: <1474292F-5902-46F6-B0A1-BB0136184577@ox.cx> <83CBBB09-9FCD-4E5A-BBFB-039C2AB4A789@stufft.io> Message-ID: https://github.com/alex/cryptography/blob/5c02ef3260aa4ffc5920aca4bc5d8aa88b430c14/cryptography/bindings/openssl/api.py#L64-L68 Instead of just asserting that 'evp_cipher' is not NULL, you may instead raise a user-defined Python exception matching the OpenSSL error code that you extract with ERR_get_error(), ERR_GET_REASON(), etc [1,2,3]. Example: cipher.name = "bogus_cipher_name" cipher.mode = "bogus_mode" cipher.key_size = 0 ciphername = "{0}-{1}-{2}".format(cipher.name, cipher.key_size, cipher.mode) evp_cipher = self._lib.EVP_get_cipherbyname(ciphername.encode("ascii")) # If EVP_get_cipherbyname() returns NULL, OpenSSL should have added the error # code to the thread's error queue (i.e., call ERR_get_error(), ERR_GET_REASON(), # etc. to extract the specific OpenSSL error. if evp_cipher == self._ffi.NULL: error = routine_that_extracts_ssl_error_information() # Raise user-defined exception matching SSL error? Perhaps your Python library defines exceptions for each expected OpenSSL error code and your test modules test against these user-defined exceptions? assertRaises(cryptography.SSLCipherNameError, create_block_cipher_context, bogus_cipher, bogus_mode) [1] https://github.com/openssl/openssl/blob/master/crypto/err/err.h [2] https://github.com/openssl/openssl/blob/master/crypto/evp/evp.h#L1444 [3] https://github.com/openssl/openssl/blob/master/crypto/evp/evp.h#L1453 On Sat, Aug 31, 2013 at 11:27 AM, Alex Gaynor wrote: > Sure, but the problem is triggering errors in the first place in the tests. > > Alex > > > On Sat, Aug 31, 2013 at 4:16 AM, Vladimir Diaz wrote: > >> >> >> >> On Sat, Aug 31, 2013 at 1:47 AM, Alex Gaynor wrote: >> >>> So I gave up on trying to test the paths, until we know how they're >>> supposed to fail, I just made them asserts, this way errors do not pass >>> silently, and we have coverage (this is particularly important since we'd >>> further have untested code for figuring out what the current openssl error >>> is). >>> >> >> Might OpenSSL's ERR_get_error() and ERR_GET_REASON() help in figuring out >> what the current OpenSSL error is? >> >> http://www.openssl.org/docs/crypto/ERR_get_error.html >> http://www.openssl.org/docs/crypto/ERR_GET_LIB.html >> >> >>> >>> We still need an answer to "change the API" vs. init on first method. >>> Anyone have strong opinions? >>> >>> Alex >>> >>> >>> On Tue, Aug 27, 2013 at 5:53 AM, Donald Stufft wrote: >>> >>>> >>>> On Aug 27, 2013, at 8:50 AM, Hynek Schlawack wrote: >>>> >>>> >>>> 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? >>>> >>>> >>>> That sounds rather sketchy TBH but I don't know the innards of both. >>>> >>>> >>>> I agree on this sounding sketchy but it might be the best way forward. >>>> >>>> >>>> * 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? >>>> >>>> >>>> I see two options: >>>> >>>> 1. Explicit factory methods. >>>> 2. Init on first use. >>>> >>>> I tend to prefer 1., ideally with separate types. I love me some types. >>>> >>>> >>>> I prefer just init on first use, it's currently setup to switch into >>>> decrypt or encrypt modes based on if you call BlockCipher.decrypt() or >>>> BlockCipher.encrypt() first. FWIW Encrypt/Decrypt mode only makes sense for >>>> certain combinations of things, some block ciphers can use the same >>>> operation. >>>> >>>> >>>> ?h >>>> _______________________________________________ >>>> Cryptography-dev mailing list >>>> Cryptography-dev at python.org >>>> http://mail.python.org/mailman/listinfo/cryptography-dev >>>> >>>> >>>> FWIW there are a few outstanding issues inside the Pull Request >>>> comments as well. >>>> >>>> ----------------- >>>> Donald Stufft >>>> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 >>>> DCFA >>>> >>>> >>>> _______________________________________________ >>>> Cryptography-dev mailing list >>>> Cryptography-dev at python.org >>>> http://mail.python.org/mailman/listinfo/cryptography-dev >>>> >>>> >>> >>> >>> -- >>> "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 >>> >>> _______________________________________________ >>> Cryptography-dev mailing list >>> Cryptography-dev at python.org >>> http://mail.python.org/mailman/listinfo/cryptography-dev >>> >>> >> >> _______________________________________________ >> Cryptography-dev mailing list >> Cryptography-dev at python.org >> http://mail.python.org/mailman/listinfo/cryptography-dev >> >> > > > -- > "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 > > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > http://mail.python.org/mailman/listinfo/cryptography-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: