Hello list,
since Snowden, there is a lot going on about cryptography as he said that nothing else will help against mass surveillance than strong cryptography.
IPFire provides a lot of services that use (strong) cryptography like the VPN services OpenVPN and strongswan and some others like tor.
We can do a lot so that users are able to use these services in the most secure manner, but I think with that comes is still some education about the DOs and DON'Ts needed.
So I was thinking that it would be nice to create a section on our wiki about cryptography and to aggregate all information that is important to know at one spot. We can refer to the content from the OpenVPN and IPsec pages for example to suggest which cipher is best to use.
I created some pages about hardware random number generators and hardware crypto processors that are commonly used and supported by IPFire. Additionally to that, I can image to add things like these:
* Briefly(!) explain the algorithms there are and point out advantages and disadvantages. Of course can never give advice to use exactly this algorithm, but we can say which are considered unsafe to use.
* Provide best practices to protect keys, etc. Explain what attacks are possible so that people can prepare for them.
I don't want to this to be a huge part of the documentation and this is probably documented somewhere else very well, but I would like to have the basics in our wiki. Detailed explanations should be referenced and not copied.
This is all to see over here: http://wiki.ipfire.org/en/cryptography/start
Of course I would like to hear your opinions (if there is anybody out there)!
-Michael
On 02/06/2014 8:52 AM, Michael Tremer wrote:
<snip>
- Briefly(!) explain the algorithms there are and point out advantages
and disadvantages. Of course can never give advice to use exactly this algorithm, but we can say which are considered unsafe to use.
<snip>
Michael,
This isn't documentation-related, but is relevant tot he subject you brought up. Perhaps it would be worthwhile to change the user interface to add an element that requires a user to "Enable insecure encryption methods" before using protocols that are considered weak?
That way a user could still use those methods if required for interoperability, but it would be clear that it is not recommended for security reasons.
Tom
Hey Tom,
On Thu, 2014-02-06 at 09:15 -0500, Tom Rymes wrote:
On 02/06/2014 8:52 AM, Michael Tremer wrote: This isn't documentation-related, but is relevant tot he subject you brought up. Perhaps it would be worthwhile to change the user interface to add an element that requires a user to "Enable insecure encryption methods" before using protocols that are considered weak?
We have already plans to do this in a slightly different way. In the dropdown menus, the algorithms are usually sorted from strong to weak. For those we consider so weak that they should not be used, we planned to add a "(not recommended)" after the name of the algorithm.
That way a user could still use those methods if required for interoperability, but it would be clear that it is not recommended for security reasons.
Interoperability is the thing that gives us a real headache here. If I could I would just remove everything that is proven to be broken.
However, there are algorithms that are not proven to be broken but there are conspiracies that the authorities that specified them may have weakened the algorithm deliberately or added a backdoor. If we take this into account, it is getting even harder to find a good default.
I think your point is to change the user interface that you won't pick the weakest cipher randomly and that you don't need to read the documentation to make a better choice. I totally agree with that.
That is also the reason why I want to keep it all short and sweet, because I don't expect too many people reading this prior to setup of the VPNs, but I think that the information must be there.
-Michael
Hi all, another idea for a potential info pool in that term could be a compatibility list for the different ciphers and digests and the different OS´s (especially the OpenSSL-1.0.1f library, which comes with IPFire-2.15, brought some new ones) . For example the CAMELLIA or SEED cipher aren´t compatible with mostly smartphones and also some older OS´s like OS X 10.6 (which is still widely used) or Windows 7 and below. But also the Whirlpool or SHA384/512 hash algorithms are interesting to check against common but also older operating systems, to name a few.
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.
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 ?
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.
--------------
A reference to different organizations with crypto background can also be an interesting point in that kind of wiki.
For example: - http://www.iacr.org/ - https://www.cosic.esat.kuleuven.be/nessie/ - http://www.ecrypt.eu.org/ - http://www.ecrypt.eu.org/stream/ - http://www.nist.org/news.php - https://www.teletrust.de/ - https://www.bsi.bund.de/EN/Publications/publications_node.html
Possibly some special section are more interesting then others, but as a first idea ???
Greetings
Erik
Hi,
On Fri, 2014-02-07 at 11:58 +0100, ummeegge wrote:
Hi all, another idea for a potential info pool in that term could be a compatibility list for the different ciphers and digests and the different OS´s (especially the OpenSSL-1.0.1f library, which comes with IPFire-2.15, brought some new ones) . For example the CAMELLIA or SEED cipher aren´t compatible with mostly smartphones and also some older OS´s like OS X 10.6 (which is still widely used) or Windows 7 and below. But also the Whirlpool or SHA384/512 hash algorithms are interesting to check against common but also older operating systems, to name a few.
This is indeed a very good idea and of course influences the decision a lot.
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.
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.
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.
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.
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.
A reference to different organizations with crypto background can also be an interesting point in that kind of wiki.
For example:
- http://www.iacr.org/
- https://www.cosic.esat.kuleuven.be/nessie/
- http://www.ecrypt.eu.org/
- http://www.ecrypt.eu.org/stream/
- http://www.nist.org/news.php
- https://www.teletrust.de/
- https://www.bsi.bund.de/EN/Publications/publications_node.html
Possibly some special section are more interesting then others, but as a first idea ???
Greetings
Erik
Documentation mailing list Documentation@lists.ipfire.org http://lists.ipfire.org/mailman/listinfo/documentation Return-Path: documentation-bounces@lists.ipfire.org Received: from mail01.ipfire.org by hedwig.ipfire.org (Dovecot) with LMTP id 56ilKlq89FIJbwAAjPkmHg ; Fri, 07 Feb 2014 11:58:34 +0100 Received: from hedwig.ipfire.org (localhost [IPv6:::1]) by mail01.ipfire.org (Postfix) with ESMTP id A1C9F2101; Fri, 7 Feb 2014 11:58:34 +0100 (CET) Received: from [192.168.75.2] (dslb-084-057-122-162.pools.arcor-ip.net [84.57.122.162]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail01.ipfire.org (Postfix) with ESMTPSA id 05101180 for documentation@lists.ipfire.org; Fri, 7 Feb 2014 11:58:32 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1085) Subject: Re: Cryptography From: ummeegge ummeegge@ipfire.org In-Reply-To: 1391696720.21794.100.camel@rice-oxley.tremer.info Date: Fri, 7 Feb 2014 11:58:26 +0100 Message-Id: 588CE637-2C6C-4F5B-9208-811574F2E5D8@ipfire.org References: 1391694769.21794.92.camel@rice-oxley.tremer.info 52F398ED.2080901@rymes.com 1391696720.21794.100.camel@rice-oxley.tremer.info To: documentation@lists.ipfire.org X-Mailer: Apple Mail (2.1085) X-BeenThere: documentation@lists.ipfire.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussions about the wiki, translations and stuff..." <documentation.lists.ipfire.org> List-Unsubscribe: http://lists.ipfire.org/mailman/options/documentation, mailto:documentation-request@lists.ipfire.org?subject=unsubscribe List-Archive: http://lists.ipfire.org/pipermail/documentation/ List-Post: mailto:documentation@lists.ipfire.org List-Help: mailto:documentation-request@lists.ipfire.org?subject=help List-Subscribe: http://lists.ipfire.org/mailman/listinfo/documentation, mailto:documentation-request@lists.ipfire.org?subject=subscribe Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Errors-To: documentation-bounces@lists.ipfire.org Sender: "Documentation" documentation-bounces@lists.ipfire.org
Hi all, another idea for a potential info pool in that term could be a compatibility list for the different ciphers and digests and the different OS´s (especially the OpenSSL-1.0.1f library, which comes with IPFire-2.15, brought some new ones) . For example the CAMELLIA or SEED cipher aren´t compatible with mostly smartphones and also some older OS´s like OS X 10.6 (which is still widely used) or Windows 7 and below. But also the Whirlpool or SHA384/512 hash algorithms are interesting to check against common but also older operating systems, to name a few.
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.
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 ?
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.
A reference to different organizations with crypto background can also be an interesting point in that kind of wiki.
For example:
- http://www.iacr.org/
- https://www.cosic.esat.kuleuven.be/nessie/
- http://www.ecrypt.eu.org/
- http://www.ecrypt.eu.org/stream/
- http://www.nist.org/news.php
- https://www.teletrust.de/
- https://www.bsi.bund.de/EN/Publications/publications_node.html
Possibly some special section are more interesting then others, but as a first idea ???
Greetings
Erik
Documentation mailing list Documentation@lists.ipfire.org http://lists.ipfire.org/mailman/listinfo/documentation
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
Hi,
statement of Tom is good, just that there are examples for this?
That way a user could still use those methods if required for interoperability
I think, a general overview is good. It can be transferred easily with respect to the fire.
5p9
Am 06.02.2014 15:15, schrieb Tom Rymes:
This isn't documentation-related, but is relevant tot he subject you brought up. Perhaps it would be worthwhile to change the user interface to add an element that requires a user to "Enable insecure encryption methods" before using protocols that are considered weak?
That way a user could still use those methods if required for interoperability, but it would be clear that it is not recommended for security reasons.
documentation@lists.ipfire.org
-
5p9 -
Michael Tremer -
Tom Rymes -
ummeegge