From paul.l.kehrer at gmail.com Sat Dec 14 05:03:49 2013 From: paul.l.kehrer at gmail.com (Paul Kehrer) Date: Fri, 13 Dec 2013 22:03:49 -0600 Subject: [Cryptography-dev] Jenkins Work In Progress Message-ID: Hey everyone, Some of you may have noticed a flurry of jenkins-related emails from Github going out. I'm currently working on configuring Jenkins so we can do OS X CI. Part of this effort includes a pull request builder (whitelisted to our org for safety for now), but it's not completely configured so don't believe it if it says your PR is passing! I'll send an email out to the list when it's full configured in the next few days. -Paul From jarret.raim at RACKSPACE.COM Tue Dec 17 19:45:12 2013 From: jarret.raim at RACKSPACE.COM (Jarret Raim) Date: Tue, 17 Dec 2013 18:45:12 +0000 Subject: [Cryptography-dev] PyCon & Releases Message-ID: All, Paul (reaperhulk) and I got accepted to do a talk on the ?State of Crypto in Python?. Here is the abstract for our talk: Python has a complex past with cryptography. There are half a dozen major frameworks built on at least three separate C implementations, each with their own strengths and weaknesses and in various states of maintenance. In our development of an open source key management system for OpenStack (Barbican), our team has spent some time investigating the major options including OpenSSL, libnss, nacl and pycrypto on the C side and PyOpenSSL, Pycrypto, python-nss and m2crypto on the Python side. In our research, we noted several challenges with the current crop of libraries including audit state, support for PyPy, maintenance status, etc. In response to this, a group of Python aficionados with more time than sense have begun development of Cryptography (https://github.com/pyca/cryptography). Cryptography is a modern Python crypto library capable of utilizing multiple C backends based on CFFI, thus enabling PyPy use. We will cover the current state of the library, it's goals and design decisions. As part of this effort, Paul, Donald (dstufft) and I were talking a bit about what a release before PyCon would look like. As PyCon is in April, we don?t have a lot of time, but we figured our thinking would be a good place to take up the release discussion again. We came up with 5 areas we wanted to work on pre-release. 1. Recipes We need to define some of the high level API that consumers would actually use. We focused on a two options, hashing and symmetric encryption. - Hashing primitives & HMAC - Non-framed, authenticated encryption: GCM for small files. - Framed, authenticated encryption: GCM for large files. Possibly includes a custom wire format. I think the goal here is a prototype for review rather than something that is usable. 2. Backends We?d like to land at least one new backend. This would help verify that our API is reasonable and nothing OpenSSL specific has managed to creep into the system. The options we came up with are below. We stayed away from C++ since CFFI. - CommonCrypto: Land the osx backend. Requires fixes for the testing infrastructure. - NSS: Easier backend to land as it works on Travis and is C, but isn?t written yet. - DPAPI: ::shudder:: At least it is probably documented, but dev / testing on windows is a question. 3. Documentation We are in okay shape here. Mostly just need to beef it up for new users. - Recipes - Overview / getting started - Examples 4. Packaging Mostly here we need to look at how we package and whether / when it makes sense to move to a sub-package format (e.g. cryptography-openssl or cryptography-nss) 5. Testing Testing is pretty good now, but we need to move most of the jobs to jenkins to scale. We also wanted to add some test types that we aren?t performing now. - Performance - Deep cycle (e.g. Cycle this 1M times and the answer should be X) We also spent some time talking about the preferred test matrix. We currently test (or should be testing against) the following Pythons: 2.6, 2.7, 3.2, 3.3, 3.4, PyPy Each one of those environments should be run on the following platforms: - Windows: 2008 R2 x32, 2008 R2 x64, 2012 x32, 2012 x64 - OSX: 10.8, 10.9 (gcc and clang) For linux, it seemed more important to test against OpenSSL versions rather than distros. The OpenSSL versions still need to be fleshed out, but they should cover the versions from common distros. Our initial list was: - 0.9.8 newest - 1.0.0 newest - 1.0.1 newest In addition to those, we want to cover the versions of OpenSSL shipped in the following distros: - RHEL / Cent 5, 6, 7 - Fedora 19, 20 - Ubuntu 12.04, newest - Debian 6, 7 Thanks, Jarret -- Jarret Raim @jarretraim -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5611 bytes Desc: not available URL: From dreid at dreid.org Tue Dec 17 20:33:54 2013 From: dreid at dreid.org (David Reid) Date: Tue, 17 Dec 2013 11:33:54 -0800 Subject: [Cryptography-dev] PyCon & Releases In-Reply-To: References: Message-ID: From:?Jarret Raim Jarret Raim Reply:?cryptography-dev at python.org cryptography-dev at python.org Date:?December 17, 2013 at 10:47:41 AM To:?cryptography-dev at python.org cryptography-dev at python.org Subject:? [Cryptography-dev] PyCon & Releases All,? Paul (reaperhulk) and I got accepted to do a talk on the ?State of Crypto? in Python?. Here is the abstract for our talk:? Python has a complex past with cryptography. There are half a dozen major? frameworks built on at least three separate C implementations, each with? their own strengths and weaknesses and in various states of maintenance.? In our development of an open source key management system for OpenStack? (Barbican), our team has spent some time investigating the major options? including OpenSSL, libnss, nacl and pycrypto on the C side and PyOpenSSL,? Pycrypto, python-nss and m2crypto on the Python side.? In our research, we noted several challenges with the current crop of? libraries including audit state, support for PyPy, maintenance status,? etc. In response to this, a group of Python aficionados with more time? than sense have begun development of Cryptography? (https://github.com/pyca/cryptography). Cryptography is a modern Python? crypto library capable of utilizing multiple C backends based on CFFI,? thus enabling PyPy use. We will cover the current state of the library,? it's goals and design decisions.? As part of this effort, Paul, Donald (dstufft) and I were talking a bit? about what a release before PyCon would look like. As PyCon is in April,? we don?t have a lot of time, but we figured our thinking would be a good? place to take up the release discussion again.? We came up with 5 areas we wanted to work on pre-release.? 1. Recipes? We need to define some of the high level API that consumers would actually? use. We focused on a two options, hashing and symmetric encryption.? - Hashing primitives & HMAC? Does this mean stdlib compatible hash/hmac interfaces? - Non-framed, authenticated encryption: GCM for small files.? The Fernet implementation is also probably ready to land.? I?m kind of wary of over specifying our own cryptographic protocols. And it?s not clear to me that the tradeoffs between GCM and CBC-HMAC constructions are well understood.? - Framed, authenticated encryption: GCM for large files. Possibly includes? a custom wire format. I think the goal here is a prototype for review? rather than something that is usable.? It?d be nice if all high level recipes which are not implemented for specific compatibility reasons have the capacity for cryptographic agility. 2. Backends? We?d like to land at least one new backend. This would help verify that? our API is reasonable and nothing OpenSSL specific has managed to creep? into the system. The options we came up with are below. We stayed away? from C++ since CFFI.? - CommonCrypto: Land the osx backend. Requires fixes for the testing? infrastructure.? This is the closest? - NSS: Easier backend to land as it works on Travis and is C, but isn?t? written yet.? Also, none of the crypto primitives appear to be documented public API. https://developer.mozilla.org/en-US/docs/NSS#NSS_APIs?"NSS Public Functions" is strictly SSL stuff. - DPAPI: ::shudder:: At least it is probably documented, but dev / testing? on windows is a question. 1.2.3. not it. 3. Documentation? We are in okay shape here. Mostly just need to beef it up for new users.? - Recipes? - Overview / getting started? - Examples? 4. Packaging? Mostly here we need to look at how we package and whether / when it makes? sense to move to a sub-package format (e.g. cryptography-openssl or? cryptography-nss)? 5. Testing? Testing is pretty good now, but we need to move most of the jobs to? jenkins to scale. We also wanted to add some test types that we aren?t? performing now.? - Performance? - Deep cycle (e.g. Cycle this 1M times and the answer should be X)? We also spent some time talking about the preferred test matrix. We? currently test (or should be testing against) the following Pythons:? 2.6, 2.7, 3.2, 3.3, 3.4, PyPy? Each one of those environments should be run on the following platforms:? - Windows: 2008 R2 x32, 2008 R2 x64, 2012 x32, 2012 x64? - OSX: 10.8, 10.9 (gcc and clang)? For linux, it seemed more important to test against OpenSSL versions? rather than distros. The OpenSSL versions still need to be fleshed out,? but they should cover the versions from common distros. Our initial list? was:? - 0.9.8 newest? - 1.0.0 newest? - 1.0.1 newest? In addition to those, we want to cover the versions of OpenSSL shipped in? the following distros:? - RHEL / Cent 5, 6, 7? - Fedora 19, 20? - Ubuntu 12.04, newest? - Debian 6, 7? Thanks,? Jarret? --? Jarret Raim? @jarretraim? - smime.p7s, 8 KB _______________________________________________? Cryptography-dev mailing list? Cryptography-dev at python.org? https://mail.python.org/mailman/listinfo/cryptography-dev? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jarret.raim at RACKSPACE.COM Wed Dec 18 04:56:25 2013 From: jarret.raim at RACKSPACE.COM (Jarret Raim) Date: Wed, 18 Dec 2013 03:56:25 +0000 Subject: [Cryptography-dev] PyCon & Releases In-Reply-To: References: Message-ID: <6824C20A6CE7A44A939B31B7084E5596225F6821@ORD1EXD03.RACKSPACE.CORP> >> 1. Recipes >> >> We need to define some of the high level API that consumers would actually >> use. We focused on a two options, hashing and symmetric encryption. >> >> - Hashing primitives & HMAC > Does this mean stdlib compatible hash/hmac interfaces? We could certainly look at it that way. My thought was mostly just that a hashing recipe seems a simple place to start, but I didn't get much further than that :) >> - Non-framed, authenticated encryption: GCM for small files. > The Fernet implementation is also probably ready to land. > I?m kind of wary of over specifying our own cryptographic protocols. And it?s not clear to me that > the tradeoffs between GCM and CBC-HMAC constructions are well understood. In either construction it seems like we have the same issue. The called can't know if the message passes authentication until the final byte is processed. This makes is hard to just default to GCM as we would have to load the entire file in memory before returning anything. This recipe is specifically to allow for that behavior (e.g. not a streaming interface). Which AEAD we use is a hazmat discussion. We need to have it, but establishing the recipe interface seems like it can happen before that. >> - Framed, authenticated encryption: GCM for large files. Possibly includes >> a custom wire format. I think the goal here is a prototype for review >> rather than something that is usable. > It?d be nice if all high level recipes which are not implemented for specific compatibility reasons have the capacity for cryptographic agility. I think I agree. See what I said above and see if that jives for you. 2. Backends >> - CommonCrypto: Land the osx backend. Requires fixes for the testing >> infrastructure. > This is the closest Right. Paul has an implementation that is somewhat tracking head, but if we landed it, it would break our testing. We need to modify the testing to allow for running selected parts of the suite (for performance) and some kind of skipif behavior based on backend / platform. >> - NSS: Easier backend to land as it works on Travis and is C, but isn?t >> written yet. > Also, none of the crypto primitives appear to be documented public API. > https://developer.mozilla.org/en-US/docs/NSS#NSS_APIs "NSS Public Functions" is strictly SSL stuff. Yeah, I was afraid of that. Jarret -- Jarret Raim @jarretraim ________________________________________ - smime.p7s, 8 KB _______________________________________________ Cryptography-dev mailing list Cryptography-dev at python.org https://mail.python.org/mailman/listinfo/cryptography-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6087 bytes Desc: not available URL: From alexs at prol.etari.at Wed Dec 18 11:32:44 2013 From: alexs at prol.etari.at (alexs) Date: Wed, 18 Dec 2013 10:32:44 +0000 Subject: [Cryptography-dev] PyCon & Releases In-Reply-To: References: Message-ID: On 17.12.2013 19:33, David Reid wrote: > From: Jarret Raim Jarret Raim [1] > Reply: cryptography-dev at python.org cryptography-dev at python.org [2] > Date: December 17, 2013 at 10:47:41 AM > To: cryptography-dev at python.org cryptography-dev at python.org [3] > Subject: [Cryptography-dev] PyCon & Releases > >> All, >> >> Paul (reaperhulk) and I got accepted to do a talk on the ?State of >> Crypto >> in Python?. Here is the abstract for our talk: Congratulations :) >> >> As part of this effort, Paul, Donald (dstufft) and I were talking a >> bit >> >> about what a release before PyCon would look like. As PyCon is in >> April, >> we don?t have a lot of time, but we figured our thinking would be a >> good >> place to take up the release discussion again. >> >> We came up with 5 areas we wanted to work on pre-release. >> >> 1. Recipes >> >> We need to define some of the high level API that consumers would >> actually >> use. We focused on a two options, hashing and symmetric encryption. >> >> - Hashing primitives & HMAC > > Does this mean stdlib compatible hash/hmac interfaces? I would like to see this also. The stdlib API is fairly sane. I think the main blocker on this is likely to be working out what algorithms the chosen backend actually supports for populating hashlib.algorithms and making hashlib.new work? AIUI we don't make any effort to detect support currently so if some enterprising individual decides to compile OpenSSL with e.g. -DOPENSSL_NO_MD5 we won't throw errors until someone actually attempts to hash something. >> - Non-framed, authenticated encryption: GCM for small files. > > The Fernet implementation is also probably ready to land. > > I'm kind of wary of over specifying our own cryptographic protocols. > And > it's not clear to me that the tradeoffs between GCM and CBC-HMAC > constructions are well understood. > >> - Framed, authenticated encryption: GCM for large files. Possibly >> includes >> a custom wire format. I think the goal here is a prototype for >> review >> rather than something that is usable. > > It'd be nice if all high level recipes which are not implemented for > specific compatibility reasons have the capacity for cryptographic > agility. I might be misunderstanding this but I'm not sure what the motivation is for adding our own protocols. Are there any particular use cases we are targeting that aren't served by supporting existing specifications? >> 2. Backends >> >> We?d like to land at least one new backend. This would help verify >> that >> our API is reasonable and nothing OpenSSL specific has managed to >> creep >> into the system. The options we came up with are below. We stayed >> away >> from C++ since CFFI. >> >> - CommonCrypto: Land the osx backend. Requires fixes for the testing >> infrastructure. > > This is the closest > >> - NSS: Easier backend to land as it works on Travis and is C, but >> isn?t >> written yet. > > Also, none of the crypto primitives appear to be documented public > API. > https://developer.mozilla.org/en-US/docs/NSS#NSS_APIs "NSS Public > Functions" is strictly SSL stuff. Botan and PolarSSL look like good candidates in terms of being actually decent crypto libraries. I don't know much about Windows. Does DPAPI offer some handy key management stuff or something else that might make people actually want to use it? From alex.gaynor at gmail.com Wed Dec 18 16:14:02 2013 From: alex.gaynor at gmail.com (Alex Gaynor) Date: Wed, 18 Dec 2013 07:14:02 -0800 Subject: [Cryptography-dev] PyCon & Releases In-Reply-To: References: Message-ID: PolarSSL is GPL, so we almost certainly can't include it as part of cryptography itself (I'm not a lawyer, this isn't legal advice, etc.) Alex On Wed, Dec 18, 2013 at 2:32 AM, alexs wrote: > On 17.12.2013 19:33, David Reid wrote: > > From: Jarret Raim Jarret Raim [1] >> Reply: cryptography-dev at python.org cryptography-dev at python.org [2] >> >> Date: December 17, 2013 at 10:47:41 AM >> To: cryptography-dev at python.org cryptography-dev at python.org [3] >> >> Subject: [Cryptography-dev] PyCon & Releases >> >> All, >>> >>> Paul (reaperhulk) and I got accepted to do a talk on the ?State of >>> Crypto >>> in Python?. Here is the abstract for our talk: >>> >> > Congratulations :) > > >>> >> > As part of this effort, Paul, Donald (dstufft) and I were talking a bit >>> >>> about what a release before PyCon would look like. As PyCon is in >>> April, >>> we don?t have a lot of time, but we figured our thinking would be a >>> good >>> place to take up the release discussion again. >>> >>> We came up with 5 areas we wanted to work on pre-release. >>> >>> 1. Recipes >>> >>> We need to define some of the high level API that consumers would >>> actually >>> use. We focused on a two options, hashing and symmetric encryption. >>> >>> - Hashing primitives & HMAC >>> >> >> Does this mean stdlib compatible hash/hmac interfaces? >> > > I would like to see this also. The stdlib API is fairly sane. I think the > main blocker on this is likely to be working out what algorithms the > chosen backend > actually supports for populating hashlib.algorithms and making hashlib.new > work? > > AIUI we don't make any effort to detect support currently so if some > enterprising individual decides to compile OpenSSL with e.g. > -DOPENSSL_NO_MD5 > we won't throw errors until someone actually attempts to hash something. > > > - Non-framed, authenticated encryption: GCM for small files. >>> >> >> The Fernet implementation is also probably ready to land. >> >> I'm kind of wary of over specifying our own cryptographic protocols. And >> it's not clear to me that the tradeoffs between GCM and CBC-HMAC >> constructions are well understood. >> >> - Framed, authenticated encryption: GCM for large files. Possibly >>> includes >>> a custom wire format. I think the goal here is a prototype for review >>> rather than something that is usable. >>> >> >> It'd be nice if all high level recipes which are not implemented for >> specific compatibility reasons have the capacity for cryptographic >> agility. >> > > I might be misunderstanding this but I'm not sure what the motivation is > for adding our own protocols. > > Are there any particular use cases we are targeting that aren't served by > supporting existing > specifications? > > > 2. Backends >>> >>> We?d like to land at least one new backend. This would help verify that >>> our API is reasonable and nothing OpenSSL specific has managed to creep >>> into the system. The options we came up with are below. We stayed away >>> from C++ since CFFI. >>> >>> - CommonCrypto: Land the osx backend. Requires fixes for the testing >>> infrastructure. >>> >> >> This is the closest >> >> - NSS: Easier backend to land as it works on Travis and is C, but isn?t >>> written yet. >>> >> >> Also, none of the crypto primitives appear to be documented public API. >> > > https://developer.mozilla.org/en-US/docs/NSS#NSS_APIs "NSS Public >> Functions" is strictly SSL stuff. >> > > Botan and PolarSSL look like good candidates in terms of being actually > decent crypto libraries. > > I don't know much about Windows. Does DPAPI offer some handy key > management stuff or something else that might make people actually want to > use it? > > > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > https://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 alexs at prol.etari.at Wed Dec 18 16:35:12 2013 From: alexs at prol.etari.at (alexs) Date: Wed, 18 Dec 2013 15:35:12 +0000 Subject: [Cryptography-dev] PyCon & Releases In-Reply-To: References: Message-ID: On 18.12.2013 15:14, Alex Gaynor wrote: > PolarSSL is GPL, so we almost certainly can't include it as part of > cryptography itself (I'm not a lawyer, this isn't legal advice, etc.) I hadn't looked into the license in much detail but it turns out they've found a way to make dual-licensed GPL libraries even more annoying. They have some sort of "FOSS License Exception" thing that I think is intended to make it clear that using PolarSSL within a BSD, APL etc app is acceptable? https://polarssl.org/foss-license-exception Which mostly seems fair, except for this innovation: > The Derivative Work does not include any work licensed under the GPL > other than the Program; Which I guess means if you wanted to also support another project that had a similar GPL linking exception in you would void this license? Probably best not to try and support this in the main tree for now :-/ > On Wed, Dec 18, 2013 at 2:32 AM, alexs > wrote: > >> On 17.12.2013 19:33, David Reid wrote: >> >>> From: Jarret Raim Jarret Raim [1] >>> Reply: cryptography-dev at python.org [1] cryptography-dev at python.org >>> [2][2] >>> >>> Date: December 17, 2013 at 10:47:41 AM To: >>> cryptography-dev at python.org [3] cryptography-dev at python.org [4][3] >>> >>> Subject: [Cryptography-dev] PyCon & Releases >>> >>>> All, >>>> >>>> Paul (reaperhulk) and I got accepted to do a talk on the ?State >>>> of >>>> Crypto >>>> in Python?. Here is the abstract for our talk: >> >> Congratulations :) >> >>> >> >> As part of this effort, Paul, Donald (dstufft) and I were talking a >> bit >> >> about what a release before PyCon would look like. As PyCon is in >> April, >> we don?t have a l >> >>> . >>> >>> We came up with 5 areas we wanted to work on pre-release. >>> >>> 1. Recipes >>> >>> We need to define some of the high level API that consumers would >>> actually >>> use. We focused on a two options, hashing and symmetric encryption. >>> >>> - Hashing primitives & HMAC >>> Does this mean stdlib compatible hash/hmac interfaces? I would like >>> to see this also. The stdlib API is fairly sane. I think the >>> main blocker on this is likely to be working out what algorithms >>> the >>> chosen backend >>> actually supports for populating hashlib.algorithms and making >>> hashlib.new work? >>> >>> AIUI we don't make any effort to detect support currently so if >>> some >>> enterprising individual decides to compile OpenSSL with e.g >> O_MD5 >> we won't throw errors until someone actually attempts to hash >> something. >> >> - Non-framed, authenticated encryption: GCM for small files. >> The Fernet implementation is also probably ready to land. >> >> I'm kind of wary of over specifying our own cryptographic protocols. >> And >> it's not clear to me that the tradeoffs between GCM and CBC-HMAC >> >>> er-left: 1px #ccc solid; padding-left: 1ex;">- Framed, >>> authenticated >>> encryption: GCM for large files. Possibly >>> includes >>> a custom wire format. I think the goal here is a prototype for >>> review >>> rather than something that is usable. >>> It'd be nice if all high level recipes which are not implemented >>> for >>> specific compatibility reasons have the capacity for cryptographic >>> agility. I might be misunderstanding this but I'm not sure what the >>> motivation is for adding our own protocols. >>> >>> Are there any particular use cases we are targeting that aren't >>> served by supporting existing >>> specifications? >>> >>> 2. Backends >> like to land at least one new backend. This would help verify that >> our API is reasonable and nothing OpenSSL specific has managed to >> creep >> into the system. The options we came up with are below. We stayed >> away >> from C++ since CFFI. >> >> - CommonCrypto: Land the osx backend. Requires fixes for the testing >> infrastructure. >> This is the closest >> >>> t: 1ex;">- NSS: Easier backend to land as it works on Travis and is >>> C, but isn?t >>> written yet. >>> Also, none of the crypto primitives appear to be documented public >>> API. >>> >>>> https://developer.mozilla.org/en-US/docs/NSS#NSS_APIs [5] "NSS >>>> Public Functions" is strictly SSL stuff. >>> Botan and PolarSSL look like good candidates in terms of being >>> actually decent crypto libraries. >>> >>> I don't know much about Windows. Does DPAPI offer some handy key >>> management stuff or something else that might make people actually >>> want to use it? >>> >> _______________________________________________ >> Cryptography-dev mailing list >> Cryptography-dev at python.org [6] >> https://mail.python.org/mailman/l >> >>> > > -- > > "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 Links: ------ [1] mailto:cryptography-dev at python.org [2] mailto:cryptography-dev at python.org [3] mailto:cryptography-dev at python.org [4] mailto:cryptography-dev at python.org [5] https://developer.mozilla.org/en-US/docs/NSS#NSS_APIs [6] mailto:Cryptography-dev at python.org [7] mailto:alexs at prol.etari.at From alex.gaynor at gmail.com Wed Dec 18 16:36:49 2013 From: alex.gaynor at gmail.com (Alex Gaynor) Date: Wed, 18 Dec 2013 07:36:49 -0800 Subject: [Cryptography-dev] PyCon & Releases In-Reply-To: References: Message-ID: Even if this were legally well founded (no clue if it is or not), cryptography isn't an end user application, it's linked into the users program, and this would make it way too easy for them to shoot themselves in the feet. Alex On Wed, Dec 18, 2013 at 7:35 AM, alexs wrote: > On 18.12.2013 15:14, Alex Gaynor wrote: > > PolarSSL is GPL, so we almost certainly can't include it as part of >> cryptography itself (I'm not a lawyer, this isn't legal advice, etc.) >> > > I hadn't looked into the license in much detail but it turns out they've > found a way to make dual-licensed GPL libraries even more annoying. > > They have some sort of "FOSS License Exception" thing that I think > is intended to make it clear that using PolarSSL within a BSD, APL etc app > is acceptable? > > https://polarssl.org/foss-license-exception > > Which mostly seems fair, except for this innovation: > > The Derivative Work does not include any work licensed under the GPL >> other than the Program; >> > > Which I guess means if you wanted to also support another project that had > a similar GPL linking exception in you would void this license? > > Probably best not to try and support this in the main tree for now :-/ > > On Wed, Dec 18, 2013 at 2:32 AM, alexs wrote: >> >> On 17.12.2013 19:33, David Reid wrote: >>> >>> From: Jarret Raim Jarret Raim [1] >>>> Reply: cryptography-dev at python.org [1] cryptography-dev at python.org >>>> [2][2] >>>> >>>> >>>> Date: December 17, 2013 at 10:47:41 AM To: >>>> cryptography-dev at python.org [3] cryptography-dev at python.org [4][3] >>>> >>>> >>>> Subject: [Cryptography-dev] PyCon & Releases >>>> >>>> All, >>>>> >>>>> Paul (reaperhulk) and I got accepted to do a talk on the ?State >>>>> of >>>>> Crypto >>>>> in Python?. Here is the abstract for our talk: >>>>> >>>> >>> Congratulations :) >>> >>> >>>> >>> As part of this effort, Paul, Donald (dstufft) and I were talking a >>> bit >>> >>> about what a release before PyCon would look like. As PyCon is in >>> April, >>> we don?t have a l >>> >>> . >>>> >>>> We came up with 5 areas we wanted to work on pre-release. >>>> >>>> 1. Recipes >>>> >>>> We need to define some of the high level API that consumers would >>>> actually >>>> use. We focused on a two options, hashing and symmetric encryption. >>>> >>>> - Hashing primitives & HMAC >>>> Does this mean stdlib compatible hash/hmac interfaces? I would like >>>> to see this also. The stdlib API is fairly sane. I think the >>>> main blocker on this is likely to be working out what algorithms the >>>> chosen backend >>>> actually supports for populating hashlib.algorithms and making >>>> hashlib.new work? >>>> >>>> AIUI we don't make any effort to detect support currently so if some >>>> enterprising individual decides to compile OpenSSL with e.g >>>> >>> O_MD5 >>> >>> we won't throw errors until someone actually attempts to hash >>> something. >>> >>> - Non-framed, authenticated encryption: GCM for small files. >>> The Fernet implementation is also probably ready to land. >>> >>> I'm kind of wary of over specifying our own cryptographic protocols. >>> And >>> it's not clear to me that the tradeoffs between GCM and CBC-HMAC >>> >>> er-left: 1px #ccc solid; padding-left: 1ex;">- Framed, authenticated >>>> >>>> encryption: GCM for large files. Possibly >>>> includes >>>> a custom wire format. I think the goal here is a prototype for >>>> review >>>> rather than something that is usable. >>>> It'd be nice if all high level recipes which are not implemented for >>>> specific compatibility reasons have the capacity for cryptographic >>>> agility. I might be misunderstanding this but I'm not sure what the >>>> motivation is for adding our own protocols. >>>> >>>> Are there any particular use cases we are targeting that aren't >>>> served by supporting existing >>>> specifications? >>>> >>>> 2. Backends >>>> >>> like to land at least one new backend. This would help verify that >>> >>> our API is reasonable and nothing OpenSSL specific has managed to >>> creep >>> into the system. The options we came up with are below. We stayed away >>> from C++ since CFFI. >>> >>> - CommonCrypto: Land the osx backend. Requires fixes for the testing >>> infrastructure. >>> This is the closest >>> >>> t: 1ex;">- NSS: Easier backend to land as it works on Travis and is >>>> >>>> C, but isn?t >>>> written yet. >>>> Also, none of the crypto primitives appear to be documented public >>>> API. >>>> >>>> https://developer.mozilla.org/en-US/docs/NSS#NSS_APIs [5] "NSS >>>>> >>>>> Public Functions" is strictly SSL stuff. >>>>> >>>> Botan and PolarSSL look like good candidates in terms of being >>>> actually decent crypto libraries. >>>> >>>> I don't know much about Windows. Does DPAPI offer some handy key >>>> management stuff or something else that might make people actually >>>> want to use it? >>>> >>>> _______________________________________________ >>> Cryptography-dev mailing list >>> Cryptography-dev at python.org [6] >>> https://mail.python.org/mailman/l >>> >>> >>>> >> -- >> >> "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 >> > > > > Links: > ------ > [1] mailto:cryptography-dev at python.org > [2] mailto:cryptography-dev at python.org > [3] mailto:cryptography-dev at python.org > [4] mailto:cryptography-dev at python.org > [5] https://developer.mozilla.org/en-US/docs/NSS#NSS_APIs > [6] mailto:Cryptography-dev at python.org > [7] mailto:alexs at prol.etari.at > > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > https://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 Dec 19 19:41:14 2013 From: donald at stufft.io (Donald Stufft) Date: Thu, 19 Dec 2013 13:41:14 -0500 Subject: [Cryptography-dev] PyCon & Releases In-Reply-To: References: Message-ID: <21D65556-5BC9-4C96-89BC-879AFCB26041@stufft.io> Having an externally packaged backend would probably be useful in a validate that this is actually possible and reasonable to do sort of thing. On Dec 18, 2013, at 10:36 AM, Alex Gaynor wrote: > Even if this were legally well founded (no clue if it is or not), cryptography isn't an end user application, it's linked into the users program, and this would make it way too easy for them to shoot themselves in the feet. > > Alex > > > On Wed, Dec 18, 2013 at 7:35 AM, alexs wrote: > On 18.12.2013 15:14, Alex Gaynor wrote: > > PolarSSL is GPL, so we almost certainly can't include it as part of > cryptography itself (I'm not a lawyer, this isn't legal advice, etc.) > > I hadn't looked into the license in much detail but it turns out they've found a way to make dual-licensed GPL libraries even more annoying. > > They have some sort of "FOSS License Exception" thing that I think > is intended to make it clear that using PolarSSL within a BSD, APL etc app is acceptable? > > https://polarssl.org/foss-license-exception > > Which mostly seems fair, except for this innovation: > > The Derivative Work does not include any work licensed under the GPL other than the Program; > > Which I guess means if you wanted to also support another project that had a similar GPL linking exception in you would void this license? > > Probably best not to try and support this in the main tree for now :-/ > > On Wed, Dec 18, 2013 at 2:32 AM, alexs wrote: > > On 17.12.2013 19:33, David Reid wrote: > > From: Jarret Raim Jarret Raim [1] > Reply: cryptography-dev at python.org [1] cryptography-dev at python.org > [2][2] > > > Date: December 17, 2013 at 10:47:41 AM To: > cryptography-dev at python.org [3] cryptography-dev at python.org [4][3] > > > Subject: [Cryptography-dev] PyCon & Releases > > All, > > Paul (reaperhulk) and I got accepted to do a talk on the ?State > of > Crypto > in Python?. Here is the abstract for our talk: > > Congratulations :) > > > > As part of this effort, Paul, Donald (dstufft) and I were talking a > bit > > about what a release before PyCon would look like. As PyCon is in > April, > we don?t have a l > > . > > We came up with 5 areas we wanted to work on pre-release. > > 1. Recipes > > We need to define some of the high level API that consumers would > actually > use. We focused on a two options, hashing and symmetric encryption. > > - Hashing primitives & HMAC > Does this mean stdlib compatible hash/hmac interfaces? I would like > to see this also. The stdlib API is fairly sane. I think the > main blocker on this is likely to be working out what algorithms the > chosen backend > actually supports for populating hashlib.algorithms and making > hashlib.new work? > > AIUI we don't make any effort to detect support currently so if some > enterprising individual decides to compile OpenSSL with e.g > O_MD5 > > we won't throw errors until someone actually attempts to hash > something. > > - Non-framed, authenticated encryption: GCM for small files. > The Fernet implementation is also probably ready to land. > > I'm kind of wary of over specifying our own cryptographic protocols. > And > it's not clear to me that the tradeoffs between GCM and CBC-HMAC > > er-left: 1px #ccc solid; padding-left: 1ex;">- Framed, authenticated > > encryption: GCM for large files. Possibly > includes > a custom wire format. I think the goal here is a prototype for > review > rather than something that is usable. > It'd be nice if all high level recipes which are not implemented for > specific compatibility reasons have the capacity for cryptographic > agility. I might be misunderstanding this but I'm not sure what the > motivation is for adding our own protocols. > > Are there any particular use cases we are targeting that aren't > served by supporting existing > specifications? > > 2. Backends > like to land at least one new backend. This would help verify that > > our API is reasonable and nothing OpenSSL specific has managed to > creep > into the system. The options we came up with are below. We stayed away > from C++ since CFFI. > > - CommonCrypto: Land the osx backend. Requires fixes for the testing > infrastructure. > This is the closest > > t: 1ex;">- NSS: Easier backend to land as it works on Travis and is > > C, but isn?t > written yet. > Also, none of the crypto primitives appear to be documented public > API. > > https://developer.mozilla.org/en-US/docs/NSS#NSS_APIs [5] "NSS > > Public Functions" is strictly SSL stuff. > Botan and PolarSSL look like good candidates in terms of being > actually decent crypto libraries. > > I don't know much about Windows. Does DPAPI offer some handy key > management stuff or something else that might make people actually > want to use it? > > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org [6] > https://mail.python.org/mailman/l > > > > -- > > "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 > > > > Links: > ------ > [1] mailto:cryptography-dev at python.org > [2] mailto:cryptography-dev at python.org > [3] mailto:cryptography-dev at python.org > [4] mailto:cryptography-dev at python.org > [5] https://developer.mozilla.org/en-US/docs/NSS#NSS_APIs > [6] mailto:Cryptography-dev at python.org > [7] mailto:alexs at prol.etari.at > > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > https://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 > https://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 Dec 19 19:49:18 2013 From: alex.gaynor at gmail.com (Alex Gaynor) Date: Thu, 19 Dec 2013 10:49:18 -0800 Subject: [Cryptography-dev] PyCon & Releases In-Reply-To: <21D65556-5BC9-4C96-89BC-879AFCB26041@stufft.io> References: <21D65556-5BC9-4C96-89BC-879AFCB26041@stufft.io> Message-ID: Doesn't seem like the type of thing that needs to block the initial release. Alex On Thu, Dec 19, 2013 at 10:41 AM, Donald Stufft wrote: > Having an externally packaged backend would probably be useful in a > validate that this is actually possible and reasonable to do sort of thing. > > On Dec 18, 2013, at 10:36 AM, Alex Gaynor wrote: > > Even if this were legally well founded (no clue if it is or not), > cryptography isn't an end user application, it's linked into the users > program, and this would make it way too easy for them to shoot themselves > in the feet. > > Alex > > > On Wed, Dec 18, 2013 at 7:35 AM, alexs wrote: > >> On 18.12.2013 15:14, Alex Gaynor wrote: >> >> PolarSSL is GPL, so we almost certainly can't include it as part of >>> cryptography itself (I'm not a lawyer, this isn't legal advice, etc.) >>> >> >> I hadn't looked into the license in much detail but it turns out they've >> found a way to make dual-licensed GPL libraries even more annoying. >> >> They have some sort of "FOSS License Exception" thing that I think >> is intended to make it clear that using PolarSSL within a BSD, APL etc >> app is acceptable? >> >> https://polarssl.org/foss-license-exception >> >> Which mostly seems fair, except for this innovation: >> >> The Derivative Work does not include any work licensed under the GPL >>> other than the Program; >>> >> >> Which I guess means if you wanted to also support another project that >> had a similar GPL linking exception in you would void this license? >> >> Probably best not to try and support this in the main tree for now :-/ >> >> On Wed, Dec 18, 2013 at 2:32 AM, alexs wrote: >>> >>> On 17.12.2013 19:33, David Reid wrote: >>>> >>>> From: Jarret Raim Jarret Raim [1] >>>>> Reply: cryptography-dev at python.org [1] cryptography-dev at python.org >>>>> [2][2] >>>>> >>>>> >>>>> Date: December 17, 2013 at 10:47:41 AM To: >>>>> cryptography-dev at python.org [3] cryptography-dev at python.org [4][3] >>>>> >>>>> >>>>> Subject: [Cryptography-dev] PyCon & Releases >>>>> >>>>> All, >>>>>> >>>>>> Paul (reaperhulk) and I got accepted to do a talk on the ?State >>>>>> of >>>>>> Crypto >>>>>> in Python?. Here is the abstract for our talk: >>>>>> >>>>> >>>> Congratulations :) >>>> >>>> >>>>> >>>> As part of this effort, Paul, Donald (dstufft) and I were talking a >>>> bit >>>> >>>> about what a release before PyCon would look like. As PyCon is in >>>> April, >>>> we don?t have a l >>>> >>>> . >>>>> >>>>> We came up with 5 areas we wanted to work on pre-release. >>>>> >>>>> 1. Recipes >>>>> >>>>> We need to define some of the high level API that consumers would >>>>> actually >>>>> use. We focused on a two options, hashing and symmetric encryption. >>>>> >>>>> - Hashing primitives & HMAC >>>>> Does this mean stdlib compatible hash/hmac interfaces? I would like >>>>> to see this also. The stdlib API is fairly sane. I think the >>>>> main blocker on this is likely to be working out what algorithms the >>>>> chosen backend >>>>> actually supports for populating hashlib.algorithms and making >>>>> hashlib.new work? >>>>> >>>>> AIUI we don't make any effort to detect support currently so if some >>>>> enterprising individual decides to compile OpenSSL with e.g >>>>> >>>> O_MD5 >>>> >>>> we won't throw errors until someone actually attempts to hash >>>> something. >>>> >>>> - Non-framed, authenticated encryption: GCM for small files. >>>> The Fernet implementation is also probably ready to land. >>>> >>>> I'm kind of wary of over specifying our own cryptographic protocols. >>>> And >>>> it's not clear to me that the tradeoffs between GCM and CBC-HMAC >>>> >>>> er-left: 1px #ccc solid; padding-left: 1ex;">- Framed, authenticated >>>>> >>>>> encryption: GCM for large files. Possibly >>>>> includes >>>>> a custom wire format. I think the goal here is a prototype for >>>>> review >>>>> rather than something that is usable. >>>>> It'd be nice if all high level recipes which are not implemented for >>>>> specific compatibility reasons have the capacity for cryptographic >>>>> agility. I might be misunderstanding this but I'm not sure what the >>>>> motivation is for adding our own protocols. >>>>> >>>>> Are there any particular use cases we are targeting that aren't >>>>> served by supporting existing >>>>> specifications? >>>>> >>>>> 2. Backends >>>>> >>>> like to land at least one new backend. This would help verify that >>>> >>>> our API is reasonable and nothing OpenSSL specific has managed to >>>> creep >>>> into the system. The options we came up with are below. We stayed away >>>> from C++ since CFFI. >>>> >>>> - CommonCrypto: Land the osx backend. Requires fixes for the testing >>>> infrastructure. >>>> This is the closest >>>> >>>> t: 1ex;">- NSS: Easier backend to land as it works on Travis and is >>>>> >>>>> C, but isn?t >>>>> written yet. >>>>> Also, none of the crypto primitives appear to be documented public >>>>> API. >>>>> >>>>> https://developer.mozilla.org/en-US/docs/NSS#NSS_APIs [5] "NSS >>>>>> >>>>>> Public Functions" is strictly SSL stuff. >>>>>> >>>>> Botan and PolarSSL look like good candidates in terms of being >>>>> actually decent crypto libraries. >>>>> >>>>> I don't know much about Windows. Does DPAPI offer some handy key >>>>> management stuff or something else that might make people actually >>>>> want to use it? >>>>> >>>>> _______________________________________________ >>>> Cryptography-dev mailing list >>>> Cryptography-dev at python.org [6] >>>> https://mail.python.org/mailman/l >>>> >>>> >>>>> >>> -- >>> >>> "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 >>> >> >> >> >> Links: >> ------ >> [1] mailto:cryptography-dev at python.org >> [2] mailto:cryptography-dev at python.org >> [3] mailto:cryptography-dev at python.org >> [4] mailto:cryptography-dev at python.org >> [5] https://developer.mozilla.org/en-US/docs/NSS#NSS_APIs >> [6] mailto:Cryptography-dev at python.org >> [7] mailto:alexs at prol.etari.at >> >> _______________________________________________ >> Cryptography-dev mailing list >> Cryptography-dev at python.org >> https://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 > https://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 > https://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 alex.gaynor at gmail.com Tue Dec 31 00:01:34 2013 From: alex.gaynor at gmail.com (Alex Gaynor) Date: Mon, 30 Dec 2013 15:01:34 -0800 Subject: [Cryptography-dev] First release -- asymmetric? Message-ID: Hey all, What do people think of the idea of us doing our first release without having any asymmetric support? The motivation here would be to allow us to get our initial release out sooner, addressing the following concerns: - pyOpenSSL! (specifically on PyPy) - Crypto on py3k and on PyPy - GCM support - A safe recipe for symmetric encryption. What do folks think about this idea? 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 Dec 31 00:59:35 2013 From: hs at ox.cx (Hynek Schlawack) Date: Tue, 31 Dec 2013 00:59:35 +0100 Subject: [Cryptography-dev] First release -- asymmetric? In-Reply-To: References: Message-ID: On 31 Dec 2013, at 0:01, Alex Gaynor wrote: > What do people think of the idea of us doing our first release without > having any asymmetric support? > > The motivation here would be to allow us to get our initial release out > sooner, addressing the following concerns: > > - pyOpenSSL! (specifically on PyPy) > - Crypto on py3k and on PyPy > - GCM support > - A safe recipe for symmetric encryption. > > What do folks think about this idea? Actually, why not? We ?just? need to be half-way sure that those points you mentioned don?t change while implementing asymmetric encryption because I?d really not like to break compatibility at any point. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: OpenPGP digital signature URL: From donald at stufft.io Tue Dec 31 01:17:43 2013 From: donald at stufft.io (Donald Stufft) Date: Mon, 30 Dec 2013 19:17:43 -0500 Subject: [Cryptography-dev] First release -- asymmetric? In-Reply-To: References: Message-ID: I?m personally fine without any asymmetric for the first release with Hynek?s concern mirrored about wanting to change the symmetric APIs with our experience in asymmetric. On Dec 30, 2013, at 6:59 PM, Hynek Schlawack wrote: > On 31 Dec 2013, at 0:01, Alex Gaynor wrote: > >> What do people think of the idea of us doing our first release without >> having any asymmetric support? >> >> The motivation here would be to allow us to get our initial release out >> sooner, addressing the following concerns: >> >> - pyOpenSSL! (specifically on PyPy) >> - Crypto on py3k and on PyPy >> - GCM support >> - A safe recipe for symmetric encryption. >> >> What do folks think about this idea? > > Actually, why not? We ?just? need to be half-way sure that those points you mentioned don?t change while implementing asymmetric encryption because I?d really not like to break compatibility at any point._______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > https://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 Tue Dec 31 21:05:48 2013 From: paul.l.kehrer at gmail.com (Paul Kehrer) Date: Tue, 31 Dec 2013 14:05:48 -0600 Subject: [Cryptography-dev] First release -- asymmetric? In-Reply-To: References: Message-ID: I am also okay with a preliminary release sans asymmetric. Looking through our currently open PRs we need to resolve the following items prior to release: CSPRNG (https://github.com/pyca/cryptography/pull/377) Are we going to release with the standard CSPRNG or the engine approach? I know we're waiting on feedback from people around this, but I think this is a blocker. Windows Support (https://github.com/pyca/cryptography/pull/322) We don't currently compile on Windows. We have a PR for it, but our test infrastructure is not fully built (yet) so we haven't landed the patch. Secondary Backend (https://github.com/pyca/cryptography/pull/344) Should we land CommonCrypto? It's nice to have a secondary backend to ensure we don't allow anything OpenSSL-specific to creep into the primitives, but I would be okay with it not landing until the next release. Thread Safety (https://github.com/pyca/cryptography/pull/352) This definitely needs to be resolved. Error Handling (https://github.com/pyca/cryptography/pull/359) There is a PR outstanding to convert our assert-based errors to methods that check ERR_get_error(). This might be helpful to have in the first release to get better error information back from early adopters. -Paul On Mon, Dec 30, 2013 at 6:17 PM, Donald Stufft wrote: > I?m personally fine without any asymmetric for the first release with Hynek?s > concern mirrored about wanting to change the symmetric APIs with our > experience in asymmetric. > > On Dec 30, 2013, at 6:59 PM, Hynek Schlawack wrote: > >> On 31 Dec 2013, at 0:01, Alex Gaynor wrote: >> >>> What do people think of the idea of us doing our first release without >>> having any asymmetric support? >>> >>> The motivation here would be to allow us to get our initial release out >>> sooner, addressing the following concerns: >>> >>> - pyOpenSSL! (specifically on PyPy) >>> - Crypto on py3k and on PyPy >>> - GCM support >>> - A safe recipe for symmetric encryption. >>> >>> What do folks think about this idea? >> >> Actually, why not? We ?just? need to be half-way sure that those points you mentioned don?t change while implementing asymmetric encryption because I?d really not like to break compatibility at any point._______________________________________________ >> Cryptography-dev mailing list >> Cryptography-dev at python.org >> https://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 > https://mail.python.org/mailman/listinfo/cryptography-dev > From dreid at dreid.org Tue Dec 31 22:50:02 2013 From: dreid at dreid.org (David Reid) Date: Tue, 31 Dec 2013 13:50:02 -0800 Subject: [Cryptography-dev] First release -- asymmetric? In-Reply-To: References: Message-ID: +1 to sans asymmetric release. With some comments inline. --? David Reid From:?Paul Kehrer Paul Kehrer Reply:?cryptography-dev at python.org cryptography-dev at python.org Date:?December 31, 2013 at 12:05:57 PM To:?cryptography-dev at python.org cryptography-dev at python.org Subject:? Re: [Cryptography-dev] First release -- asymmetric? I am also okay with a preliminary release sans asymmetric.? Looking through our currently open PRs we need to resolve the? following items prior to release:? CSPRNG (https://github.com/pyca/cryptography/pull/377)? Are we going to release with the standard CSPRNG or the engine? approach? I know we're waiting on feedback from people around this,? but I think this is a blocker.? zooko on IRC managed to convince me that the system random engine is a good solution, here is an excerpt from that conversation. [19:28:35] So you'd be surprised if it were (by default) using /dev/urandom or the CryptGenRandom on Windows instead of using the OpenSSL userspace PRNG? [19:30:30] But you'd be even more surprised if you fork()'ed and cryptography.io leaked your secrets? ? [19:37:24] There's a problem with /dev/urandom, but it is also, I assume, a problem with the OpenSSL CSPRNG, which is: what to do if the pool has never yet been initialized with unguessable values? [19:37:45] If forced to choose right now without further study, I would choose to rely on /dev/urandom. [19:49:10] dreid: let me emphasize that the issue about uninitialized PRNGs is a serious issue. [19:49:40] I think it is probably responsible for most of this mess: https://factorable.net/ [19:50:02] zooko: Yeah, my initial inclination was to thoroughly document the issues, and provide an escape hatch. [19:50:11] Unfortunately, it gets conflated with the notion of "running out of real entropy" and the whole idea of /dev/random. [19:50:30] Which is one of those things that I just get too frustrated about to contribute productively to discussions of it. [19:51:13] But what's the escape hatch? [19:51:24] I assume the same issue affects the OpenSSL PRNG, but I haven't investigated that. Windows Support (https://github.com/pyca/cryptography/pull/322)? We don't currently compile on Windows. We have a PR for it, but our? test infrastructure is not fully built (yet) so we haven't landed the? patch.? I?m OK with not having windows support for the I don?t know, 0.0.1 release?? If we do that we should make sure we purge stuff of partial support (like the random engine stuff?) Secondary Backend (https://github.com/pyca/cryptography/pull/344)? Should we land CommonCrypto? It's nice to have a secondary backend to? ensure we don't allow anything OpenSSL-specific to creep into the? primitives, but I would be okay with it not landing until the next? release.? I don?t feel strongly about this, I have some concerns about not being able to look inside corecrypto. ?I would like to land a second backend sooner rather than later, but I can?t come up with a good reason why it should block release. Thread Safety (https://github.com/pyca/cryptography/pull/352)? This definitely needs to be resolved.? +1 pending https://github.com/pyca/cryptography/pull/380 landing Error Handling (https://github.com/pyca/cryptography/pull/359)? There is a PR outstanding to convert our assert-based errors to? methods that check ERR_get_error(). This might be helpful to have in? the first release to get better error information back from early? adopters.? The existing pull request seems unwieldy, anyone have a good idea for how to break it up? -Paul? On Mon, Dec 30, 2013 at 6:17 PM, Donald Stufft wrote:? > I?m personally fine without any asymmetric for the first release with Hynek?s? > concern mirrored about wanting to change the symmetric APIs with our? > experience in asymmetric.? My bigger concern is actually not letting us get enough feedback on the symmetric APIs before solidifying the asymmetric ones >? > On Dec 30, 2013, at 6:59 PM, Hynek Schlawack wrote:? >? >> On 31 Dec 2013, at 0:01, Alex Gaynor wrote:? >>? >>> What do people think of the idea of us doing our first release without? >>> having any asymmetric support?? >>>? >>> The motivation here would be to allow us to get our initial release out? >>> sooner, addressing the following concerns:? >>>? >>> - pyOpenSSL! (specifically on PyPy)? >>> - Crypto on py3k and on PyPy? >>> - GCM support? >>> - A safe recipe for symmetric encryption.? >>>? >>> What do folks think about this idea?? >>? >> Actually, why not? We ?just? need to be half-way sure that those points you mentioned don?t change while implementing asymmetric encryption because I?d really not like to break compatibility at any point._______________________________________________? >> Cryptography-dev mailing list? >> Cryptography-dev at python.org? >> https://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? > https://mail.python.org/mailman/listinfo/cryptography-dev? >? _______________________________________________? Cryptography-dev mailing list? Cryptography-dev at python.org? https://mail.python.org/mailman/listinfo/cryptography-dev? -------------- next part -------------- An HTML attachment was scrubbed... URL: