From tknarr at silverglass.org  Wed Jun  1 12:44:15 2016
From: tknarr at silverglass.org (Todd Knarr)
Date: Wed, 1 Jun 2016 09:44:15 -0700
Subject: [Cryptography-dev] Fernet with AES192/256
In-Reply-To: <5d0ffa46-a9fe-e0e8-5aa8-a54dfab50ec4@silverglass.org>
References: <cbdac179-67bd-eb4e-a070-f934792bde93@silverglass.org>
 <CAFRnB2WR9FAORKGpuFiEbVKvcZd5qYnKE4e8ngwXGuAnTy58PQ@mail.gmail.com>
 <caa33164-7355-70a0-5712-b333c9bca454@silverglass.org>
 <CAFRnB2X7xVB+xdOrzRSpA+5nWhttUAwoU4d2Q1EpHa=nkeCx-g@mail.gmail.com>
 <d671bf5e-55a2-61b5-25d1-256e021467c4@silverglass.org>
 <282B37BB-13C9-4036-8C53-1B8D3055E317@lukasa.co.uk>
 <5d0ffa46-a9fe-e0e8-5aa8-a54dfab50ec4@silverglass.org>
Message-ID: <f6c372cf-8c32-be9e-d34b-76fe60bca320@silverglass.org>

On 05/30/2016 08:49 PM, Todd Knarr wrote:
> It's also available as a pull request on Github. 
Pull request 2938:
https://github.com/pyca/cryptography/pull/2938
Looks to be passing tests at this point, it's still waiting for Jenkins 
to report in.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4160 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20160601/aaf4fd6b/attachment.bin>

From alex.gaynor at gmail.com  Wed Jun  1 12:45:31 2016
From: alex.gaynor at gmail.com (Alex Gaynor)
Date: Wed, 1 Jun 2016 12:45:31 -0400
Subject: [Cryptography-dev] Fernet with AES192/256
In-Reply-To: <f6c372cf-8c32-be9e-d34b-76fe60bca320@silverglass.org>
References: <cbdac179-67bd-eb4e-a070-f934792bde93@silverglass.org>
 <CAFRnB2WR9FAORKGpuFiEbVKvcZd5qYnKE4e8ngwXGuAnTy58PQ@mail.gmail.com>
 <caa33164-7355-70a0-5712-b333c9bca454@silverglass.org>
 <CAFRnB2X7xVB+xdOrzRSpA+5nWhttUAwoU4d2Q1EpHa=nkeCx-g@mail.gmail.com>
 <d671bf5e-55a2-61b5-25d1-256e021467c4@silverglass.org>
 <282B37BB-13C9-4036-8C53-1B8D3055E317@lukasa.co.uk>
 <5d0ffa46-a9fe-e0e8-5aa8-a54dfab50ec4@silverglass.org>
 <f6c372cf-8c32-be9e-d34b-76fe60bca320@silverglass.org>
Message-ID: <CAFRnB2W7ox6n3k8FqYo7q8H2pX-+CqDhpAvAaYvM4FmEcGXiDw@mail.gmail.com>

Hi Todd,

We're not going to merge non-standard extensions to Fernet. You're welcome
to attempt to contribute to the upstream spec, but absent a change there
I'm going to close your PR.

Alex

On Wed, Jun 1, 2016 at 12:44 PM, Todd Knarr <tknarr at silverglass.org> wrote:

> On 05/30/2016 08:49 PM, Todd Knarr wrote:
>
>> It's also available as a pull request on Github.
>>
> Pull request 2938:
> https://github.com/pyca/cryptography/pull/2938
> Looks to be passing tests at this point, it's still waiting for Jenkins to
> report in.
>
>
> _______________________________________________
> 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: <http://mail.python.org/pipermail/cryptography-dev/attachments/20160601/a2d328f7/attachment.html>

From paul.l.kehrer at gmail.com  Thu Jun  2 17:54:55 2016
From: paul.l.kehrer at gmail.com (Paul Kehrer)
Date: Thu, 2 Jun 2016 17:54:55 -0400
Subject: [Cryptography-dev] PyCA cryptography 1.3.3 released
Message-ID: <CABj5TKSX8fY2K7JSfxf=ET7y2Q2AFxzrXBmz_hcM0+Xzt1SL8Q@mail.gmail.com>

PyCA cryptography 1.3.3 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.

Changelog:

* Added two new OpenSSL functions to the bindings to support an upcoming
pyOpenSSL release.

-Paul Kehrer (reaperhulk)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20160602/73fefd56/attachment.html>

From paul.l.kehrer at gmail.com  Fri Jun  3 01:40:38 2016
From: paul.l.kehrer at gmail.com (Paul Kehrer)
Date: Thu, 2 Jun 2016 22:40:38 -0700
Subject: [Cryptography-dev] PyCA cryptography 1.3.4
Message-ID: <CABj5TKQv5y9yokyBx-TEf-3qhhmHKf2ize-=zB0Fe8syoxC36Q@mail.gmail.com>

PyCA cryptography 1.3.3 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.

Changelog:

* Added another OpenSSL function to the bindings to support an upcoming
pyOpenSSL release.


-Paul Kehrer (reaperhulk)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20160602/db56ecc0/attachment.html>

From paul.l.kehrer at gmail.com  Sat Jun  4 13:18:10 2016
From: paul.l.kehrer at gmail.com (Paul Kehrer)
Date: Sat, 4 Jun 2016 13:18:10 -0400
Subject: [Cryptography-dev] PyCA cryptography 1.4 released
Message-ID: <CABj5TKTtAJAy3PDehVV3K-j6RrrcmgWwLwFgSfHxF-W5uc5rKQ@mail.gmail.com>

Courtesy of the PyCon sprints, PyCA cryptography 1.4 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.

Changelog:

* Support for OpenSSL 0.9.8 has been removed. Users on older versions of
OpenSSL will need to upgrade.
* Added KBKDFHMAC.
* Added support for OpenSSH public key serialization.
* Added support for SHA-2 in RSA OAEP when using OpenSSL 1.0.2 or greater.
* Added "one shot" sign() and verify() APIs to RSA keys.


-Paul Kehrer (reaperhulk)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20160604/82aefc00/attachment.html>

From frank.siebenlist at gmail.com  Sun Jun  5 19:34:39 2016
From: frank.siebenlist at gmail.com (Frank Siebenlist)
Date: Sun, 5 Jun 2016 16:34:39 -0700
Subject: [Cryptography-dev] Fernet NG or alternative simple, high-level,
 encrypted message module?
Message-ID: <948A93A3-0FBC-41CB-937E-DFF2A7FBEC9D@gmail.com>

Hi pyca/cryptography community,

We're looking to migrate away from pycrypto - most probably to pyca/cryptography.
Pretty sure there will be no objections to that choice on this mailing list. ;-)

We also have internally developed libraries for symmetric-key message encryption and such, which we?d love to migrate to some simple, high-level Fernet/KeyCzar-like lib for our developers to use. 

Our requirements for such a high-level, simple, symmetric-key message encryption library are:

?

* based on pyca/cryptography

* simple interface that hides all low-level crypto, like algo, mode, iv, tag, and their respective sizes
** transparently uses the ?correct" defaults for the developers.
** ideally just new_key, encrypt & decrypt functions with opaque tokens
** although implementation could hard-code choices, changes over time should be compatible with already encrypted tokens

* make the keys and encrypted messages opaque tokens for developers
** no need to know what?s inside - just move those tokens from Alice to Bob and vice versa.

* make both key and encrypted message tokens html&url-friendly
** base64url

* token format enables/allows for algo/mode/size policy changes over time
** ideally a change of policy should not affect existing tokens and code
** (I?ve been bitten one time too many by hard-coded message formats?)

* key versioning
** not sure yet about the details?
** maybe something like aws-kms: use newest key version by default and transparently decrypt any message encrypted with older versions (?).

* key time-to-live
** Fernet has that TTL feature built-in for encrypted messages? but we haven?t seen that requirement yet (encrypted cookie life-time maybe?)

* make key-management as transparent as possible
** use key-identifiers (kid) under-the-covers
** all keys should have identifiers
** all encrypted message tokes should include the associated key-identifier
** possible transparently deploy a default kid-key-db

?

The current Fernet module does not meet a number of those requirements, like the flexibility of transparently changing ciphers or sizes, no key-tokens, and no key-management help. Changing key-sizes or modes (AES256GCM anyone?), would brake the current implementation because the iv, cipher text and tag are essentially byte-concatenated in the token. 

Looking at the recent standards, an implementation based on jose's json web tokens would give you a lot of primitives to work with: well defined token format, enough meta-data about keys and encrypted messages to ensure the ability to change policies over time, overhead and increased message size acceptable for most (somewhat bigger than concatenating bare-bytes but not as overly verbose as XML-Encryption).

Unfortunately, there is no jose library included in pyca/cryptography (yet)? The best jose library based on cryptography that I found seems to be jwcrypto, but its GNU GPL is less friendly (just observation - not a religious statement (I actually contributed to jwcrypto?)). Furthermore, it?s a lot of code to pull-in.

We have prototype code that shows that a simple Fernet-style interface based on AES256GCM and jose?s jwt should be feasible. The coding was an exercise to test our requirements and possible token formats - production quality code was not aimed for. Ideally, we would prefer to leverage those kind of crypto libraries from efforts like pyca/cryptography? happy to help or contribute, but we?re very hesitant to take on the support of a crypto library as it?s not core to our business.

Questions for the pyca/cryptography community:

* Any others who share the need/dream for such a high-level, simple Fernet-style library based on jose/jwt?

* Did we possibly miss an existing effort that meets (most of) those requirements?

* Comments? Suggestions?

Thanks, Frank.

"From a security perspective, if you're connected, you're screwed." - Daniel J. Bernstein


From rob.marshall17 at gmail.com  Wed Jun  8 09:59:21 2016
From: rob.marshall17 at gmail.com (Rob Marshall)
Date: Wed, 8 Jun 2016 09:59:21 -0400
Subject: [Cryptography-dev] Python cryptography-1.4 install fails on SLES 10
 SP3
Message-ID: <CALrmp7xEq_jgkrWZHrMO-rNH2u-8pjztv00+xoNAKDajS6dd=g@mail.gmail.com>

Hi,

I'm trying to install cryptography-1.4 on SLES 10 SP3 running Python 2.7.8
that I installed from source. I installed:

libffi-devel-3.0.11-9.1
libffi6-3.0.11-9.1
openssl-devel-0.9.8a-18.36
openssl-0.9.8a-18.36

When I try to build cryptography I'm getting:

creating build/temp.linux-i686-2.7/build/temp.linux-i686-2.7
gcc -pthread -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -fPIC -I/usr/local/include/python2.7 -c
build/temp.linux-i686-2.7/_openssl.c -o
build/temp.linux-i686-2.7/build/temp.linux-i686-2.7/_openssl.o
build/temp.linux-i686-2.7/_openssl.c: In function
?_cffi_const_NID_certificate_issuer?:
build/temp.linux-i686-2.7/_openssl.c:9048: error: ?NID_certificate_issuer?
undeclared (first use in this function)
build/temp.linux-i686-2.7/_openssl.c:9048: error: (Each undeclared
identifier is reported only once
build/temp.linux-i686-2.7/_openssl.c:9048: error: for each function it
appears in.)
build/temp.linux-i686-2.7/_openssl.c: In function
?_cffi_const_NID_issuing_distribution_point?:
build/temp.linux-i686-2.7/_openssl.c:9237: error:
?NID_issuing_distribution_point? undeclared (first use in this function)
build/temp.linux-i686-2.7/_openssl.c: In function
?_cffi_const_X509_V_ERR_UNNESTED_RESOURCE?:
build/temp.linux-i686-2.7/_openssl.c:11781: error:
?X509_V_ERR_UNNESTED_RESOURCE? undeclared (first use in this function)
build/temp.linux-i686-2.7/_openssl.c: In function
?_cffi_d_SSL_CIPHER_description?:
build/temp.linux-i686-2.7/_openssl.c:47399: warning: passing argument 1 of
?SSL_CIPHER_description? discards qualifiers from pointer target type
build/temp.linux-i686-2.7/_openssl.c: In function
?_cffi_f_SSL_CIPHER_description?:
build/temp.linux-i686-2.7/_openssl.c:47450: warning: passing argument 1 of
?SSL_CIPHER_description? discards qualifiers from pointer target type
error: command 'gcc' failed with exit status 1

Any ideas?

Thanks,

Rob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20160608/d1d19ac5/attachment.html>

From alex.gaynor at gmail.com  Wed Jun  8 10:01:35 2016
From: alex.gaynor at gmail.com (Alex Gaynor)
Date: Wed, 8 Jun 2016 10:01:35 -0400
Subject: [Cryptography-dev] Python cryptography-1.4 install fails on
 SLES 10 SP3
In-Reply-To: <CALrmp7xEq_jgkrWZHrMO-rNH2u-8pjztv00+xoNAKDajS6dd=g@mail.gmail.com>
References: <CALrmp7xEq_jgkrWZHrMO-rNH2u-8pjztv00+xoNAKDajS6dd=g@mail.gmail.com>
Message-ID: <CAFRnB2Um=+X+NyzE3WTcmw4APBM5kfbsECED_VboM6rGyJgwOg@mail.gmail.com>

Hi Rob,

Cryptography no longer supports OpenSSL 0.9.8 (I'm not sure we ever
supported as far back as 0.9.8a truth be told).

OpenSSL 0.9.8 is no longer supported by the upstream OpenSSL team, nor does
it receive security patches.

I _strongly_ recommend you upgrade to a modern distro with a modern OpenSSL.

Alex

On Wed, Jun 8, 2016 at 9:59 AM, Rob Marshall <rob.marshall17 at gmail.com>
wrote:

> Hi,
>
> I'm trying to install cryptography-1.4 on SLES 10 SP3 running Python 2.7.8
> that I installed from source. I installed:
>
> libffi-devel-3.0.11-9.1
> libffi6-3.0.11-9.1
> openssl-devel-0.9.8a-18.36
> openssl-0.9.8a-18.36
>
> When I try to build cryptography I'm getting:
>
> creating build/temp.linux-i686-2.7/build/temp.linux-i686-2.7
> gcc -pthread -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall
> -Wstrict-prototypes -fPIC -I/usr/local/include/python2.7 -c
> build/temp.linux-i686-2.7/_openssl.c -o
> build/temp.linux-i686-2.7/build/temp.linux-i686-2.7/_openssl.o
> build/temp.linux-i686-2.7/_openssl.c: In function
> ?_cffi_const_NID_certificate_issuer?:
> build/temp.linux-i686-2.7/_openssl.c:9048: error: ?NID_certificate_issuer?
> undeclared (first use in this function)
> build/temp.linux-i686-2.7/_openssl.c:9048: error: (Each undeclared
> identifier is reported only once
> build/temp.linux-i686-2.7/_openssl.c:9048: error: for each function it
> appears in.)
> build/temp.linux-i686-2.7/_openssl.c: In function
> ?_cffi_const_NID_issuing_distribution_point?:
> build/temp.linux-i686-2.7/_openssl.c:9237: error:
> ?NID_issuing_distribution_point? undeclared (first use in this function)
> build/temp.linux-i686-2.7/_openssl.c: In function
> ?_cffi_const_X509_V_ERR_UNNESTED_RESOURCE?:
> build/temp.linux-i686-2.7/_openssl.c:11781: error:
> ?X509_V_ERR_UNNESTED_RESOURCE? undeclared (first use in this function)
> build/temp.linux-i686-2.7/_openssl.c: In function
> ?_cffi_d_SSL_CIPHER_description?:
> build/temp.linux-i686-2.7/_openssl.c:47399: warning: passing argument 1 of
> ?SSL_CIPHER_description? discards qualifiers from pointer target type
> build/temp.linux-i686-2.7/_openssl.c: In function
> ?_cffi_f_SSL_CIPHER_description?:
> build/temp.linux-i686-2.7/_openssl.c:47450: warning: passing argument 1 of
> ?SSL_CIPHER_description? discards qualifiers from pointer target type
> error: command 'gcc' failed with exit status 1
>
> Any ideas?
>
> Thanks,
>
> Rob
>
> _______________________________________________
> 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: <http://mail.python.org/pipermail/cryptography-dev/attachments/20160608/1213d1f3/attachment.html>

From rob.marshall17 at gmail.com  Wed Jun  8 13:25:14 2016
From: rob.marshall17 at gmail.com (Rob Marshall)
Date: Wed, 8 Jun 2016 13:25:14 -0400
Subject: [Cryptography-dev] Python cryptography-1.4 install fails on
 SLES 10 SP3
In-Reply-To: <CAFRnB2Um=+X+NyzE3WTcmw4APBM5kfbsECED_VboM6rGyJgwOg@mail.gmail.com>
References: <CALrmp7xEq_jgkrWZHrMO-rNH2u-8pjztv00+xoNAKDajS6dd=g@mail.gmail.com>
 <CAFRnB2Um=+X+NyzE3WTcmw4APBM5kfbsECED_VboM6rGyJgwOg@mail.gmail.com>
Message-ID: <CALrmp7zjPncN_dbyRLJakYH-1UHG=yRY7GHg4Eiro4KG_tXOxQ@mail.gmail.com>

Hi Alex,

OK, thanks. I can't upgrade because I use SLES 10 SP3 as the basis of a
product I support which has kernel modules, among other things, and my
management would rather never release a new version...

Rob

On Wed, Jun 8, 2016 at 10:01 AM, Alex Gaynor <alex.gaynor at gmail.com> wrote:

