[Cryptography-dev] Low level API for Symmetric Encryption

Thu Aug 8 03:17:13 CEST 2013

Yeah, the composition between the mode and cipher objects would be purely
at the python layer, what you end up with is a single object which has an
EVP_CIPHER.

Alex

On Wed, Aug 7, 2013 at 6:15 PM, Paul Kehrer <paul.l.kehrer at gmail.com> wrote:

> 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
> >
> _______________________________________________
> 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/aa606be6/attachment-0001.html>