[Cryptography-dev] Low level API for Symmetric Encryption

[Paul Kehrer]

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.

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
>