On Wed, 21 Dec 2016 17:47, [email protected] said: > Everybody know CTR is easy to parallelize and easy to understand implement,
CTR is a reincarnation of RC4 - bug wise. Nobody with a sane mind wants a counter mode. It is also not an AE mode and thus nothing to be used for new protocols. > CCM is another options - > http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/proposedmodes/ccm/ccm.pdf FWIW, here are the numbers fro current Libgcrypt on amd64: AES | nanosecs/byte mebibytes/sec cycles/byte CFB enc | 1.77 ns/B 537.9 MiB/s 4.08 c/B -- non-AE CFB dec | 0.373 ns/B 2554.7 MiB/s 0.859 c/B -- non-AE CTR enc | 0.396 ns/B 2409.6 MiB/s 0.910 c/B -- non-AE CTR dec | 0.396 ns/B 2409.9 MiB/s 0.910 c/B -- non-AE CCM enc | 2.19 ns/B 435.6 MiB/s 5.04 c/B CCM dec | 2.25 ns/B 423.7 MiB/s 5.18 c/B GCM enc | 1.07 ns/B 890.9 MiB/s 2.46 c/B GCM dec | 1.07 ns/B 890.8 MiB/s 2.46 c/B OCB enc | 0.440 ns/B 2165.9 MiB/s 1.01 c/B OCB dec | 0.453 ns/B 2107.5 MiB/s 1.04 c/B So, CCM is pretty slow. The whole reason why we have that slow CCM is due to patent fears. And it is cumbersome to work with. > still most of the work can be parallelized, and if authentication stage is > faster than encryption, it should not be a bottlneck for performance. It is anyway I/O bounded. This is why I wrote theoretical speedup. For backing up large amounts of data, gpg is not an optimal tool. If there is a real need for a faster tool we could add one to GnuPG which does only one thing (symmetric encryption) without the various options possible in OpenPGP. bugs.gnupg.org has a “wish” category. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
pgpeyacKGKmHu.pgp
Description: PGP signature
