s2k-cipher-mode default

[Daniel Kahn Gillmor]

On Tue 2015-06-02 12:31:24 -0400, Werner Koch wrote:
> On Tue,  2 Jun 2015 17:33, dkg at fifthhorseman.net said:
>
>> I think it should change to AES256, with explanation below.
>
> I am fine to switch to AES-128 for 2.0 too.

Any reason to avoid it for the 1.4 branch?

>> secret key, it should be the strongest symmetric cipher known to the
>> running system.  This is probably AES256, not CAST5 or AES128.
>
> Whether AES-256 is stronger than AES-128 in the real world is a pretty
> good bike shedding topic.  Changing the default cipher to AES-256 should
> be the least problem for those who need such a kind of protection.
>
> Here is my reason why AES-128 is a better *default*:
>
>  AES-128        |  nanosecs/byte   mebibytes/sec   cycles/byte
>         CFB enc |      1.77 ns/B     537.9 MiB/s      4.08 c/B
>         CFB dec |     0.374 ns/B    2548.9 MiB/s     0.861 c/B
>         OCB enc |     0.527 ns/B    1810.8 MiB/s      1.21 c/B
>         OCB dec |     0.546 ns/B    1746.0 MiB/s      1.26 c/B
>
>  AES-256        |  nanosecs/byte   mebibytes/sec   cycles/byte
>         CFB enc |      2.42 ns/B     393.6 MiB/s      5.57 c/B
>         CFB dec |     0.543 ns/B    1755.1 MiB/s      1.25 c/B
>         OCB enc |     0.695 ns/B    1372.9 MiB/s      1.60 c/B
>         OCB dec |     0.728 ns/B    1310.2 MiB/s      1.67 c/B
>
> OpenPGP uses CFB mode.  I listed OCB in case rfc4880bis will switch to
> that mode.
>
> Encrypting with AES-128 is 35% faster than with AES-256.
> Decrypting with AES-128 is 45% faster than with AES-256.
>
> It makes a difference whether you need 32 or 45 minutes to encrypt
> 1TiB.

This is the case for symmetric backups.  For secret key protection, the
time difference is negligible compared to things like passphrase entry.

Do you still think this argument is relevant for secret key protection?

> Yeah, I know this is theoretical because a backup is I/O bounded but
> nevertheless AES-256 takes up more CPU resources than AES-128.

As you say, CPU is not the bottleneck on modern systems dealing with
this kind of data, either large or small.  So why not move to stronger
protections against an adversary who might have visibility of the
ciphertext?

     --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 948 bytes
Desc: not available
URL: </pipermail/attachments/20150602/b02ad1c1/attachment.sig>