DSA2

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


-----BEGIN PGP SIGNED MESSAGE-----
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
http://www.kfwebs.net
- ----------------------------
This email was digitally signed using the OpenPGP
standard. If you want to read more about this, visit:
http://www.secure-my-email.com
- ----------------------------
http://www.secure-my-internet.com
http://www.yourblog.in
- ----------------------------
Public PGP key 0x6B0B9508 at http://www.kfwebs.net/pgp/

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

iQIVAwUBRRtTmRbgz41rC5UIAQLxrxAAo0gDyVbGeDp7MLrcgOq4IrpuigsxbhO4
GVFRyxH8fNpBznbtIVrBXtaFkY8jg/VU20Q4GAaX4iyshwomOlQB+87XYqHQpwlV
/oXUbXKFTswSChNtcmAkoYDI4lLlj22ZAnu0CU6pINe6uYLf6cxRGCti84cIZgCA
4xa2QnHDJbPraEV9ciiAxM7n0p+shD0ovDw5O5rnvA8v2X1oZusxGAFyR6Aw6HDN
R2I8e4822s6Or/NEaeYot9Ef7tNLnmpzgAdDVSNkHC4NEwp/Xqs4NQ6q2tfQVVZH
k6tofDyoGq/c0QOEMFoHgmReIpTu2ku48h9yqekRKdYnURDc8//ANwAMdKp9tq98
t+emQms6VHwimcYwzVz2rRofemP+WqPxEuj9FOytiNLvgsLlVXgA1ItK5la9Mfuq
v05qSOXn431yrSu5Wwq3K4y5cTbiNuJG9VbVxbrkJfshHtFD/GoGSoF3rUcTNLwv
CqLz9n4F6wJENmxBHVTwvuyBnXwy7JnyN+fw+Z6hvpq5wNm5x1ktD56qrK8ygFxn
vmW9V3x85EOdXjHbZOczaa+yLB5UDBeZDtsI5ilYT4B5N5OZB7oHm3Pzl2kAwbBz
F9UmlFBATzhNtugSzdjYHm0YPIPDuzV/ChBdqIiE4AHAgQioReiLKtpK+gSvqSQj
2CCMWJ/6pJE=
=Tx1B
-----END PGP SIGNATURE-----



More information about the Gnupg-devel mailing list