public inbox for documentation@lists.ipfire.org
 help / color / mirror / Atom feed
From: Michael Tremer <michael.tremer@ipfire.org>
To: documentation@lists.ipfire.org
Subject: Re: Cryptography
Date: Thu, 06 Feb 2014 15:25:20 +0100	[thread overview]
Message-ID: <1391696720.21794.100.camel@rice-oxley.tremer.info> (raw)
In-Reply-To: <52F398ED.2080901@rymes.com>

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


  reply	other threads:[~2014-02-06 14:25 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-06 13:52 Cryptography Michael Tremer
2014-02-06 14:15 ` Cryptography Tom Rymes
2014-02-06 14:25   ` Michael Tremer [this message]
2014-02-07 10:58     ` Cryptography ummeegge
2014-02-08 14:37       ` Cryptography Michael Tremer
2014-02-09 20:59         ` Cryptography ummeegge
2014-02-06 14:25   ` Cryptography 5p9

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1391696720.21794.100.camel@rice-oxley.tremer.info \
    --to=michael.tremer@ipfire.org \
    --cc=documentation@lists.ipfire.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox