Hi Michael,
I am just wondering if we are able to have a global matrix for OpenVPN and IPsec or if we need to split that up? I would suggest to have two different matrices for that.
Think so too. OpenVPN offers more but also different ciphers to IPSec (SEED, BF, different 3DES, RC2), but also different HMAC algorithms. I think an interesting point in here is IPSec (especially Net-to-Net) with his different settings and the compatibility to other non IPFire systems which is mostly more complex and difficult to overview than OpenVPN.
For the OpenVPN server on IPFire for example the ciphers and digests (selection in the WUI is in development) are globally defined and a fallback to older ciphers/digests isn´t possible at this time. If a wide range of different client OS´s are used now, the question on the lowest common denominator possibly comes up. So a compatibility list can help to make a good decision. We have started with a little list --> http://wiki.ipfire.org/en/configuration/services/openvpn/extensions/zertkonv... which should only help temporarily for testing purposes and should only serve an idea/example to this.
I would also like to suggest to make two matrices. One for the ciphers, one for the hashing algorithms. That makes it a bit easier because the table doesn't get too huge.
In here are also differences between OpenVPN and IPSec so probably there is the need to do so.
Another point might be a timeline for the generation of the root/host certificates. We work currently on a flip menu in OpenVPN WUI where different bit sizes of the Diffie-Hellman key can be selected (1024, 2048, 3072 and 4096). The generation time for 4096 bit on a ALIX platform needed for example ~ 13 hours, 1024 bit instead 1.5 minutes, people might think something is broken while generating a new PKI so a hint for generation can help to understand such process better ?
With beta 1, generating keys on ALIX boards should be done within a second because the RNG is used for that. Benchmarking the times is nothing different than a measurement for how much entropy is generated by the system, so I think that there is not too much use for this. You will have to wait the time it takes to generate the key. If it takes way too long, than you should search for a source of entropy.
rngd doesn´t start on my systems
[root@ipfire]# /etc/init.d/rngd start No Hardware Random Number Generator found... [ WARN ]
but i used instead haveged which also brings more bits to entropy_available, but it makes the generation time not much faster. The DH key needs in any case (with or without more entropy_available) much longer.
But this shouldn´t be the problem, a hint over the WUI can serves also this informations.
We have still lots of other places to work on, so I would like to keep this as short as possible and cut everything that is not essentially required.
Sure.
This points does not targeting how strong or week or useful a cipher/hash or a key is now, but this can give also some technical background info´s.
Are you planning to point to sources? That is fine. But please do not copy or re-write texts about how AES works internally.
There is a lot of good documentation out there how ciphers works internally, in fact also Wikipedia delivers good informations. So i don´t think that we need deep specifics related to this topic. But to point out some non commercial platforms which provides more informations or some good RSS feeds for actual security infos might be possibly a good idea.
But anyway some questions comes up for me, - What other infos beneath a compatibility tables and some red flags causing broken or old-fashioned ciphers and hash algorithms which makes sense ? - Should we consider also other services like SSH, ... ?
Greetings
Erik