> Hi Rob,
>
> Cryptography no longer supports OpenSSL 0.9.8 (I'm not sure we ever
> supported as far back as 0.9.8a truth be told).
>
> OpenSSL 0.9.8 is no longer supported by the upstream OpenSSL team, nor
> does it receive security patches.
>
> I _strongly_ recommend you upgrade to a modern distro with a modern
> OpenSSL.
>
> Alex
>
> On Wed, Jun 8, 2016 at 9:59 AM, Rob Marshall <rob.marshall17 at gmail.com>
> wrote:
>
>> Hi,
>>
>> I'm trying to install cryptography-1.4 on SLES 10 SP3 running Python
>> 2.7.8 that I installed from source. I installed:
>>
>> libffi-devel-3.0.11-9.1
>> libffi6-3.0.11-9.1
>> openssl-devel-0.9.8a-18.36
>> openssl-0.9.8a-18.36
>>
>> When I try to build cryptography I'm getting:
>>
>> creating build/temp.linux-i686-2.7/build/temp.linux-i686-2.7
>> gcc -pthread -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall
>> -Wstrict-prototypes -fPIC -I/usr/local/include/python2.7 -c
>> build/temp.linux-i686-2.7/_openssl.c -o
>> build/temp.linux-i686-2.7/build/temp.linux-i686-2.7/_openssl.o
>> build/temp.linux-i686-2.7/_openssl.c: In function
>> ?_cffi_const_NID_certificate_issuer?:
>> build/temp.linux-i686-2.7/_openssl.c:9048: error:
>> ?NID_certificate_issuer? undeclared (first use in this function)
>> build/temp.linux-i686-2.7/_openssl.c:9048: error: (Each undeclared
>> identifier is reported only once
>> build/temp.linux-i686-2.7/_openssl.c:9048: error: for each function it
>> appears in.)
>> build/temp.linux-i686-2.7/_openssl.c: In function
>> ?_cffi_const_NID_issuing_distribution_point?:
>> build/temp.linux-i686-2.7/_openssl.c:9237: error:
>> ?NID_issuing_distribution_point? undeclared (first use in this function)
>> build/temp.linux-i686-2.7/_openssl.c: In function
>> ?_cffi_const_X509_V_ERR_UNNESTED_RESOURCE?:
>> build/temp.linux-i686-2.7/_openssl.c:11781: error:
>> ?X509_V_ERR_UNNESTED_RESOURCE? undeclared (first use in this function)
>> build/temp.linux-i686-2.7/_openssl.c: In function
>> ?_cffi_d_SSL_CIPHER_description?:
>> build/temp.linux-i686-2.7/_openssl.c:47399: warning: passing argument 1
>> of ?SSL_CIPHER_description? discards qualifiers from pointer target type
>> build/temp.linux-i686-2.7/_openssl.c: In function
>> ?_cffi_f_SSL_CIPHER_description?:
>> build/temp.linux-i686-2.7/_openssl.c:47450: warning: passing argument 1
>> of ?SSL_CIPHER_description? discards qualifiers from pointer target type
>> error: command 'gcc' failed with exit status 1
>>
>> Any ideas?
>>
>> Thanks,
>>
>> Rob
>>
>> _______________________________________________
>> 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: <http://mail.python.org/pipermail/cryptography-dev/attachments/20160608/9156aa75/attachment.html>

From alex.gaynor at gmail.com  Wed Jun  8 13:27:54 2016
From: alex.gaynor at gmail.com (Alex Gaynor)
Date: Wed, 8 Jun 2016 13:27:54 -0400
Subject: [Cryptography-dev] Python cryptography-1.4 install fails on
 SLES 10 SP3
In-Reply-To: <CALrmp7zjPncN_dbyRLJakYH-1UHG=yRY7GHg4Eiro4KG_tXOxQ@mail.gmail.com>
References: <CALrmp7xEq_jgkrWZHrMO-rNH2u-8pjztv00+xoNAKDajS6dd=g@mail.gmail.com>
 <CAFRnB2Um=+X+NyzE3WTcmw4APBM5kfbsECED_VboM6rGyJgwOg@mail.gmail.com>
 <CALrmp7zjPncN_dbyRLJakYH-1UHG=yRY7GHg4Eiro4KG_tXOxQ@mail.gmail.com>
Message-ID: <CAFRnB2Wte3zsZ1Y2NvpPop6oVMXS5NWPUQWRS=9LXiu7=Z4cmg@mail.gmail.com>

That's unfortunate. You'll be unable to use cryptography, as we don't
supported an OpenSSL that old.

Alex

On Wed, Jun 8, 2016 at 1:25 PM, Rob Marshall <rob.marshall17 at gmail.com>
wrote:

> Hi Alex,
>
> OK, thanks. I can't upgrade because I use SLES 10 SP3 as the basis of a
> product I support which has kernel modules, among other things, and my
> management would rather never release a new version...
>
> Rob
>
> On Wed, Jun 8, 2016 at 10:01 AM, Alex Gaynor <alex.gaynor at gmail.com>
> wrote:
>
>> Hi Rob,
>>
>> Cryptography no longer supports OpenSSL 0.9.8 (I'm not sure we ever
>> supported as far back as 0.9.8a truth be told).
>>
>> OpenSSL 0.9.8 is no longer supported by the upstream OpenSSL team, nor
>> does it receive security patches.
>>
>> I _strongly_ recommend you upgrade to a modern distro with a modern
>> OpenSSL.
>>
>> Alex
>>
>> On Wed, Jun 8, 2016 at 9:59 AM, Rob Marshall <rob.marshall17 at gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> I'm trying to install cryptography-1.4 on SLES 10 SP3 running Python
>>> 2.7.8 that I installed from source. I installed:
>>>
>>> libffi-devel-3.0.11-9.1
>>> libffi6-3.0.11-9.1
>>> openssl-devel-0.9.8a-18.36
>>> openssl-0.9.8a-18.36
>>>
>>> When I try to build cryptography I'm getting:
>>>
>>> creating build/temp.linux-i686-2.7/build/temp.linux-i686-2.7
>>> gcc -pthread -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall
>>> -Wstrict-prototypes -fPIC -I/usr/local/include/python2.7 -c
>>> build/temp.linux-i686-2.7/_openssl.c -o
>>> build/temp.linux-i686-2.7/build/temp.linux-i686-2.7/_openssl.o
>>> build/temp.linux-i686-2.7/_openssl.c: In function
>>> ?_cffi_const_NID_certificate_issuer?:
>>> build/temp.linux-i686-2.7/_openssl.c:9048: error:
>>> ?NID_certificate_issuer? undeclared (first use in this function)
>>> build/temp.linux-i686-2.7/_openssl.c:9048: error: (Each undeclared
>>> identifier is reported only once
>>> build/temp.linux-i686-2.7/_openssl.c:9048: error: for each function it
>>> appears in.)
>>> build/temp.linux-i686-2.7/_openssl.c: In function
>>> ?_cffi_const_NID_issuing_distribution_point?:
>>> build/temp.linux-i686-2.7/_openssl.c:9237: error:
>>> ?NID_issuing_distribution_point? undeclared (first use in this function)
>>> build/temp.linux-i686-2.7/_openssl.c: In function
>>> ?_cffi_const_X509_V_ERR_UNNESTED_RESOURCE?:
>>> build/temp.linux-i686-2.7/_openssl.c:11781: error:
>>> ?X509_V_ERR_UNNESTED_RESOURCE? undeclared (first use in this function)
>>> build/temp.linux-i686-2.7/_openssl.c: In function
>>> ?_cffi_d_SSL_CIPHER_description?:
>>> build/temp.linux-i686-2.7/_openssl.c:47399: warning: passing argument 1
>>> of ?SSL_CIPHER_description? discards qualifiers from pointer target type
>>> build/temp.linux-i686-2.7/_openssl.c: In function
>>> ?_cffi_f_SSL_CIPHER_description?:
>>> build/temp.linux-i686-2.7/_openssl.c:47450: warning: passing argument 1
>>> of ?SSL_CIPHER_description? discards qualifiers from pointer target type
>>> error: command 'gcc' failed with exit status 1
>>>
>>> Any ideas?
>>>
>>> Thanks,
>>>
>>> Rob
>>>
>>> _______________________________________________
>>> 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
>>
>>
>
> _______________________________________________
> 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: <http://mail.python.org/pipermail/cryptography-dev/attachments/20160608/b9cd6226/attachment-0001.html>

From jcea at jcea.es  Wed Jun  8 17:02:56 2016
From: jcea at jcea.es (Jesus Cea)
Date: Wed, 8 Jun 2016 23:02:56 +0200
Subject: [Cryptography-dev] Python cryptography-1.4 install fails on
 SLES 10 SP3
