From paul.l.kehrer at gmail.com Wed May 4 12:43:02 2016 From: paul.l.kehrer at gmail.com (Paul Kehrer) Date: Wed, 4 May 2016 11:43:02 -0500 Subject: [Cryptography-dev] PyCA/cryptography 1.3.2 released Message-ID: PyCA cryptography 1.3.2 has been released to PyPI. cryptography is a package which provides cryptographic recipes and primitives to Python developers. Our goal is for it to be your "cryptographic standard library". We support Python 2.6-2.7, Python 3.3+, and PyPy.? This release contains only two changes: * Updated Windows and OS X wheels to be compiled against OpenSSL 1.0.2h. * Fixed an issue preventing cryptography from compiling against LibreSSL 2.3.x. -Paul Kehrer (reaperhulk) From a.yukhanov at gmail.com Thu May 12 16:09:27 2016 From: a.yukhanov at gmail.com (Alexander Yukhanov) Date: Thu, 12 May 2016 16:09:27 -0400 Subject: [Cryptography-dev] deadlock while using hazmat Message-ID: Hello, I have a service which uses hazmat, requests and tornado. Now and when i am encountering deadlock in openssl. One thread is trying to perform handshake, acquires CRYPTO_LOCK_RSA lock and is trying to call to Cryptography_rand_bytes which required GIL. Another thread is keeping GIL and trying to execute PySSL_dealloc, which required locking of CRYPTO_LOCK_RSA. So, it seems to be a classical deadlock. Can i use hazmat without osrandom engine registration? Thank you, Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.gaynor at gmail.com Thu May 12 16:14:13 2016 From: alex.gaynor at gmail.com (Alex Gaynor) Date: Thu, 12 May 2016 16:14:13 -0400 Subject: [Cryptography-dev] deadlock while using hazmat In-Reply-To: References: Message-ID: Ugh, that's nasty, awesome job debugging it! You can disable the osrandom engine with https://cryptography.io/en/latest/hazmat/backends/openssl/#activate_builtin_random however it'd be great to actually get this fixed. Can you file a ticket with all this info (and if you have a minimal reproducer, that as well)? Thanks! Alex On Thu, May 12, 2016 at 4:09 PM, Alexander Yukhanov wrote: > Hello, > I have a service which uses hazmat, requests and tornado. Now and when i > am encountering deadlock in openssl. One thread is trying to perform > handshake, acquires CRYPTO_LOCK_RSA lock and is trying to call to > Cryptography_rand_bytes which required GIL. Another thread is keeping GIL > and trying to execute PySSL_dealloc, which required locking of > CRYPTO_LOCK_RSA. So, it seems to be a classical deadlock. > Can i use hazmat without osrandom engine registration? > > Thank you, > Alex > > _______________________________________________ > 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: D1B3 ADC0 E023 8CA6 -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.yukhanov at gmail.com Thu May 12 16:20:12 2016 From: a.yukhanov at gmail.com (Alexander Yukhanov) Date: Thu, 12 May 2016 16:20:12 -0400 Subject: [Cryptography-dev] deadlock while using hazmat In-Reply-To: References: Message-ID: Thank you so much for the info! I will write a minimal reproducer and file the ticket. On Thu, May 12, 2016 at 4:14 PM, Alex Gaynor wrote: > Ugh, that's nasty, awesome job debugging it! > > You can disable the osrandom engine with > https://cryptography.io/en/latest/hazmat/backends/openssl/#activate_builtin_random > however it'd be great to actually get this fixed. Can you file a ticket > with all this info (and if you have a minimal reproducer, that as well)? > > Thanks! > Alex > > On Thu, May 12, 2016 at 4:09 PM, Alexander Yukhanov > wrote: > >> Hello, >> I have a service which uses hazmat, requests and tornado. Now and when i >> am encountering deadlock in openssl. One thread is trying to perform >> handshake, acquires CRYPTO_LOCK_RSA lock and is trying to call to >> Cryptography_rand_bytes which required GIL. Another thread is keeping GIL >> and trying to execute PySSL_dealloc, which required locking of >> CRYPTO_LOCK_RSA. So, it seems to be a classical deadlock. >> Can i use hazmat without osrandom engine registration? >> >> Thank you, >> Alex >> >> _______________________________________________ >> 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: D1B3 ADC0 E023 8CA6 > > > _______________________________________________ > 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 tknarr at silverglass.org Fri May 27 22:28:04 2016 From: tknarr at silverglass.org (Todd Knarr) Date: Fri, 27 May 2016 19:28:04 -0700 Subject: [Cryptography-dev] Fernet with AES192/256 Message-ID: Would there be an interest in, or philosophical/design objections to, a patch to allow Fernet to use AES192 and AES256 encryption? I've got a situation where Fernet would be a good fit but 256-bit encryption is highly desired. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4160 bytes Desc: S/MIME Cryptographic Signature URL: From alex.gaynor at gmail.com Fri May 27 22:36:45 2016 From: alex.gaynor at gmail.com (Alex Gaynor) Date: Fri, 27 May 2016 22:36:45 -0400 Subject: [Cryptography-dev] Fernet with AES192/256 In-Reply-To: References: Message-ID: Fernet is a standard maintained outside pyca/cryptography, we wouldn't implement anything in Fernet that wasn't a part of that standard. The standard itself is in something of a hybernation state ATM, so candidly I don't know how receptive they'd be to such a proposed change. I fear your best option is probably to fork the Fernet mdoule, which thankfully isn't terribly much code. Alex On Fri, May 27, 2016 at 10:28 PM, Todd Knarr wrote: > Would there be an interest in, or philosophical/design objections to, a > patch to allow Fernet to use AES192 and AES256 encryption? I've got a > situation where Fernet would be a good fit but 256-bit encryption is highly > desired. > > > > _______________________________________________ > 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: D1B3 ADC0 E023 8CA6 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tknarr at silverglass.org Sat May 28 00:25:51 2016 From: tknarr at silverglass.org (Todd Knarr) Date: Fri, 27 May 2016 21:25:51 -0700 Subject: [Cryptography-dev] Fernet with AES192/256 In-Reply-To: References: Message-ID: On 05/27/2016 07:36 PM, Alex Gaynor wrote: > Fernet is a standard maintained outside pyca/cryptography, we wouldn't > implement anything in Fernet that wasn't a part of that standard. How about a version that left the Fernet class itself using AES128 but added new classes that'd use AES192 and AES256? I can fork the code and use my fork, but if I'm going to do the work anyway I'd like to feed it back in for others to use if I can do that in an acceptable way. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4160 bytes Desc: S/MIME Cryptographic Signature URL: From alex.gaynor at gmail.com Sat May 28 00:27:05 2016 From: alex.gaynor at gmail.com (Alex Gaynor) Date: Sat, 28 May 2016 00:27:05 -0400 Subject: [Cryptography-dev] Fernet with AES192/256 In-Reply-To: References: Message-ID: The problem is Fernet refers to a specific standard, if you change it, you've got something new and not interoperable :-) Alex On Sat, May 28, 2016 at 12:25 AM, Todd Knarr wrote: > On 05/27/2016 07:36 PM, Alex Gaynor wrote: > >> Fernet is a standard maintained outside pyca/cryptography, we wouldn't >> implement anything in Fernet that wasn't a part of that standard. >> > How about a version that left the Fernet class itself using AES128 but > added new classes that'd use AES192 and AES256? I can fork the code and use > my fork, but if I'm going to do the work anyway I'd like to feed it back in > for others to use if I can do that in an acceptable way. > > > _______________________________________________ > 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: D1B3 ADC0 E023 8CA6 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tknarr at silverglass.org Sat May 28 01:17:38 2016 From: tknarr at silverglass.org (Todd Knarr) Date: Fri, 27 May 2016 22:17:38 -0700 Subject: [Cryptography-dev] Fernet with AES192/256 In-Reply-To: References: Message-ID: On 05/27/2016 09:27 PM, Alex Gaynor wrote: > The problem is Fernet refers to a specific standard, if you change it, > you've got something new and not interoperable :-) Oddly, it /would/ interoperate (at least using cryptography's implementation) if you used the correct-sized key for the AES encryption (and if you weren't using the correct size, you wouldn't be using the right key and decryption should correctly fail). At least that's what it looks like. I need to do a proper test, but it looks like the changes are all in the Fernet class's __init__ and generate_key methods to use the desired key size instead of the current hard-coded 128 bits. Ugly but minimal-modifications method is to derive Fernet256 from Fernet implementing __init__ and generate_key with the hard-coded values changed to 256 bits, clean method is to rename Fernet to FernetBase and alter __init__ and generate_key to work based on the passed-in key length or requested number of key bits, then new Fernet, Fernet192 and Fernet256 classes derive from FernetBase forcing 128-, 192- or 256-bit AES keys. Names of the latter two classes could be changed, I use them just to remind myself that they're all related except for the key size. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4160 bytes Desc: S/MIME Cryptographic Signature URL: From cory at lukasa.co.uk Sat May 28 10:51:00 2016 From: cory at lukasa.co.uk (Cory Benfield) Date: Sat, 28 May 2016 07:51:00 -0700 Subject: [Cryptography-dev] Fernet with AES192/256 In-Reply-To: References: Message-ID: <282B37BB-13C9-4036-8C53-1B8D3055E317@lukasa.co.uk> > On 27 May 2016, at 22:17, Todd Knarr wrote: > > On 05/27/2016 09:27 PM, Alex Gaynor wrote: >> The problem is Fernet refers to a specific standard, if you change it, you've got something new and not interoperable :-) > Oddly, it would interoperate (at least using cryptography's implementation) if you used the correct-sized key for the AES encryption Unfortunately, Fernet is implemented by more than just the Python cryptography project, and *those* implementations may not react as well to higher-key-length AES encryption mechanisms. Cory -------------- 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 tknarr at silverglass.org Mon May 30 23:49:39 2016 From: tknarr at silverglass.org (Todd Knarr) Date: Mon, 30 May 2016 20:49:39 -0700 Subject: [Cryptography-dev] Fernet with AES192/256 In-Reply-To: <282B37BB-13C9-4036-8C53-1B8D3055E317@lukasa.co.uk> References: <282B37BB-13C9-4036-8C53-1B8D3055E317@lukasa.co.uk> Message-ID: <5d0ffa46-a9fe-e0e8-5aa8-a54dfab50ec4@silverglass.org> On 05/28/2016 07:51 AM, Cory Benfield wrote: > Unfortunately, Fernet is implemented by more than just the Python > cryptography project, and *those* implementations may not react as > well to higher-key-length AES encryption mechanisms. Would the attached be an acceptable change? The Fernet class continues to use AES128. The ExtFernet192 and ExtFernet256 classes follow the same token format but use AES192 and AES256 encryption respectively and change the version byte in the output to distinguish the data from standard Fernet. It's also available as a pull request on Github. -------------- next part -------------- A non-text attachment was scrubbed... Name: extended_fernet.diff Type: text/x-patch Size: 10652 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4160 bytes Desc: S/MIME Cryptographic Signature URL: