Daniel Kahn Gillmor
dkg at fifthhorseman.net
Tue Jun 2 21:01:21 CEST 2015
On Tue 2015-06-02 14:38:13 -0400, Werner Koch wrote:
> On Tue, 2 Jun 2015 19:25, dkg at fifthhorseman.net said:
>>> I am fine to switch to AES-128 for 2.0 too.
>> Any reason to avoid it for the 1.4 branch?
> Can be done.
Thanks, making all the branches have the same defaults when they support
the same algorithms seems reasonable to me.
>> This is the case for symmetric backups. For secret key protection, the
>> time difference is negligible compared to things like passphrase entry.
> Secret key protection does not require that strength. Do you really
> thing anyone is using a passphrase (intended to be memorized) with more
> than 128 bit of entropy?
No, i suspect that most people are not. But (a) why limit them to it?
and (b) as i mentioned to Robert, depending on the attacks against
AES-128, and how much key material is intended to be protected, there
may be attacks against AES that are significantly more effective than
brute force over the entire keyspace.
> Anywa, I won't care whether this is AES-256 or AES-128 - implementation
> wise it does not make a real difference to implement one or both.
Both are implemented already. I'm asking about what the default should
>> 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
> Why using cycles and energy without a reason?
To protect data at rest against a powerful adversary, right?
More information about the Gnupg-devel