Author dstufft
Recipients Arfrever, alex, benjamin.peterson, christian.heimes, dstufft, ezio.melotti, jcea, lemburg, markk, ncoghlan, pitrou, python-dev, r.david.murray, vstinner
Date 2014-04-23.13:44:10
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1398260650.97.0.129969618495.issue20995@psf.upfronthosting.co.za>
In-reply-to
Content
> I think performance isn't really relevant, except perhaps on very busy
> servers. A smartphone acting as a *client* certainly shouldn't need to
> download 20 MB/s of encrypted data.

Well, if you factor out performance then ChaCha20Poly1305 and AES-GCM are more
or less equivalent in preference with AES-CBC still less than either of them
because of problematic construction choices in the TLS spec. If you factor
out performance completely there is maybe a slight preference for
ChaCha20Poly1305 over AES-GCM simply because AES-GCM is hard to implement in
a timing safe way in software. However that discussion is mostly academic as
right now ChaCha20Poly1305 is not available in OpenSSL.

In general I agree that the performance of all of these are "good enough" that
the average user of this API won't be able to tell the difference, however
there is no cost to selecting the generally more performant of the two so I
think it still makes sense to consider it.

Hopefully what I was trying to achieve was provide some more context for markk so he'd hopefully be able to better understand why the string cipher calls out AES specifically before falling back to HIGH.
History
Date User Action Args
2014-04-23 13:44:11dstufftsetrecipients: + dstufft, lemburg, jcea, ncoghlan, pitrou, vstinner, christian.heimes, benjamin.peterson, ezio.melotti, Arfrever, alex, r.david.murray, python-dev, markk
2014-04-23 13:44:10dstufftsetmessageid: <1398260650.97.0.129969618495.issue20995@psf.upfronthosting.co.za>
2014-04-23 13:44:10dstufftlinkissue20995 messages
2014-04-23 13:44:10dstufftcreate