[Cryptography-dev] PyCon & Releases

[Alex Gaynor]

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 <alexs at prol.etari.at> 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 :)
>
>  <snip>
>>>
>>
>  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: <http://mail.python.org/pipermail/cryptography-dev/attachments/20131218/74ef4957/attachment.html>