In-Reply-To: <CALrmp7zjPncN_dbyRLJakYH-1UHG=yRY7GHg4Eiro4KG_tXOxQ@mail.gmail.com>
References: <CALrmp7xEq_jgkrWZHrMO-rNH2u-8pjztv00+xoNAKDajS6dd=g@mail.gmail.com>
 <CAFRnB2Um=+X+NyzE3WTcmw4APBM5kfbsECED_VboM6rGyJgwOg@mail.gmail.com>
 <CALrmp7zjPncN_dbyRLJakYH-1UHG=yRY7GHg4Eiro4KG_tXOxQ@mail.gmail.com>
Message-ID: <5236dfb8-9c11-e64b-c9f6-7fee49fd070c@jcea.es>

On 08/06/16 19:25, Rob Marshall wrote:
> OK, thanks. I can't upgrade because I use SLES 10 SP3 as the basis of a
> product I support which has kernel modules, among other things, and my
> management would rather never release a new version...

That I do is to compile my own OpenSSL version to link with Python and
Cryptography. You should use the same version for all your python and
python modules.

-- 
Jes?s Cea Avi?n                         _/_/      _/_/_/        _/_/_/
jcea at jcea.es - http://www.jcea.es/     _/_/    _/_/  _/_/    _/_/  _/_/
Twitter: @jcea                        _/_/    _/_/          _/_/_/_/_/
jabber / xmpp:jcea at jabber.org  _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20160608/b6510400/attachment.sig>

From paul.l.kehrer at gmail.com  Sun Jun 12 23:51:26 2016
From: paul.l.kehrer at gmail.com (Paul Kehrer)
Date: Sun, 12 Jun 2016 23:51:26 -0400
Subject: [Cryptography-dev] Fernet NG or alternative simple, high-level,
 encrypted message module?
In-Reply-To: <948A93A3-0FBC-41CB-937E-DFF2A7FBEC9D@gmail.com>
References: <948A93A3-0FBC-41CB-937E-DFF2A7FBEC9D@gmail.com>
Message-ID: <CABj5TKQRNAv8p1X-fy8C5pSHKdGSk+m89Fmz8Wn3OLpThX8ggw@mail.gmail.com>

Hi Frank, sorry about the delayed response. Replies inline.

On June 5, 2016 at 6:34:58 PM, Frank Siebenlist (frank.siebenlist at gmail.com)
wrote:

...snip...
Questions for the pyca/cryptography community:

* Any others who share the need/dream for such a high-level, simple
Fernet-style library based on jose/jwt?

There has been some conversation along these lines in
https://github.com/pyca/cryptography/issues/2900 and continuing in
https://github.com/pyca/cryptography/issues/2912

In general I'm in favor of pulling jwcrypto (or something like it) into
cryptography. The obstacles are going to be figuring out the licensing
(cryptography is Apache2/BSD dual licensed and any code contributed to it
needs to be available under those licenses), discussing what (if any) API
changes need to be made to fit in with the API design of the hazmat layer,
and general "make the code style match cryptography".

As I've stated in issue 2912 I do feel that the JW{S,E,T} implementations
belong in hazmat because the IETF specs allow bad algorithm choice. I might
be okay with exposing a specifically opinionated version (e.g. your choices
are taken away and cryptography selects a good choice) as a recipe. This
sounds like it would meet your needs, correct?


* Did we possibly miss an existing effort that meets (most of) those
requirements?

I'm not specifically familiar with any, but the world is vast. :)



* Comments? Suggestions?

Be wary of algorithmic agility. :) Fernet bakes its algorithms into the
version, so a future version can change them but it will result in a
version bump (a system DJB frequently argues for:
https://twitter.com/hashbreaker/status/601074008013037568). I personally
believe it to be a better solution than what the JOSE specs choose to
provide, but I also concede there's value in something being highly
interoperable even if it isn't the platonic ideal. :)



Thanks, Frank.

"From a security perspective, if you're connected, you're screwed." -
Daniel J. Bernstein

_______________________________________________
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: <http://mail.python.org/pipermail/cryptography-dev/attachments/20160612/4b5b5926/attachment.html>

From simo at redhat.com  Mon Jun 13 09:06:50 2016
From: simo at redhat.com (Simo Sorce)
Date: Mon, 13 Jun 2016 09:06:50 -0400
Subject: [Cryptography-dev] Fernet NG or alternative simple, high-level,
 encrypted message module?
In-Reply-To: <CABj5TKQRNAv8p1X-fy8C5pSHKdGSk+m89Fmz8Wn3OLpThX8ggw@mail.gmail.com>
References: <948A93A3-0FBC-41CB-937E-DFF2A7FBEC9D@gmail.com>
 <CABj5TKQRNAv8p1X-fy8C5pSHKdGSk+m89Fmz8Wn3OLpThX8ggw@mail.gmail.com>
Message-ID: <1465823210.3498.49.camel@redhat.com>

On Sun, 2016-06-12 at 23:51 -0400, Paul Kehrer wrote:
> In general I'm in favor of pulling jwcrypto (or something like it)
> into cryptography. The obstacles are going to be figuring out the
> licensing (cryptography is Apache2/BSD dual licensed and any code
> contributed to it needs to be available under those licenses),
> discussing what (if any) API changes need to be made to fit in with
> the API design of the hazmat layer, and general "make the code style
> match cryptography".

Jwcrypto author here,
from my POV we can discuss license/API/style adjustments needed, just
let me know in which form you want to have this discussion.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York


From frank.siebenlist at gmail.com  Tue Jun 14 12:16:40 2016
From: frank.siebenlist at gmail.com (Frank Siebenlist)
Date: Tue, 14 Jun 2016 09:16:40 -0700
Subject: [Cryptography-dev] Fernet NG or alternative simple, high-level,
 encrypted message module?
In-Reply-To: <CABj5TKQRNAv8p1X-fy8C5pSHKdGSk+m89Fmz8Wn3OLpThX8ggw@mail.gmail.com>
References: <948A93A3-0FBC-41CB-937E-DFF2A7FBEC9D@gmail.com>
 <CABj5TKQRNAv8p1X-fy8C5pSHKdGSk+m89Fmz8Wn3OLpThX8ggw@mail.gmail.com>
Message-ID: <CAJGvTrQZoaWffHmL9gneE==xQUKjfk4e4r=bPo1j+z+vY3E-gw@mail.gmail.com>

> ...snip...
> Questions for the pyca/cryptography community:
>
> * Any others who share the need/dream for such a high-level, simple
> Fernet-style library based on jose/jwt?
>
> There has been some conversation along these lines in
> https://github.com/pyca/cryptography/issues/2900 and continuing in
> https://github.com/pyca/cryptography/issues/2912


Thanks for the links - didn't see those - good to read about the
interest - this discussion should be on the mailing list and not
hidden in github-issues!


> In general I'm in favor of pulling jwcrypto (or something like it) into
> cryptography. The obstacles are going to be figuring out the licensing
> (cryptography is Apache2/BSD dual licensed and any code contributed to it
> needs to be available under those licenses), discussing what (if any) API
> changes need to be made to fit in with the API design of the hazmat layer,
> and general "make the code style match cryptography".
>
> As I've stated in issue 2912 I do feel that the JW{S,E,T} implementations
> belong in hazmat because the IETF specs allow bad algorithm choice. I might
> be okay with exposing a specifically opinionated version (e.g. your choices
> are taken away and cryptography selects a good choice) as a recipe. This
> sounds like it would meet your needs, correct?


Agreed - too many options to deal with - Fernet-like abstraction needs
to work with  (and hide) sane defaults.


> * Did we possibly miss an existing effort that meets (most of) those
> requirements?
>
> I'm not specifically familiar with any, but the world is vast. :)


I've copied a ipython notebook that illustrates the proto-type code
that we have for a Fernet-like message encryption module.

Hopefully that helps a discussion about the different choices at hand.

gist: "https://gist.github.com/franks42/714282ee84b58727c4e9a143d19071b8"


> * Comments? Suggestions?
>
> Be wary of algorithmic agility. :) Fernet bakes its algorithms into the
> version, so a future version can change them but it will result in a version
> bump (a system DJB frequently argues for:
> https://twitter.com/hashbreaker/status/601074008013037568). I personally
> believe it to be a better solution than what the JOSE specs choose to
> provide, but I also concede there's value in something being highly
> interoperable even if it isn't the platonic ideal. :)


I can relate to the concern and although I have an enormous amount of
respect for djb... I don't believe his code relates very well to your
average application developer ;-)
Not sure what the right answer is - but if you get agility (almost)
for free, whether you like it or not, by choosing jwk/e/s token
formats...

Regards, Frank.

From frank.siebenlist at gmail.com  Tue Jun 14 12:19:28 2016
From: frank.siebenlist at gmail.com (Frank Siebenlist)
Date: Tue, 14 Jun 2016 09:19:28 -0700
Subject: [Cryptography-dev] Fernet NG or alternative simple, high-level,
 encrypted message module?
In-Reply-To: <1465823210.3498.49.camel@redhat.com>
References: <948A93A3-0FBC-41CB-937E-DFF2A7FBEC9D@gmail.com>
 <CABj5TKQRNAv8p1X-fy8C5pSHKdGSk+m89Fmz8Wn3OLpThX8ggw@mail.gmail.com>
 <1465823210.3498.49.camel@redhat.com>
Message-ID: <CAJGvTrSp2jUZ-h-EptXEAb8E1nAiGZTGE0A7kziXAysj5ZzEYQ@mail.gmail.com>

Hi Simo - if you could accommodate the jwcrypto-license to match
pyca/cryptography's... that would be fantastic and generous!!! -
Thanks, Frank.

On Mon, Jun 13, 2016 at 6:06 AM, Simo Sorce <simo at redhat.com> wrote:
> On Sun, 2016-06-12 at 23:51 -0400, Paul Kehrer wrote:
>> In general I'm in favor of pulling jwcrypto (or something like it)
>> into cryptography. The obstacles are going to be figuring out the
>> licensing (cryptography is Apache2/BSD dual licensed and any code
>> contributed to it needs to be available under those licenses),
>> discussing what (if any) API changes need to be made to fit in with
>> the API design of the hazmat layer, and general "make the code style
>> match cryptography".
>
> Jwcrypto author here,
> from my POV we can discuss license/API/style adjustments needed, just
> let me know in which form you want to have this discussion.
>
> Simo.
>
> --
> Simo Sorce * Red Hat, Inc * New York
>
> _______________________________________________
> Cryptography-dev mailing list
> Cryptography-dev at python.org
> https://mail.python.org/mailman/listinfo/cryptography-dev

From frank.siebenlist at gmail.com  Tue Jun 14 13:25:28 2016
From: frank.siebenlist at gmail.com (Frank Siebenlist)
Date: Tue, 14 Jun 2016 10:25:28 -0700
Subject: [Cryptography-dev] High-level password hashing module for
 cryptography?
Message-ID: <CAJGvTrQeiCxZgutqWUseidpOd9KyaTmpsMw_Muw99ut-21zv+Q@mail.gmail.com>

Hi pyca/cryptography community,

In my company, we're currently confronted with all the bcrypt vs pbkd2
vs scrypt vs argon discussions and choices. For each there are further
choices to be made about salts-sizes, hash-counts, hash-algos...

Currently pyca/cryptography only has a PBKDF2HMAC module in the hazmat
section, that can be used for password hashing but is presented as a
key-derivation algo... which it technically is.

I'm looking for a higher, non-hazmat, level password-hashing specific module...

Any good libraries available?
Ideally based on pyca/cryptography - although the implementation
choices seem limited (just PBKDF2 unless I missed some...).

I've got some prototype code to see how much we could possibly
abstract the interface to deal with passwords.

Please look at the example python notebook in this gist:
https://gist.github.com/franks42/6edb914203ab7f5a0b151fe0a21e6150

Hopefully that shows some of the interface requirements:

* hide low level key-derivation "stuff" from developers
* work with opaque html/url-friendly tokens to store in the user-passwd-db
* find easy way to manage policy changes and upgrade affected
passwordhash-tokens
* make "easy" migration to the ultimate future algo feasilble (argon2?)

Ideas/suggestions/feedback much appreciated!

Thanks, Frank.

From tknarr at silverglass.org  Tue Jun 14 14:02:39 2016
From: tknarr at silverglass.org (Todd Knarr)
Date: Tue, 14 Jun 2016 11:02:39 -0700
Subject: [Cryptography-dev] High-level password hashing module for
 cryptography?
In-Reply-To: <CAJGvTrQeiCxZgutqWUseidpOd9KyaTmpsMw_Muw99ut-21zv+Q@mail.gmail.com>
References: <CAJGvTrQeiCxZgutqWUseidpOd9KyaTmpsMw_Muw99ut-21zv+Q@mail.gmail.com>
Message-ID: <ffd37e35-86f5-b849-9250-cfd95a566ca3@silverglass.org>

On 06/14/2016 10:25 AM, Frank Siebenlist wrote:
> Any good libraries available?
> Ideally based on pyca/cryptography - although the implementation
> choices seem limited (just PBKDF2 unless I missed some...).
There's pyca/bcrypt, it's not part of pyca/cryptography but it's 
Apache-licensed.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4379 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20160614/25a6d1fb/attachment.bin>

From frank.siebenlist at gmail.com  Tue Jun 14 14:34:11 2016
From: frank.siebenlist at gmail.com (Frank Siebenlist)
Date: Tue, 14 Jun 2016 11:34:11 -0700
Subject: [Cryptography-dev] High-level password hashing module for
 cryptography?
In-Reply-To: <ffd37e35-86f5-b849-9250-cfd95a566ca3@silverglass.org>
References: <CAJGvTrQeiCxZgutqWUseidpOd9KyaTmpsMw_Muw99ut-21zv+Q@mail.gmail.com>
 <ffd37e35-86f5-b849-9250-cfd95a566ca3@silverglass.org>
Message-ID: <CAJGvTrRiC1UXsGXuNYY1MEj7eaSC=jMSY4bEUO7ODj2YO2YpbA@mail.gmail.com>

Right - forgot about that effort... and forgot to "complain" that it
was not integrated with pyca/cryptography ;-)

On Tue, Jun 14, 2016 at 11:02 AM, Todd Knarr <tknarr at silverglass.org> wrote:
> On 06/14/2016 10:25 AM, Frank Siebenlist wrote:
>>
>> Any good libraries available?
>> Ideally based on pyca/cryptography - although the implementation
>> choices seem limited (just PBKDF2 unless I missed some...).
>
> There's pyca/bcrypt, it's not part of pyca/cryptography but it's
> Apache-licensed.
>
>
> _______________________________________________
> Cryptography-dev mailing list
> Cryptography-dev at python.org
> https://mail.python.org/mailman/listinfo/cryptography-dev
>

From ansleypeduru96 at gmail.com  Wed Jun 15 10:57:23 2016
From: ansleypeduru96 at gmail.com (Ansley Peduru)
Date: Wed, 15 Jun 2016 10:57:23 -0400
Subject: [Cryptography-dev] pyOpenSSL CRL chaining
Message-ID: <CA+0_recc0z5Mgn=fGQBX0KUmsVmJr6X_X5P4h59S5HKdyqiLCQ@mail.gmail.com>

Hi all,

