[Cryptography-dev] Low level API for Symmetric Encryption

[Paul Kehrer]

That sounds workable.

A few more questions around Jean-Paul's proposal then...

Are people comfortable significantly changing the standard conventions
for instantiation of block ciphers? I'm not aware of any major crypto
APIs that currently build via mode(cipher()), although that might just
be my ignorance.

Since the underlying library is still OpenSSL this means constructs
like CBC(AES(key_size=256), iv) will result in a BlockCipherMode
object that holds an EVP_CIPHER, correct? For methods that can take an
EVP_CIPHER (such as PEM_write_bio_RSAPrivateKey) you would need to
pass in that BlockCipherMode object then.

The AES() object itself would be used primarily for setting the key,
getting the block size of the cipher, and being passed as a parameter
into the mode constructor. It could not have an EVP_CIPHER since that
implies a chosen mode.

On Wed, Aug 7, 2013 at 7:57 PM, Donald Stufft <donald at stufft.io> wrote:
>
> On Aug 7, 2013, at 8:36 PM, Paul Kehrer <paul.l.kehrer at gmail.com> wrote:
>
>> GCM is only defined for block ciphers of 128/192/256 bit block
>> lengths. So a construction of GCM(DES()) would have to throw an
>> exception since DES uses a 64-bit block size.
>
> Yea the modes would need to know what properties the cipher needs to have
> in order to work with it. So GCM would need to check that it is a block cipher
> with a block size of 128, 192, or 256. It shouldn't check based on name of
> course.
>
>>
>> On Wed, Aug 7, 2013 at 7:30 PM, Donald Stufft <donald at stufft.io> wrote:
>>>
>>> On Aug 7, 2013, at 8:16 PM, Alex Gaynor <alex.gaynor at gmail.com> wrote:
>>>
>>> I guess the fact that different modes have fundamentally different APIs
>>> (e.g. GCM needs a MAC, CTR needs the counter, etc.) really points to that
>>> they should have different classes.
>>>
>>> How about keysize, do we need a class for each?
>>>
>>>
>>> AFAIK there's no API differences for key size, it's just the size of the key
>>> and the name you tell openssl.
>>>
>>> OTOH now that I think about it more, maybe I'm looking at it backwards, I'm
>>> thinking about it like AES is the important part of GCM(AES128()) that
>>> Jean-Paul mentioned, but really it's the other way around. The differences
>>> between GCM vs CBC vs Whatever are not specific to key size or cipher.
>>>
>>> So if GCM/CBC/etc were the driving forces of the API interaction with
>>> OpenSSL and there is (I believe) no difference other than parameters you
>>> call the API's with for algo/key size instead of the way I was thinking of
>>> it where AES128() were the driving I think it would work assuming I'm right
>>> about that.
>>>
>>>
>>>
>>> Alex
>>>
>>>
>>> On Wed, Aug 7, 2013 at 5:12 PM, Donald Stufft <donald at stufft.io> wrote:
>>>>
>>>>
>>>> On Aug 7, 2013, at 7:18 PM, Alex Gaynor <alex.gaynor at gmail.com> wrote:
>>>>
>>>> Another option is to compose them in the constructor: AES(keysize=256,
>>>> mode=GCM) or so.
>>>>
>>>> Alex
>>>>
>>>>
>>>> We'd still essentially be passing AES-256-GCM into OpenSSL afaik. So afaik
>>>> it'd only look like composing. We're not handling (most) of the differences
>>>> between the modes (and none of the differences for key size).
>>>>
>>>> The mode classes could be stuff that handles the slight differences in how
>>>> you call the API (for instance GCM has an additional call to
>>>> EVP_EncryptUpdate to give it the AAD and a different calls to handle getting
>>>> the MAC data. I'm not sure how well that'd translate? It might work ok.
>>>>
>>>>
>>>>
>>>> On Wed, Aug 7, 2013 at 4:12 PM, Donald Stufft <donald at stufft.io> wrote:
>>>>>
>>>>>
>>>>> On Aug 7, 2013, at 6:32 PM, Jean-Paul Calderone
>>>>> <jean-paul at hybridcluster.com> wrote:
>>>>>
>>>>>> On 08/07/2013 06:16 PM, Donald Stufft 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.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> GCM (CBC, etc) is a mode of operation that is applicable to arbitrary
>>>>>> block ciphers.
>>>>>>
>>>>>> Why should it be tied to "AES128"?  Why wouldn't you GCM(AES128())?  If
>>>>>> you're talking about primitives, AES128 is more primitive than GCM on
>>>>>> AES128.  And GCM isn't specific to AES, so I don't see
>>>>>> cryptography.primitives.aes as the proper home for it.
>>>>>>
>>>>>> I hope these aren't questions with highly obvious answers.
>>>>>
>>>>> As far as I know (and I could be wrong? I don't know OpenSSL guts that
>>>>> well) OpenSSL doesn't do composition like that, in order to get AES-128-GCM
>>>>> you pass that in.
>>>>>
>>>>> Is there a way to access openssl where you're composing GCM with AES128?
>>>>> If not I think we'd be stuck do some sort of "combine variables of the
>>>>> classes AES128 and GCM to make the name AES-128-GCM to pass into openssl"
>>>>> thing which doesn't feel particularly clean to me?
>>>>>
>>>>>
>>>>> -----------------
>>>>> 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
>>>
>> _______________________________________________
>> 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
>