Wandering Thoughts archives

2010-11-29

Why low quality encryption is not better than no encryption

Today, I was considering reconfiguring a program to stop supporting relatively less secure SSL connections and found myself thinking the old refrain of 'well, maybe there's some client that only works with the old stuff, isn't it better for them to have some encryption rather than no encryption?'

This is a superficially attractive thought, and it's certainly an easy refrain to fall into. It's also wrong.

From the semi-mathematical security perspective, it sounds good; having weak encryption defeats some attackers and makes some attacks just that little bit more difficult. But that's the wrong perspective, because security is not math, security is people and people are really bad at understanding degrees of security. When you say 'low quality encryption', they miss the 'low quality' and just see the 'encryption'.

(Well, sort of. It is not so much that they miss the low quality, it is that almost everyone lacks the knowledge to understand how low the low quality is and how vulnerable they are as a result. 'Encryption' is something that people understand, while 'low quality' is a meaningless buzzword.)

The end result is that in practice, your low quality encryption winds up creating an unwarranted feeling of security in both people and programs (because programs are written by people). In short, they put more trust in it than they should (ie any trust whatsoever). For the purposes of actual practical security, they would be better off with no encryption at all because then they would understand that they weren't protected (or at least have a realistic chance to).

The much shorter version of this is: if the connection is not really secure, you should not pretend that it is. Pretending just hurts people in the end.

Hopefully I will remember this logic the next time I go through this exercise and proceed to the bit where I actually turn off 'known to be insecure' stuff. (I didn't get to the actual configuration bit today; I just convinced myself that I should.)

tech/LowQualEncryptionBad written at 23:19:20; Add Comment

Why 10G Ethernet is not a near-term issue for us

In my entry on the lifetime of our fileserver infrastructure, I said that 10G Ethernet wasn't something that I expected to force hardware changes on us in the next three years. The reason for this is pretty simple: it is too expensive now.

Well, sort of. What is actually important is what happens because 10G Ethernet is so expensive, namely that it is vanishingly rare today. Rarity matters in several ways. First and most obviously, by default rarity means low or no demand for something; with no 10G shipping on machines that our users deploy, there is no demand for us to supply them with 10G connections, 10G switches, and so on. In fact there is basically no point in trying to support 10G connection speeds early even if we had the money, because we can get better and cheaper hardware by waiting until we actually need it.

Second, there is inevitably going to be a learning process with 10G, where software and configurations have to be tuned to get the speed and then take advantage of it. This learning process will not really get under way until 10G is relatively pervasive, not just here but in developer hardware, and that is not going to happen while 10G is expensive.

(The learning process matters because until it's complete, 10G hardware will be less attractive than it looks because you can't actually get all the nice performance that it theoretically offers.)

10G hardware will inevitably come down in price over time. However, both of these issues have relatively long lead times, which means that there is a (substantial) delay between when 10G hardware becomes cheap and when it starts driving demand for 10G infrastructure that can sensibly be met. Since 10G hardware is not cheap now and does not seem like it will be cheap in the near future, I feel safe in saying that 10G will not be a driver (or a risk) for hardware changes over the next three years.

(Note that this is a different issue than whether or not we would buy 10G hardware for fileservers that we were building from scratch. I certainly hope that in less than three years, 10G is cheap enough that we're putting it in new servers and switches. But that it's available as a nice feature isn't enough to force us into a significant hardware upgrade of our current fileservers.)

tech/10GEthernetDemand written at 00:41:43; Add Comment


Page tools: See As Normal.
Search:
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.