From mboxrd@z Thu Jan  1 00:00:00 1970
From: ummeegge <ummeegge@ipfire.org>
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: <documentation.lists.ipfire.org>

--===============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==--