[Cryptography-dev] Low level API for Symmetric Encryption

Thu Aug 8 00:41:17 CEST 2013

I'm not sure I totally follow what you said, can you show an example of
using such an API?

Alex

On Wed, Aug 7, 2013 at 3:40 PM, Donald Stufft <donald at stufft.io> wrote:

>
> On Aug 7, 2013, at 6:31 PM, Alex Gaynor <alex.gaynor at gmail.com> wrote:
>
>
>
>
> On Wed, Aug 7, 2013 at 3:27 PM, Donald Stufft <donald at stufft.io> wrote:
>
>>
>> On Aug 7, 2013, at 6:21 PM, Alex Gaynor <alex.gaynor at gmail.com> wrote:
>>
>> A few thoughts:
>>
>> a) I don't like each call to update() returning data, it seems like it
>> should all be buffered in the cipher and then returned at the end.
>>
>>
>> The idea behind returning data is it enables the ability to stream the
>> cipher (albeit at whatever the block size is for block ciphers). If you
>> just buffer it and return it at the end then you can't really do that. Like
>> a list comprehension vs an generator.
>>
>>
> Different API then? I think most people assume update() won't return
> anything (also they'll do bufferring slowly with stuff like += on bytes).
>
>
> Yea we probably need two separate API's now that I think about it, because
> you likely want to either do streaming OR internal buffering. As suggested
> if I was trying to stream 50GB of data through encryption I'd be pretty
> upset if it was getting stored in an internal buffer chewing up 50Gb worth
> of ram by the time we're done.
>
> The other option is to just always have the api take data in, operate on
> it, and return data and never worry about doing any internal buffering.
> Probably need a different name than update though.
>
> This might be a bad idea but we could do ``decrypt()`` and ``encrypt()``
> which function as above (take data in, operate on it, return it) and
> whichever one you call first sets the encrypt vs decrypt flag on that
> instance (so calling one and than the other would be an error).
>
>
>
>>
>> b) I assume it raises an error if you try to do anything after
>> finalization?
>>
>>
>> That'd make the most sense I think, the other alternative is garbage but
>> I think that's bad.
>>
>>
> Garbage bad.
>
>
>>
>> c) I think params like a MAC should just be added to __init__ for ciphers
>> which need them
>>
>>
>> Well for instance for AES-GCM when encrypting you wouldn't add anything
>> to __init__, you'd just need a way to fetch the MAC data that you can use
>> to authenticate the ciphertext. When decrypting you need a way to pass the
>> MAC data in so it can be authenticated (so this could use __init__).
>>
>> The same sort of thing exists for authenticated plaintext too, when
>> encrypting you need to pass it in, when decrypting you get it back out.
>>
>
> Yeah I think passing MAC on decrypt to __init__, and a method to get the
> mac makes the most sense (or have finalize return a tuple?).
>
>
>>
>>
>> d) I don't have any ideas about specifying encrypt vs. decrypt.
>>
>> Alex
>>
>>
>> On Wed, Aug 7, 2013 at 3:16 PM, Donald Stufft <donald at stufft.io> wrote:
>>
>>> So to kick things off I'd like to get AES-GCM exposed and figured it
>>> could be a good way to start the ball rolling for figuring out how we want
>>> to expose symmetric ciphers at the low level API.
>>>
>>> I'm thinking cryptography.primitives.aes which has classes named like
>>> AES128GCM, AES256CBC, etc. The obvious naming scheme being
>>> AlgorithmKeysizeMode.
>>>
>>> classes look something like
>>>
>>> class AES128GCM:
>>>
>>>     # Information about the Cipher
>>>     authenticated = True
>>>     block_size = 128
>>>
>>>     def __init__(self, key, iv, …)
>>>
>>>     def update(self, plaintext)  # Updates an internal buffer as well as
>>> returns the encrypted chunk of data
>>>
>>>     def finalize(self)  # Updates the internal buffer witth finalized
>>> data and returns the same finalized data
>>>
>>>
>>> Some open questions:
>>>
>>> A lot of these are going to be block ciphers, do we want to do padding
>>> for people or expect them to hand us chunks of the correct block size?
>>>
>>> How do we decrypt vs encrypt. I think that:
>>>
>>>     cipher = AES128GCM(key, iv)
>>>     enciphered = cipher.update(plaintext) + cipher.finalize()
>>>
>>>     cipher = AES128GCM(key, iv)
>>>     plaintext = cipher.update(enciphered) + cipher.finalize()
>>>
>>> Makes a decent API here, but we need a way to make a decryption vs
>>> encryption cipher. Possibly something like encrypt=True, or decrypt=True
>>> (specifying both being an error)?
>>>
>>> Some ciphers (AES-GCM included) are authenticated and thus return (and
>>> require giving) a MAC in order to authenticate it, some authenticated
>>> ciphers also support the ability to pass along unencrypted but still
>>> authenticated data as well. I can't think of a decent way of doing this
>>> besides just adding functions (or __init__ args) to pass this data in, does
>>> anyone else have any ideas?
>>>
>>> Any other thoughts? I'm just spitballing here so let's see what we can
>>> come up with!
>>>
>>>
>>> -----------------
>>> Donald Stufft
>>> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372
>>> DCFA
>>>
>>>
>>> _______________________________________________
>>> Cryptography-dev mailing list
>>> Cryptography-dev at python.org
>>> http://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
>> http://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
>> http://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
> http://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
> http://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/20130807/fcbd9f73/attachment.html>