[Cryptography-dev] Low level API for Symmetric Encryption

[Donald Stufft]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20130807/530e9440/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20130807/530e9440/attachment-0001.pgp>