[Freedombox-discuss] CAs and cipher suites for cautious

[Mark Richards]

Hi,

Perhaps old, but worth reading
http://csrc.nist.gov/publications/nistpubs/800-131A/sp800-131A.pdf
http://csrc.nist.gov/publications/fips/fips140-2/fips1402annexa.pdf this is
dated well before Snowden and bans bit lengths and algorithms commonly
still used in https... Notable are RSA bit lengths, sha-1 to be banned.
This isn't new, but it seems the federal guidance of things to ban might be
worth using as a baseline.

I hope you've got an encryption specialist in the team... I'm no expert,
just caught recent press and over the last 12 months there have been quite
a few risks highlighted in https, most require some form of network access
and persuasion means (you need the users computer to do something)... But
one claimed it could break compressed https tunnel in 30 seconds if it
could persuade the user's machine to send data down the tunnel so would
likely need an xss hack.

It seems RC4 might be worth dropping, but AES seems okay?

As a secure tunnel method, best to ban SSL 3 and TLS except 1.2. Also the
hashing algorithm is very important (no md5, or perhaps sha-1).

Other attacks this year have included vulnerabilities in random functions
(android's SecureRandom) which apparently lost a few people some bitcoins
oh and remember the old php pseudo random one a few years ago, a colleague
pointed this one out in a good YouTube video from defcon 2010
http://m.youtube.com/watch?v=gP8Vs5boIDk&desktop_uri=%2Fwatch%3Fv%3DgP8Vs5boIDk.
Sorry if the video seems a little sexist...

There is an interesting discussion ongoing about Linux's /udev/random... It
might have a dependency on the CPU not having a malicious hardware hack...
Although the CPU could guess the instructions are from /dev/urandom and do
an xor to remove precalculated randomness might be a stab in the dark...

Regarding WEP and WPA, these are both pretty broken in many
implementations, even the enterprise ones... There might be a secure VPN
tunnel you could layer on top...

I'm not sure how you propose to manage encryption, if there are various
applications for different purposes (messenging, data store, email) then
having to manage the encryption levels in each might be painful for a
user.. If settings are centralised it could be easy to remove rc4 or only
allow sha1 for hash tables and not checksum purposes.

Lastly, there are a few algorithms showing promise for being safe against
quantum computers, so in case these pesky things leave Google's hands and
end up on best buy shelves in a few years, you could check them out! Only
issue is that they might not have had as much scrutiny as say AES or RSA.

Good luck
Mark
:-)

> Date: Sat, 14 Sep 2013 13:44:01 -0400
> From: Sandy Harris <sandyinchina at gmail.com>
> To: freedombox list <freedombox-discuss at lists.alioth.debian.org>
> Subject: Re: [Freedombox-discuss] CAs and cipher suites for cautious
>         servers like FreedomBox
> Message-ID:
>         <
CACXcFmkRi+bNgjFftB8GweecZx_D+p6b3c9RvkCUkrVapFDvSw at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Fri, Sep 13, 2013 at 8:18 PM,  <cgw993 at aol.com> wrote:
>
> > Again, not an expert in this subject at all, but since we are talking
about
> > security I wanted to bring up WEP.   My limited understanding of WEP is
that
> > it was an insecure encryption method used a decade or more ago and is
still
> > offered on many routers.
>
> WEP is on a list of broken things we should obviously make sure the Box
> never does. One reference is:
> http://www.isaac.cs.berkeley.edu/isaac/wep-faq.html
> That is outdated; newer and even better attacks on WEP have been
> published since it was written,
>
> Other known-broken things we should not do include single DES and
> several of the cell phone encryption methods like A5/! and A5/2.
>
> Another is RSA with short keys. I think the current recommended minimum
> for RSA is 2048 bits, but I may be out of date. Certainly < 1024 is
unsafe,
> and some systems still use 512.
>
> A similar issue shows up for the Diffie-Hellman groups used in key
> negotiation for IPsec and I think TLS.
> http://en.citizendium.org/wiki/Diffie-Hellman
> Fifteen years ago, the FreeS/WAN team refused to implement the
> 768-bit Group 1, even though it was in the IPsec standard. Most
> installations used the 1536-bit Group 5. I'm not sure what would
> be appropriate today.
>
> For both RSA and DH, there are related elliptic curve algorithms
> which may be better (faster for a given security level). Evaluating
> those gets complicated though. For one thing, the math involved
> is remarkably heavy. Also, some of the algorithms are patented
> and the patent holder is aggressive about enforcement. Finally,
> there have been claims that the curves used in some of the
> standards give the NSA a back door. As far as I can tell, the
> last two concerns can be worked around; there are unpatented
> algorithms and curves the NSA had no hand in devising, but
> it is not going to be easy.
>
> Arguably, using IPsec or TLS without forward secrecy is another thing
> we should never do.
>
https://www.eff.org/deeplinks/2013/08/pushing-perfect-forward-secrecy-important-web-privacy-protection
>
> The replacement for WEP is WPA.
> http://en.wikipedia.org/wiki/Wi-Fi_Protected_Access
>
> There are also some known problems with it. I think they are
> only for certain modes and WPA can be secure if used very
> carefully, but I have not looked at it in any detail so I could
> easily be wrong.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/freedombox-discuss/attachments/20130915/f1bd2a00/attachment.html>