WIth the recent changes made to enable CRL in verify context objects (see
here https://github.com/pyca/pyopenssl/pull/483) I would like to know some
further functionality. In particular, if this API supports CRL chaining
and/or CRL concatenation. Would a CRL need to contain a full chain of
issuing intermediate CA's and the issuing root CA? Also when we create an
X509Store object we add the certificate in question using add_cert() but
when we use it to verify in the X509StoreContext, must we use the same
certificate? It seems slightly confusing given the lack of documentation. I
am basing most of my assumptions on the unit tests that were merged in.

Regards,
Ansley
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20160615/3218d70f/attachment.html>

From ich at danielneuhaeuser.de  Wed Jun 15 12:09:55 2016
From: ich at danielneuhaeuser.de (=?utf-8?Q?Daniel_Neuh=C3=A4user?=)
Date: Wed, 15 Jun 2016 18:09:55 +0200
Subject: [Cryptography-dev] High-level password hashing module for
 cryptography?
In-Reply-To: <CAJGvTrQeiCxZgutqWUseidpOd9KyaTmpsMw_Muw99ut-21zv+Q@mail.gmail.com>
References: <CAJGvTrQeiCxZgutqWUseidpOd9KyaTmpsMw_Muw99ut-21zv+Q@mail.gmail.com>
Message-ID: <0991BAA5-849B-4658-BA28-BD13A72FDC36@danielneuhaeuser.de>

You should take a look at Passlib[1]. It provides support for all algorithms worth recommending (except argon2, though that will probably change in the future). It has a high level API, so you don?t have to know about the details of the algorithm. It can also perform upgrades to new algorithms or different configurations during verification.

[1]: https://pythonhosted.org/passlib/

From frank.siebenlist at gmail.com  Wed Jun 15 14:12:44 2016
From: frank.siebenlist at gmail.com (Frank Siebenlist)
Date: Wed, 15 Jun 2016 11:12:44 -0700
Subject: [Cryptography-dev] High-level password hashing module for
 cryptography?
In-Reply-To: <0991BAA5-849B-4658-BA28-BD13A72FDC36@danielneuhaeuser.de>
References: <CAJGvTrQeiCxZgutqWUseidpOd9KyaTmpsMw_Muw99ut-21zv+Q@mail.gmail.com>
 <0991BAA5-849B-4658-BA28-BD13A72FDC36@danielneuhaeuser.de>
Message-ID: <CAJGvTrTT3vsv=tRVHcQHABCEHuKtd25SjaLk+YEbqvHf2xq+sQ@mail.gmail.com>

Hi Daniel - Thanks for the pointer! - Didn't know about this passlib
effort and it looks very comprehensive - I'll take a closer look -
Regards, Frank.

On Wed, Jun 15, 2016 at 9:09 AM, Daniel Neuh?user
<ich at danielneuhaeuser.de> wrote:
> You should take a look at Passlib[1]. It provides support for all algorithms worth recommending (except argon2, though that will probably change in the future). It has a high level API, so you don?t have to know about the details of the algorithm. It can also perform upgrades to new algorithms or different configurations during verification.
>
> [1]: https://pythonhosted.org/passlib/
> _______________________________________________
> Cryptography-dev mailing list
> Cryptography-dev at python.org
> https://mail.python.org/mailman/listinfo/cryptography-dev

From frank.siebenlist at gmail.com  Tue Jun 21 00:59:02 2016
From: frank.siebenlist at gmail.com (Frank Siebenlist)
Date: Mon, 20 Jun 2016 21:59:02 -0700
Subject: [Cryptography-dev] High-level password hashing module for
 cryptography?
In-Reply-To: <CAJGvTrTT3vsv=tRVHcQHABCEHuKtd25SjaLk+YEbqvHf2xq+sQ@mail.gmail.com>
References: <CAJGvTrQeiCxZgutqWUseidpOd9KyaTmpsMw_Muw99ut-21zv+Q@mail.gmail.com>
 <0991BAA5-849B-4658-BA28-BD13A72FDC36@danielneuhaeuser.de>
 <CAJGvTrTT3vsv=tRVHcQHABCEHuKtd25SjaLk+YEbqvHf2xq+sQ@mail.gmail.com>
Message-ID: <CAJGvTrQZOHK2quEsW+N=D-VLbr_y3Rtj4Sqo5uKYwPfsfV0FUQ@mail.gmail.com>

passlib looks like a very comprehensive library for password(-hash) management.

However, a number of warts were discussed in this issue:
https://github.com/pyca/cryptography/issues/1149

Some nuggets from that discussion: passlib relies on m2crypto for
openssl support (m2crypto has its own warts), no external backend
support for python 3, and the observation that the best solution may
be cryptography becoming a configurable backend for passlib. What
worries me also is that I do not see a lot of active development
lately on passlib.

In the mean time, I see that the latest versions of both python 2&3
have support for pbkdf2 that also seems to rely on openssl.
How does that compare to pyca/cryptography's?

My plan was to find a good, well vetted, as fast as possible pbkdf2
implementation, and migrate to argon2 once its implementation is
ready. I do recognize that just those implementations are not enough,
and that support for migration to different algos and work-factors are
very important.
Too many imperfect solutions... it's like real life ;-)

Could use some more advise or suggestions...

Thanks, Frank.


On Wed, Jun 15, 2016 at 11:12 AM, Frank Siebenlist
<frank.siebenlist at gmail.com> wrote:
> Hi Daniel - Thanks for the pointer! - Didn't know about this passlib
> effort and it looks very comprehensive - I'll take a closer look -
> Regards, Frank.
>
> On Wed, Jun 15, 2016 at 9:09 AM, Daniel Neuh?user
> <ich at danielneuhaeuser.de> wrote:
>> You should take a look at Passlib[1]. It provides support for all algorithms worth recommending (except argon2, though that will probably change in the future). It has a high level API, so you don?t have to know about the details of the algorithm. It can also perform upgrades to new algorithms or different configurations during verification.
>>
>> [1]: https://pythonhosted.org/passlib/
>> _______________________________________________
>> Cryptography-dev mailing list
>> Cryptography-dev at python.org
>> https://mail.python.org/mailman/listinfo/cryptography-dev

From Nikolaus at rath.org  Mon Jun 27 19:07:05 2016
From: Nikolaus at rath.org (Nikolaus Rath)
Date: Mon, 27 Jun 2016 16:07:05 -0700
Subject: [Cryptography-dev] pyOpenSSL: non-blocking socket support
Message-ID: <87por2xmcm.fsf@thinkpad.rath.org>

Hello,

IIAC, when using the standard library's ssl module, the following can
happen (distilled from http://bugs.python.org/issue22499):

1. User calls SSLSocket.send(something)
2. SSLSocket.send raises SSLWantRead (or SSLWantWrite)
3. User calls select() to wait for Read (or write) readyness of the
   underlying fd.
4. User calls SSLSocket.send(something) again
5. SSLSocket.send raises SSLError

If I understand correctly, this is because the ssl module does not
actually implement the 'struct iostate' state machinery required by
OpenSSL and instead just blindly raises SSLWantRead/SSLWantWrite.

Can someone tell me how pyOpenSSL supports non-blocking socket? Does it
also require the caller to maintain struct iostate, or does it allow to
work with just SSLWantRead/Write and select()?


(Background: I'm wondering if switching to pyOpenSSL would be a feasible
way to tackle https://bitbucket.org/nikratio/s3ql/issues/87).


Thanks,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             ?Time flies like an arrow, fruit flies like a Banana.?

From vladimir.didenko at gmail.com  Tue Jun 28 00:58:01 2016
From: vladimir.didenko at gmail.com (Vladimir Didenko)
Date: Tue, 28 Jun 2016 07:58:01 +0300
Subject: [Cryptography-dev] pyOpenSSL: non-blocking socket support
In-Reply-To: <87por2xmcm.fsf@thinkpad.rath.org>
References: <87por2xmcm.fsf@thinkpad.rath.org>
Message-ID: <CAHRK1yNHqAN6jtPB2i33YB2iL3U0FZM=gYpxpLsAm8-8dzKHOg@mail.gmail.com>

2016-06-28 2:07 GMT+03:00 Nikolaus Rath:

> Hello,
>
> Can someone tell me how pyOpenSSL supports non-blocking socket?


Yes, it does.


> Does it
> also require the caller to maintain struct iostate, or does it allow to
> work with just SSLWantRead/Write and select()?
>

iostate is not required. Just create Python socket, set non-blocking mode
and pass it to SSL.Connection constructor. After that use select/poll/epoll
to check socket readiness and call do_handshake/send/recv.

-- 
? ?????????,
????????.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20160628/6dd6ae77/attachment.html>

From vladimir.didenko at gmail.com  Tue Jun 28 01:23:30 2016
From: vladimir.didenko at gmail.com (Vladimir Didenko)
Date: Tue, 28 Jun 2016 08:23:30 +0300
Subject: [Cryptography-dev] pyOpenSSL: non-blocking socket support
In-Reply-To: <87por2xmcm.fsf@thinkpad.rath.org>
References: <87por2xmcm.fsf@thinkpad.rath.org>
Message-ID: <CAHRK1yNeH0nyZ0MH-EEakzH4nY=BrCTh8WLKfaFTZ7Q0_UDaCA@mail.gmail.com>

2016-06-28 2:07 GMT+03:00 Nikolaus Rath <Nikolaus at rath.org>:

> Hello,
>
> IIAC, when using the standard library's ssl module, the following can
> happen (distilled from http://bugs.python.org/issue22499):
>

I read this issue and it looks like I misunderstood you question.


> If I understand correctly, this is because the ssl module does not
> actually implement the 'struct iostate' state machinery required by
> OpenSSL and instead just blindly raises SSLWantRead/SSLWantWrite.
>

And it shouldn't implement it. It is task for user to handle IO state.


> Can someone tell me how pyOpenSSL supports non-blocking socket? Does it
> also require the caller to maintain struct iostate, or does it allow to
> work with just SSLWantRead/Write and select()?
>

Doesn't differ from standard ssl module.

Resume: you can use nonblocking ssl socket with standard ssl module and
PyOpenSSL. Though it requires some work from you (but it is not hard!).

-- 
Regards,
Vladimir.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20160628/82495572/attachment.html>

From glyph at twistedmatrix.com  Tue Jun 28 01:59:18 2016
From: glyph at twistedmatrix.com (Glyph)
Date: Mon, 27 Jun 2016 22:59:18 -0700
Subject: [Cryptography-dev] pyOpenSSL: non-blocking socket support
In-Reply-To: <CAHRK1yNeH0nyZ0MH-EEakzH4nY=BrCTh8WLKfaFTZ7Q0_UDaCA@mail.gmail.com>
References: <87por2xmcm.fsf@thinkpad.rath.org>
 <CAHRK1yNeH0nyZ0MH-EEakzH4nY=BrCTh8WLKfaFTZ7Q0_UDaCA@mail.gmail.com>
Message-ID: <3C9F11E5-955E-40CF-A592-3267691805D5@twistedmatrix.com>


> On Jun 27, 2016, at 22:23, Vladimir Didenko <vladimir.didenko at gmail.com> wrote:
> 
> Resume: you can use nonblocking ssl socket with standard ssl module and PyOpenSSL. Though it requires some work from you (but it is not hard!).

The better way to use pyOpenSSL (and more recent stdlib ssl modules) is to use Memory BIOs, though.  Twisted migrated many years back from letting OpenSSL do the socket I/O to doing the socket I/O itself and the result has been much more portable, testable, and reliable.

-glyph
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20160627/23b2417a/attachment.html>

From Nikolaus at rath.org  Tue Jun 28 12:24:54 2016
From: Nikolaus at rath.org (Nikolaus Rath)
Date: Tue, 28 Jun 2016 09:24:54 -0700
Subject: [Cryptography-dev] pyOpenSSL: non-blocking socket support
In-Reply-To: <CAHRK1yNeH0nyZ0MH-EEakzH4nY=BrCTh8WLKfaFTZ7Q0_UDaCA@mail.gmail.com>
 (Vladimir Didenko's message of "Tue, 28 Jun 2016 08:23:30 +0300")
References: <87por2xmcm.fsf@thinkpad.rath.org>
 <CAHRK1yNeH0nyZ0MH-EEakzH4nY=BrCTh8WLKfaFTZ7Q0_UDaCA@mail.gmail.com>
Message-ID: <87lh1pffhl.fsf@thinkpad.rath.org>

On Jun 28 2016, Vladimir Didenko <vladimir.didenko-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org> wrote:
> 2016-06-28 2:07 GMT+03:00 Nikolaus Rath <Nikolaus-BTH8mxji4b0 at public.gmane.org>:
>
>> Hello,
>>
>> IIAC, when using the standard library's ssl module, the following can
>> happen (distilled from http://bugs.python.org/issue22499):
>>
>
> I read this issue and it looks like I misunderstood you question.
>
>
>> If I understand correctly, this is because the ssl module does not
>> actually implement the 'struct iostate' state machinery required by
>> OpenSSL and instead just blindly raises SSLWantRead/SSLWantWrite.
>
> And it shouldn't implement it. It is task for user to handle IO state.

Is there a reason not to implement it in the pyOpenSSL layer, though?

>> Can someone tell me how pyOpenSSL supports non-blocking socket? Does it
>> also require the caller to maintain struct iostate, or does it allow to
>> work with just SSLWantRead/Write and select()?
>
> Doesn't differ from standard ssl module.
>
> Resume: you can use nonblocking ssl socket with standard ssl module and
> PyOpenSSL. Though it requires some work from you (but it is not hard!).

I don't understand why everyone using it would have to re-implement the
same functionality. Would you be interested in a patch that adds this to
pyOpenSSL?

Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             ?Time flies like an arrow, fruit flies like a Banana.?

From Nikolaus at rath.org  Tue Jun 28 12:31:47 2016
From: Nikolaus at rath.org (Nikolaus Rath)
Date: Tue, 28 Jun 2016 09:31:47 -0700
Subject: [Cryptography-dev] pyOpenSSL: non-blocking socket support
In-Reply-To: <3C9F11E5-955E-40CF-A592-3267691805D5@twistedmatrix.com> (Glyph's
 message of "Mon, 27 Jun 2016 22:59:18 -0700")
References: <87por2xmcm.fsf@thinkpad.rath.org>
 <CAHRK1yNeH0nyZ0MH-EEakzH4nY=BrCTh8WLKfaFTZ7Q0_UDaCA@mail.gmail.com>
 <3C9F11E5-955E-40CF-A592-3267691805D5@twistedmatrix.com>
Message-ID: <87inwtff64.fsf@thinkpad.rath.org>

On Jun 27 2016, Glyph <glyph-wgPraSjSqjuEakHPNWoOSQC/G2K4zDHf at public.gmane.org> wrote:
>> On Jun 27, 2016, at 22:23, Vladimir Didenko <vladimir.didenko-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org> wrote:
>> 
>> Resume: you can use nonblocking ssl socket with standard ssl module
>> and PyOpenSSL. Though it requires some work from you (but it is not
>> hard!).
>
> The better way to use pyOpenSSL (and more recent stdlib ssl modules)
> is to use Memory BIOs, though.  Twisted migrated many years back from
> letting OpenSSL do the socket I/O to doing the socket I/O itself and
> the result has been much more portable, testable, and reliable.

Thanks! I think this is what I'll use.

Do you have any guidelines when to pick pyOpenSSL versus the stdlib's
ssl module (assuming that there are no outside constraints)?

Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             ?Time flies like an arrow, fruit flies like a Banana.?

From Nikolaus at rath.org  Tue Jun 28 12:50:09 2016
From: Nikolaus at rath.org (Nikolaus Rath)
Date: Tue, 28 Jun 2016 09:50:09 -0700
Subject: [Cryptography-dev] pyOpenSSL: non-blocking socket support
In-Reply-To: <3C9F11E5-955E-40CF-A592-3267691805D5@twistedmatrix.com> (Glyph's
 message of "Mon, 27 Jun 2016 22:59:18 -0700")
References: <87por2xmcm.fsf@thinkpad.rath.org>
 <CAHRK1yNeH0nyZ0MH-EEakzH4nY=BrCTh8WLKfaFTZ7Q0_UDaCA@mail.gmail.com>
 <3C9F11E5-955E-40CF-A592-3267691805D5@twistedmatrix.com>
Message-ID: <87d1n1febi.fsf@thinkpad.rath.org>

On Jun 27 2016, Glyph <glyph-wgPraSjSqjuEakHPNWoOSQC/G2K4zDHf at public.gmane.org> wrote:
>> On Jun 27, 2016, at 22:23, Vladimir Didenko <vladimir.didenko-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org> wrote:
>> 
>> Resume: you can use nonblocking ssl socket with standard ssl module
>> and PyOpenSSL. Though it requires some work from you (but it is not
>> hard!).
>
> The better way to use pyOpenSSL (and more recent stdlib ssl modules)
> is to use Memory BIOs, though.  Twisted migrated many years back from
> letting OpenSSL do the socket I/O to doing the socket I/O itself and
> the result has been much more portable, testable, and reliable.

Hum. When using BIOs, does this mean that I can safely refill/read-out
the BIO when getting SSLWantRead/SSLWantRead and then call the SSL
function again, or do I need to keep track of the detailed io state
again?

Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             ?Time flies like an arrow, fruit flies like a Banana.?

From simo at redhat.com  Tue Jun 28 14:11:34 2016
From: simo at redhat.com (Simo Sorce)
Date: Tue, 28 Jun 2016 14:11:34 -0400
Subject: [Cryptography-dev] Fernet NG or alternative simple, high-level,
 encrypted message module?
In-Reply-To: <CAJGvTrSp2jUZ-h-EptXEAb8E1nAiGZTGE0A7kziXAysj5ZzEYQ@mail.gmail.com>
References: <948A93A3-0FBC-41CB-937E-DFF2A7FBEC9D@gmail.com>
 <CABj5TKQRNAv8p1X-fy8C5pSHKdGSk+m89Fmz8Wn3OLpThX8ggw@mail.gmail.com>
 <1465823210.3498.49.camel@redhat.com>
 <CAJGvTrSp2jUZ-h-EptXEAb8E1nAiGZTGE0A7kziXAysj5ZzEYQ@mail.gmail.com>
Message-ID: <1467137494.3121.8.camel@redhat.com>

I see no problem matching the license, let's discuss if this merge can
be done and I will change the license as we start working on it for
real.

Simo.

On Tue, 2016-06-14 at 09:19 -0700, Frank Siebenlist wrote:
> Hi Simo - if you could accommodate the jwcrypto-license to match
> pyca/cryptography's... that would be fantastic and generous!!! -
> Thanks, Frank.
> 
> On Mon, Jun 13, 2016 at 6:06 AM, Simo Sorce <simo at redhat.com> wrote:
> > On Sun, 2016-06-12 at 23:51 -0400, Paul Kehrer wrote:
> >> In general I'm in favor of pulling jwcrypto (or something like it)
> >> into cryptography. The obstacles are going to be figuring out the
> >> licensing (cryptography is Apache2/BSD dual licensed and any code
> >> contributed to it needs to be available under those licenses),
> >> discussing what (if any) API changes need to be made to fit in with
> >> the API design of the hazmat layer, and general "make the code style
> >> match cryptography".
> >
> > Jwcrypto author here,
> > from my POV we can discuss license/API/style adjustments needed, just
> > let me know in which form you want to have this discussion.
> >
> > Simo.
> >
> > --
> > Simo Sorce * Red Hat, Inc * New York
> >
> > _______________________________________________
> > 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


-- 
Simo Sorce * Red Hat, Inc * New York


From cory at lukasa.co.uk  Tue Jun 28 15:25:07 2016
From: cory at lukasa.co.uk (Cory Benfield)
Date: Tue, 28 Jun 2016 20:25:07 +0100
Subject: [Cryptography-dev] pyOpenSSL: non-blocking socket support
In-Reply-To: <87lh1pffhl.fsf@thinkpad.rath.org>
References: <87por2xmcm.fsf@thinkpad.rath.org>
 <CAHRK1yNeH0nyZ0MH-EEakzH4nY=BrCTh8WLKfaFTZ7Q0_UDaCA@mail.gmail.com>
 <87lh1pffhl.fsf@thinkpad.rath.org>
Message-ID: <9878D43A-F6F6-48E4-8C7D-2D07D5DD08C4@lukasa.co.uk>


> On 28 Jun 2016, at 17:24, Nikolaus Rath <Nikolaus at rath.org> wrote:
> 
> I don't understand why everyone using it would have to re-implement the
> same functionality. Would you be interested in a patch that adds this to
> pyOpenSSL?

We would not, for two reasons. Firstly, PyOpenSSL?s stated goal is of being a thin wrapper around OpenSSL?s APIs, rather than the full OpenSSL abstraction layer that the stdlib ssl module (claims to) implement.

Secondly, PyOpenSSL is now in maintenance mode: we?re aiming to slowly transition users to cryptography.io as it becomes more fully-featured and able to replace PyOpenSSL. We will still fix bugs and and will resolve glaring holes in features that cryptography does not have, but otherwise we?ve got a ?no new features? policy.

Cory
-------------- 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: <http://mail.python.org/pipermail/cryptography-dev/attachments/20160628/46bc9027/attachment.sig>

From cory at lukasa.co.uk  Tue Jun 28 15:29:03 2016
From: cory at lukasa.co.uk (Cory Benfield)
Date: Tue, 28 Jun 2016 20:29:03 +0100
Subject: [Cryptography-dev] pyOpenSSL: non-blocking socket support
In-Reply-To: <87d1n1febi.fsf@thinkpad.rath.org>
References: <87por2xmcm.fsf@thinkpad.rath.org>
 <CAHRK1yNeH0nyZ0MH-EEakzH4nY=BrCTh8WLKfaFTZ7Q0_UDaCA@mail.gmail.com>
 <3C9F11E5-955E-40CF-A592-3267691805D5@twistedmatrix.com>
 <87d1n1febi.fsf@thinkpad.rath.org>
Message-ID: <951DC0C8-60DC-45D0-A150-20861E953DEB@lukasa.co.uk>


> On 28 Jun 2016, at 17:50, Nikolaus Rath <Nikolaus at rath.org> wrote:
> 
> Hum. When using BIOs, does this mean that I can safely refill/read-out
> the BIO when getting SSLWantRead/SSLWantRead and then call the SSL
> function again, or do I need to keep track of the detailed io state
> again?
> 
> Best,
> -Nikolaus

If you get SSLWantRead it?s a signal that you?re waiting for more data from the socket: you shouldn?t expect to see SSLWantWrite in regular use with a BIO. You shove application data in: if you get no error, you write out as much as you can from the BIO. If you get WantRead, you make sure you go back to the socket because you need some data from it.

If you want to see what Twisted does, it?s in the TLSMemoryBIOProtocol class here: https://github.com/twisted/twisted/blob/trunk/twisted/protocols/tls.py#L216
-------------- 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: <http://mail.python.org/pipermail/cryptography-dev/attachments/20160628/1526620c/attachment-0001.sig>

From Nikolaus at rath.org  Tue Jun 28 18:46:08 2016
From: Nikolaus at rath.org (Nikolaus Rath)
Date: Tue, 28 Jun 2016 15:46:08 -0700
Subject: [Cryptography-dev] pyOpenSSL: non-blocking socket support
In-Reply-To: <951DC0C8-60DC-45D0-A150-20861E953DEB@lukasa.co.uk> (Cory
 Benfield's message of "Tue, 28 Jun 2016 20:29:03 +0100")
References: <87por2xmcm.fsf@thinkpad.rath.org>
 <CAHRK1yNeH0nyZ0MH-EEakzH4nY=BrCTh8WLKfaFTZ7Q0_UDaCA@mail.gmail.com>
 <3C9F11E5-955E-40CF-A592-3267691805D5@twistedmatrix.com>
 <87d1n1febi.fsf@thinkpad.rath.org>
 <951DC0C8-60DC-45D0-A150-20861E953DEB@lukasa.co.uk>
Message-ID: <874m8dexu7.fsf@thinkpad.rath.org>

On Jun 28 2016, Cory Benfield <cory-4cWZ1Abt8O3QXOPxS62xeg at public.gmane.org> wrote:
>> On 28 Jun 2016, at 17:50, Nikolaus Rath <Nikolaus-BTH8mxji4b0 at public.gmane.org> wrote:
>> 
>> Hum. When using BIOs, does this mean that I can safely refill/read-out
>> the BIO when getting SSLWantRead/SSLWantRead and then call the SSL
>> function again, or do I need to keep track of the detailed io state
>> again?
>> 
>> Best,
>> -Nikolaus
>
> If you get SSLWantRead it?s a signal that you?re waiting for more data
> from the socket: you shouldn?t expect to see SSLWantWrite in regular
> use with a BIO.

What happens if the data that OpenSSL wants to send doesn't fit in the
provided BIO? Shouldn't that raise SSLWantWrite?

> You shove application data in: if you get no error,
> you write out as much as you can from the BIO.

...but that may not be enough.

> If you get WantRead, you make sure you go back to the socket because
> you need some data from it.

That's the behavior that I would expect, yes. It is also what I would
expect to be the right method when using ssl (or PyOpenSSL) with
non-blocking sockets. But in the latter cases is actually insufficient,
so I've grown cautious.

Best,
-Nikolaus


-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             ?Time flies like an arrow, fruit flies like a Banana.?

From cooljay.gupta at gmail.com  Thu Jun 30 02:09:25 2016
From: cooljay.gupta at gmail.com (Jay Gupta)
Date: Thu, 30 Jun 2016 11:39:25 +0530
Subject: [Cryptography-dev] use of poor implementations of algorithms
Message-ID: <CAMusu9SMg_de9jwvX_2LjKT4NG+9j4+EeP5i0kBhQWQjnbtFaw@mail.gmail.com>

could you provide concrete examples of your criticism of other Python
cryptographic packages, especially about poor algorithm interpretations?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20160630/70b267aa/attachment.html>

From glyph at twistedmatrix.com  Thu Jun 30 18:10:49 2016
From: glyph at twistedmatrix.com (Glyph Lefkowitz)
Date: Thu, 30 Jun 2016 15:10:49 -0700
Subject: [Cryptography-dev] use of poor implementations of algorithms
In-Reply-To: <CAMusu9SMg_de9jwvX_2LjKT4NG+9j4+EeP5i0kBhQWQjnbtFaw@mail.gmail.com>
References: <CAMusu9SMg_de9jwvX_2LjKT4NG+9j4+EeP5i0kBhQWQjnbtFaw@mail.gmail.com>
Message-ID: <7DCA0A19-21FC-467A-BBD9-A8C11FB98D08@twistedmatrix.com>


> On Jun 29, 2016, at 23:09, Jay Gupta <cooljay.gupta at gmail.com> wrote:
> 
> could you provide concrete examples of your criticism of other Python cryptographic packages, especially about poor algorithm interpretations?

What specific criticism are you referring to?  Cryptography developers have been critical of other packages (and their own!) in a variety of contexts.

-glyph
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20160630/7490d672/attachment.html>

From alex.gaynor at gmail.com  Thu Jun 30 18:11:53 2016
From: alex.gaynor at gmail.com (Alex Gaynor)
Date: Thu, 30 Jun 2016 18:11:53 -0400
Subject: [Cryptography-dev] use of poor implementations of algorithms
In-Reply-To: <7DCA0A19-21FC-467A-BBD9-A8C11FB98D08@twistedmatrix.com>
References: <CAMusu9SMg_de9jwvX_2LjKT4NG+9j4+EeP5i0kBhQWQjnbtFaw@mail.gmail.com>
 <7DCA0A19-21FC-467A-BBD9-A8C11FB98D08@twistedmatrix.com>
Message-ID: <CAFRnB2V5Fggr7-s4a8=O=mM6y9OPZWkWnS4bx7yt4xn-LRQynQ@mail.gmail.com>

Probably the one in our readme/homepage.

It's been a while since we wrote that. If I recall correctly, PyCrypto's
AES implementation is vulnerable to the cache timing side-channel that DJB
wrote about many years ago.

Alex

On Thu, Jun 30, 2016 at 6:10 PM, Glyph Lefkowitz <glyph at twistedmatrix.com>
wrote:

>
> On Jun 29, 2016, at 23:09, Jay Gupta <cooljay.gupta at gmail.com> wrote:
>
> could you provide concrete examples of your criticism of other Python
> cryptographic packages, especially about poor algorithm interpretations?
>
>
> What specific criticism are you referring to?  Cryptography developers
> have been critical of other packages (and their own!) in a variety of
> contexts.
>
> -glyph
>
> _______________________________________________
> 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: <http://mail.python.org/pipermail/cryptography-dev/attachments/20160630/2be00108/attachment.html>