[Cryptography-dev] PyCon & Releases

Jarret Raim jarret.raim at RACKSPACE.COM
Wed Dec 18 04:56:25 CET 2013


>> 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: <http://mail.python.org/pipermail/cryptography-dev/attachments/20131218/27b18da7/attachment.bin>


More information about the Cryptography-dev mailing list