I think it's very valuable for people who might not already now this to see an example of why it's true, as the post does:
> "What’s happening here is simple: The web application has the ability to decrypt different records encrypted with different keys. If you pass records that were encrypted for Alice to the application to decrypt it for Bob, and you’re not authenticating your access patterns, Bob can read Alice’s data by performing this attack."
An interesting question here is whether or not there's a god key that allows the administrator to decrypt all the data even if they can't authenticate as the user (or if they just have copies of all keys). Searching HN for 'lavabits' turns up some results related to this, e.g.
In a way when people talk about encryption what they really mean is authorization to access data.
The actual facts of whether or not data are encrypted using some whiz bang algorithm are irrelevant as long as some intermediary is ensuring that the data are only accessible by the intended clients.
Sometimes I wonder if all the focus on encryption is actually wasting cycles that could be spent instead making sure the authorization model is bulletproof.
For instance if a DBMS could ensure that only client A can access client A's data then does it matter if the data are stored encrypted in the DB?
You might say, well if they aren't encrypted then anyone with root can just read the data directly but it may be the case that anyone with root will be able to access the data regardless of whether it's encrypted because they can just pull it from the memory space of the DB engine.
There are a lot of considerations but it does seem like people get caught up in the "how" of encryption because of all the fancy maths and cool sounding algorithms rather than focusing on the "what" they're actually trying to accomplish which is usually "prevent clients from accessing data they shouldn't be able to access".
