Kristian Fiskerstrand kristian.fiskerstrand at kfwebs.net
Thu Sep 28 06:46:17 CEST 2006

Hash: SHA1

Carlo Luciano Bianco wrote, On 09/28/2006 12:46 AM:
> Il /27 set 2006/, *Robert J. Hansen* ha scritto:
>> Carlo Luciano Bianco wrote:
>>> Needless to say, I completely agree with both you and Werner on
>>> this. This discussion about "balancing" security is very
>>> interesting [at least for me... ;-)] from a theoretical point of
>>> view. I know very well that using this extra-large keys does not
>>> add any security in real life. 
>> There's a contrary view, which says that balancing cryptosystem
>> components is an unnecessary distraction.  This contrary view says
>> that each component of a system should be built to meet or exceed
>> security requirements while meeting or exceeding performance and
>> usability requirements.  As long as each component is in that
>> sweet spot, then you're great.
> I agree with David in saying that this two points of view are not
> necessarily "contrary" to each other. You can chose a "minimum"
> security level and then make sure that all cryptosystem components
> are "balanced" in the sense that they all meet at least such level. 
> This is also because the "equivalence" between the security of a
> DSA/RSA 15-kbit key, SHA-512 and AES-256 comes just from a more or
> less rough estimate and not from a mathematical theorem (AFAIK).
> Therefore, if you "overshoot" the security of a component of your
> cryptosystem, this is not bad. At worst, it is not even good (i.e.
> it is useless), but for sure it is not bad. 
> Just to make an example:
> I am currently using a 4096-bit RSA key, with AES-256 and SHA-512 as
> "preferred" algorithms. I am not going to switch back to AES-128 and
> SHA-256 to have a "balanced" system. I will stay with AES-256 and
> SHA-512, even if they are estimated to be much more secure than
> 4096-bit RSA keys (and therefore maybe "useless"). In this way, I
> can be reasonably sure that the weakest component of my cryptosystem
> is the 4096-bit RSA key. But such a key meets my minimum security
> requirements, so I am safe. 
> The "balance" requirement for my cryptosystem means that I will
> bother GnuPG developers about adding full support for longer public
> keys before bothering them about longer symmetric keys and longer 
> hashes, instead of viceversa... ;-)

Last time I checked GnuPG supported to read larger keys, to generate
them only requires altering the max variable in the sourecode. I used
this to test the performance on a system with some different keysizes,
one of them being 15,360 bits.

The 15,360bit ElGamal encryption key took me about 20 hours to generate
on an Intel Centrino 1400MHz. Which is more that what would be
considered practical for ordinary uses, on the same computer encrypting
a file took about 33 seconds using the key. It was slower ( 44 seconds )
on my Dual PIII 1000MHz, as it wasn't shared across the CPUs (
http://www.kfwebs.net/news/62/Experimenting-with-GnuPG )

I CCed the sender as some posts of mine in the past have never reached
the list, probably due to using a different sender address and moderation.

Yours sincerely
- --
- ----------------------------
Kristian Fiskerstrand
- ----------------------------
This email was digitally signed using the OpenPGP
standard. If you want to read more about this, visit:
- ----------------------------
- ----------------------------
Public PGP key 0x6B0B9508 at http://www.kfwebs.net/pgp/

Version: GnuPG v1.4.5-svn4189 (GNU/Linux)


More information about the Gnupg-devel mailing list