From mboxrd@z Thu Jan 1 00:00:00 1970 From: ummeegge To: documentation@lists.ipfire.org Subject: Re: Cryptography Date: Sun, 09 Feb 2014 21:59:10 +0100 Message-ID: <4D558235-E7BE-41CE-973B-3560C67117FF@ipfire.org> In-Reply-To: <1391870272.21794.154.camel@rice-oxley.tremer.info> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1851631430032035855==" List-Id: --===============1851631430032035855== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Michael, >=20 > 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.=20 I think an interesting point in here is IPSec (especially Net-to-Net) with hi= s different settings and the compatibility to other non IPFire systems which = is mostly more complex and difficult to overview than OpenVPN. >=20 >> For the OpenVPN server on IPFire for example the ciphers and digests (sele= ction in the WUI is in development) are globally defined and a fallback to ol= der ciphers/digests isn=C2=B4t possible at this time. If a wide range of diff= erent client OS=C2=B4s are used now, the question on the lowest common denomi= nator possibly comes up. So a compatibility list can help to make a good deci= sion. >> We have started with a little list --> http://wiki.ipfire.org/en/configura= tion/services/openvpn/extensions/zertkonvert#openvpns_cipher_and_digests_test= s_with_openssl_version_101f which should only help temporarily for testing pu= rposes and should only serve an idea/example to this. >=20 > 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 t= he need to do so. >=20 >> Another point might be a timeline for the generation of the root/host cert= ificates. 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 su= ch process better ? >=20 > 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=C2=B4t start on my systems [root(a)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 cas= e (with or without more entropy_available) much longer.=20 But this shouldn=C2=B4t be the problem, a hint over the WUI can serves also t= his informations. >=20 > 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. >=20 >>=20 >> 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=C2=B4s. >=20 > 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=C2=B4t think that= we need deep specifics related to this topic. But to point out some non commercial platforms which provides more informatio= ns or some good RSS feeds for actual security infos might be possibly a good = idea. But anyway some questions comes up for me,=20 - 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 --===============1851631430032035855==--