Hi,
On 10/26/2013 02:13 PM, Werner Koch wrote:
> On Sat, 26 Oct 2013 11:35, b...@beuc.net said:
>
>> Plus, following this principle, why doesn't gnupg default to 4096 if
>> there isn't any reason not to? I would suppose that if gnupg defaults
>
> 4k primary RSA keys increase the size of the signatures and thus make
> the keyrings longer and, worse, computing the web of trust takes much
> longer. Yeah, not on your high end desktop machine but on old laptops
> and my N900 phone. It also drains the battery faster.
Numbers please? Or are you talking about personal/subjective impressions?
Seems to be that one of the main ideas behind modern consumer computing
is to address increasing need of processing capability and storage space
(despite hype surrounding cloud products).
Software is growing and is becoming more complicated, less care and
effort is given to manual craftsmanship in this field, higher level
languages and frameworks are more common. All this comes with a price of
increased processing power requirement and most of the hardware vendors
are doing really good here (really happily).
Also making an imperative from supporting ancient and legacy devices
(and I'm not saying N900 is ancient) is somehow controversial.
> There is no benefit of overly large keys on average computers. After
> all the goal is not to have large key but to protect something. Now, if
> you want to protect something you need to think like the attacker - what
> will an attacker do to get the plaintext (or fake a signature)? Spend
> millions on breaking a few 2k keys (assuming this is at all possible
> within the next decade) or buy/develop/use a zero-day?
On the other hand, one of the conclusions that Mr Schneier presented was
that in case of doubt increasing length of the key is easy and nice
approach. So looks like definition of "overly large" could be somehow
subjective.
> Instead of discussing these numbers the time could be much better use to
> audit the used software (firmware, OS, libs, apps).
I would say it would be good to do that in addition/in parallel, not
instead.
Cheers,
Filip
_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
