<div dir="ltr">That makes sense, InvalidCipher or something.<div><br></div><div>Alex</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Aug 7, 2013 at 5:36 PM, Paul Kehrer <span dir="ltr"><<a href="mailto:paul.l.kehrer@gmail.com" target="_blank">paul.l.kehrer@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">GCM is only defined for block ciphers of 128/192/256 bit block<br>
lengths. So a construction of GCM(DES()) would have to throw an<br>
exception since DES uses a 64-bit block size.<br>
<div class="HOEnZb"><div class="h5"><br>
On Wed, Aug 7, 2013 at 7:30 PM, Donald Stufft <<a href="mailto:donald@stufft.io">donald@stufft.io</a>> wrote:<br>
><br>
> On Aug 7, 2013, at 8:16 PM, Alex Gaynor <<a href="mailto:alex.gaynor@gmail.com">alex.gaynor@gmail.com</a>> wrote:<br>
><br>
> I guess the fact that different modes have fundamentally different APIs<br>
> (e.g. GCM needs a MAC, CTR needs the counter, etc.) really points to that<br>
> they should have different classes.<br>
><br>
> How about keysize, do we need a class for each?<br>
><br>
><br>
> AFAIK there's no API differences for key size, it's just the size of the key<br>
> and the name you tell openssl.<br>
><br>
> OTOH now that I think about it more, maybe I'm looking at it backwards, I'm<br>
> thinking about it like AES is the important part of GCM(AES128()) that<br>
> Jean-Paul mentioned, but really it's the other way around. The differences<br>
> between GCM vs CBC vs Whatever are not specific to key size or cipher.<br>
><br>
> So if GCM/CBC/etc were the driving forces of the API interaction with<br>
> OpenSSL and there is (I believe) no difference other than parameters you<br>
> call the API's with for algo/key size instead of the way I was thinking of<br>
> it where AES128() were the driving I think it would work assuming I'm right<br>
> about that.<br>
><br>
><br>
><br>
> Alex<br>
><br>
><br>
> On Wed, Aug 7, 2013 at 5:12 PM, Donald Stufft <<a href="mailto:donald@stufft.io">donald@stufft.io</a>> wrote:<br>
>><br>
>><br>
>> On Aug 7, 2013, at 7:18 PM, Alex Gaynor <<a href="mailto:alex.gaynor@gmail.com">alex.gaynor@gmail.com</a>> wrote:<br>
>><br>
>> Another option is to compose them in the constructor: AES(keysize=256,<br>
>> mode=GCM) or so.<br>
>><br>
>> Alex<br>
>><br>
>><br>
>> We'd still essentially be passing AES-256-GCM into OpenSSL afaik. So afaik<br>
>> it'd only look like composing. We're not handling (most) of the differences<br>
>> between the modes (and none of the differences for key size).<br>
>><br>
>> The mode classes could be stuff that handles the slight differences in how<br>
>> you call the API (for instance GCM has an additional call to<br>
>> EVP_EncryptUpdate to give it the AAD and a different calls to handle getting<br>
>> the MAC data. I'm not sure how well that'd translate? It might work ok.<br>
>><br>
>><br>
>><br>
>> On Wed, Aug 7, 2013 at 4:12 PM, Donald Stufft <<a href="mailto:donald@stufft.io">donald@stufft.io</a>> wrote:<br>
>>><br>
>>><br>
>>> On Aug 7, 2013, at 6:32 PM, Jean-Paul Calderone<br>
>>> <<a href="mailto:jean-paul@hybridcluster.com">jean-paul@hybridcluster.com</a>> wrote:<br>
>>><br>
>>> > On 08/07/2013 06:16 PM, Donald Stufft wrote:<br>
>>> >> So to kick things off I'd like to get AES-GCM exposed and figured it<br>
>>> >> could be a good way to start the ball rolling for figuring out how we want<br>
>>> >> to expose symmetric ciphers at the low level API.<br>
>>> >><br>
>>> >> I'm thinking cryptography.primitives.aes which has classes named like<br>
>>> >> AES128GCM, AES256CBC, etc. The obvious naming scheme being<br>
>>> >> AlgorithmKeysizeMode.<br>
>>> >><br>
>>> >><br>
>>> ><br>
>>> > GCM (CBC, etc) is a mode of operation that is applicable to arbitrary<br>
>>> > block ciphers.<br>
>>> ><br>
>>> > Why should it be tied to "AES128"?  Why wouldn't you GCM(AES128())?  If<br>
>>> > you're talking about primitives, AES128 is more primitive than GCM on<br>
>>> > AES128.  And GCM isn't specific to AES, so I don't see<br>
>>> > cryptography.primitives.aes as the proper home for it.<br>
>>> ><br>
>>> > I hope these aren't questions with highly obvious answers.<br>
>>><br>
>>> As far as I know (and I could be wrong? I don't know OpenSSL guts that<br>
>>> well) OpenSSL doesn't do composition like that, in order to get AES-128-GCM<br>
>>> you pass that in.<br>
>>><br>
>>> Is there a way to access openssl where you're composing GCM with AES128?<br>
>>> If not I think we'd be stuck do some sort of "combine variables of the<br>
>>> classes AES128 and GCM to make the name AES-128-GCM to pass into openssl"<br>
>>> thing which doesn't feel particularly clean to me?<br>
>>><br>
>>><br>
>>> -----------------<br>
>>> Donald Stufft<br>
>>> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372<br>
>>> DCFA<br>
>>><br>
>>><br>
>>> _______________________________________________<br>
>>> Cryptography-dev mailing list<br>
>>> <a href="mailto:Cryptography-dev@python.org">Cryptography-dev@python.org</a><br>
>>> <a href="http://mail.python.org/mailman/listinfo/cryptography-dev" target="_blank">http://mail.python.org/mailman/listinfo/cryptography-dev</a><br>
>>><br>
>><br>
>><br>
>><br>
>> --<br>
>> "I disapprove of what you say, but I will defend to the death your right<br>
>> to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)<br>
>> "The people's good is the highest law." -- Cicero<br>
>> GPG Key fingerprint: 125F 5C67 DFE9 4084<br>
>> _______________________________________________<br>
>> Cryptography-dev mailing list<br>
>> <a href="mailto:Cryptography-dev@python.org">Cryptography-dev@python.org</a><br>
>> <a href="http://mail.python.org/mailman/listinfo/cryptography-dev" target="_blank">http://mail.python.org/mailman/listinfo/cryptography-dev</a><br>
>><br>
>><br>
>><br>
>> -----------------<br>
>> Donald Stufft<br>
>> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372<br>
>> DCFA<br>
>><br>
>><br>
>> _______________________________________________<br>
>> Cryptography-dev mailing list<br>
>> <a href="mailto:Cryptography-dev@python.org">Cryptography-dev@python.org</a><br>
>> <a href="http://mail.python.org/mailman/listinfo/cryptography-dev" target="_blank">http://mail.python.org/mailman/listinfo/cryptography-dev</a><br>
>><br>
><br>
><br>
><br>
> --<br>
> "I disapprove of what you say, but I will defend to the death your right to<br>
> say it." -- Evelyn Beatrice Hall (summarizing Voltaire)<br>
> "The people's good is the highest law." -- Cicero<br>
> GPG Key fingerprint: 125F 5C67 DFE9 4084<br>
> _______________________________________________<br>
> Cryptography-dev mailing list<br>
> <a href="mailto:Cryptography-dev@python.org">Cryptography-dev@python.org</a><br>
> <a href="http://mail.python.org/mailman/listinfo/cryptography-dev" target="_blank">http://mail.python.org/mailman/listinfo/cryptography-dev</a><br>
><br>
><br>
><br>
> -----------------<br>
> Donald Stufft<br>
> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA<br>
><br>
><br>
> _______________________________________________<br>
> Cryptography-dev mailing list<br>
> <a href="mailto:Cryptography-dev@python.org">Cryptography-dev@python.org</a><br>
> <a href="http://mail.python.org/mailman/listinfo/cryptography-dev" target="_blank">http://mail.python.org/mailman/listinfo/cryptography-dev</a><br>
><br>
_______________________________________________<br>
Cryptography-dev mailing list<br>
<a href="mailto:Cryptography-dev@python.org">Cryptography-dev@python.org</a><br>
<a href="http://mail.python.org/mailman/listinfo/cryptography-dev" target="_blank">http://mail.python.org/mailman/listinfo/cryptography-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">"I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)<br>
"The people's good is the highest law." -- Cicero<br><div>GPG Key fingerprint: 125F 5C67 DFE9 4084</div></div>
</div>