I recently noticed that several packages in Fedora create RSA keys with
inappropriate key sizes:
dnssec-trigger creates RSA 1536 keys with certificate that is valid for
dropbear-keygen creates by default RSA 1024 keys:
Some other observations:
ssh-keygen on F19 creates RSA 2048 keys by default
ENISA recommends to at least RSA 3072 keys:
If e.g. AES-256 is used. RSA 15360 is recommended for long-term usage.
Therefore I would like to propose a packaging guideline about which
minimum key size software in Fedora should generate by default. It seems
to me that requiring RSA 3072 key by default in Fedora is a good initial
compromise. I did not notice RSA keys with more than 4096 bits
regularly, therefore I am not sure whether using RSA 15360 keys by
default is a good idea.
What is your opinion?
Hello to the list,
i would like to contribute to the security response team.
If any help is needed or any ideas ongoing please point to an good
My name is Jörg Stephan, i am an 34 years old system administrator from germany. I basically work on maintaining some hundreds of debian/ubuntu based servers and a handful of centos machines. Besides my administrator work i am also responsible for IT security questions.
-----BEGIN PGP SIGNED MESSAGE-----
it was topic during the last infrastructure meeting that the CSI
Security Policy may is a bit outdated.
i would like to review, expand and update it.
If nobody else is currently working on it, I will start to go through
the text and and commit changes and updates.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
-----END PGP SIGNATURE-----
[reposting from fedora-devel]
I am working on a draft common crypto policy for Fedora. The idea is to
be able to set a security level for all TLS/SSL connections in a system
(which will of course allow the user to use any application-specific
The draft change is at:
and is not submitted yet as I'd appreciate any comments, suggestions for
improvement or any help in implementing it. The current policy is
restricted to TLS and SSL libraries to have a manageable work effort but
the idea is to convert gradually all crypto applications and libraries.