Cryptography

Cryptography

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 1670 bytes --]

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

Re: Cryptography

[Tom Rymes]

[-- Attachment #1: Type: text/plain, Size: 714 bytes --]

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

Re: Cryptography

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 1652 bytes --]

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

Re: Cryptography

[ummeegge]

[-- Attachment #1: Type: text/plain, Size: 2409 bytes --]

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/zertkonvert#openvpns_cipher_and_digests_tests_with_openssl_version_101f 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

Re: Cryptography

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 8666 bytes --]

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/zertkonvert#openvpns_cipher_and_digests_tests_with_openssl_version_101f 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(a)lists.ipfire.org
> http://lists.ipfire.org/mailman/listinfo/documentation
> Return-Path: <documentation-bounces(a)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(a)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(a)ipfire.org>
> In-Reply-To: <1391696720.21794.100.camel(a)rice-oxley.tremer.info>
> Date: Fri, 7 Feb 2014 11:58:26 +0100
> Message-Id: <588CE637-2C6C-4F5B-9208-811574F2E5D8(a)ipfire.org>
> References: <1391694769.21794.92.camel(a)rice-oxley.tremer.info>
>  <52F398ED.2080901(a)rymes.com>
>  <1391696720.21794.100.camel(a)rice-oxley.tremer.info>
> To: documentation(a)lists.ipfire.org
> X-Mailer: Apple Mail (2.1085)
> X-BeenThere: documentation(a)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(a)lists.ipfire.org?subject=unsubscribe>
> List-Archive: <http://lists.ipfire.org/pipermail/documentation/>
> List-Post: <mailto:documentation(a)lists.ipfire.org>
> List-Help: <mailto:documentation-request(a)lists.ipfire.org?subject=help>
> List-Subscribe: <http://lists.ipfire.org/mailman/listinfo/documentation>,
>  <mailto:documentation-request(a)lists.ipfire.org?subject=subscribe>
> Content-Type: text/plain; charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
> Errors-To: documentation-bounces(a)lists.ipfire.org
> Sender: "Documentation" <documentation-bounces(a)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/zertkonvert#openvpns_cipher_and_digests_tests_with_openssl_version_101f 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(a)lists.ipfire.org
> http://lists.ipfire.org/mailman/listinfo/documentation

Re: Cryptography

[ummeegge]

[-- Attachment #1: Type: text/plain, Size: 4088 bytes --]

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/zertkonvert#openvpns_cipher_and_digests_tests_with_openssl_version_101f 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(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 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

Re: Cryptography

[5p9]

[-- Attachment #1: Type: text/plain, Size: 730 bytes --]

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.