On 9/11/12 15:00 PM, Kevin W. Wall wrote:
I was only considering it because it seemed like it was the easiest way
to get from point A (plaintext SSNs) to point B (encrypted SSNs). Been
trying to get that done for almost 2 yrs. They've been putting it off because
of the supposed effort and using TDE should minimize their development
effort. The question is whether TDE leaves us with acceptable risk,
hence my attempt to better understand it.
my 20c
I think this one of those compliance traps that we frequently allow
ourselves to fall into. "We encrypt our data" means it is secure. The
more nuanced risk expression that "we took reasonable mitigation steps
to address the risk of data compromise" but what is reasonable?
The false premise here is that encryption will secure the data. That's
only true in the public mind. In reality, we discover that the data is
so difficult to deal with that simple encryption just obfuscates it.
E.g., the simple approach of ECB leads to salting which breaks indexing.
In effect, SQL tables are mostly incompatible with straight encryption.
However you explore this rabbit hole, you're still down deep inside it.
The better answer is more like an architectural approach that provides a
more holistic model. But this is too radical to contemplate, as it
might result in things like "SQL databases can't be secured..." which
impresses no-one, least all vendors who pay salaries.
So what to do? One thing is to keep in mind that encryption isn't the
answer, although it may be the compliance requirement. Another thing is
to keep firmly in mind that you're in a risk game - you are mitigating
things, not removing them. Whereas, Compliance means you tick boxes,
and this is followed whether you decrease risks or increase them.
Maybe a partial solution will pop out that does a little bit of
encryption, and a lot of separation, and a bit of governance... Or note
Morlock's post to use asymmetric crypto. This works, but it does have
surprising ramifications, such as making backups rather less scrutinisable.
iang
_______________________________________________
cryptography mailing list
[email protected]
http://lists.randombit.net/mailman/listinfo/cryptography
