Subject | Re: [firebird-support] Re: Encryption |
---|---|
Author | Geoff Worboys |
Post date | 2009-06-17T22:30:14Z |
Hi Mauro,
Maverick Thunder wrote:
We do not need to argue the merits of key management for UDF
encryption... because you have still not solved the original
point of my response to the UDF suggestion: patterns.
Take a look at this as an example:
http://www.truecrypt.org/docs/?s=how-to-back-up-securely
with the repeated warnings not to let a potential attacker get
copies of the encrypted volume over successive periods in time.
These warnings are given because it is possible to analyse the
changes and get hints towards the encryption key.
Now multiply that by the number of rows in which you are going
to store encrypted fields... then add in the old version row
data that have not yet been cleaned up.
Then weaken the encryption scheme according to the large number
of hints available in the surrounding plain-text data. Perhaps
it is known the encrypted data is text, perhaps the surrounding
data makes it possible to make good guesses at the actual
contents of just one or two of the fields (with the UDF
restrictions on encryption this is effectively the same as
handing the attacker the key).
But wait, there's more:
You are wanting to encrypt because you believe an attacker may
be able to read the source/original field data. (If they never
see it you would not need to encrypt it.) If the attacker is
an authorised user it may well be that they can prime the field
with known data... they read back the encrypted result and once
again you have handed them the key.
If all you want to do is stop your little brother from reading
your diary then some simple obscuring of data may be all you
need (beware of under-estimating the younger generations ;-).
I would much rather we did not attempt to pretend it was real
security.
Sure there are many commercial enterprises out there selling
products with "strong encryption" features worth almost as much
as the paper it was printed on, but Firebird does not have to
follow their example.
--
Geoff Worboys
Telesis Computing
Maverick Thunder wrote:
>> > You can write an UDF that makes the encryption/decryption...
>> > of the data.
>> The sort of "encryption" offered by UDF could soon be broken...
>> by the patterns produced over many rows of data...
> If the database is on a remote scerver, public and private...
> RSA/3DES/AES keys can be stored
We do not need to argue the merits of key management for UDF
encryption... because you have still not solved the original
point of my response to the UDF suggestion: patterns.
Take a look at this as an example:
http://www.truecrypt.org/docs/?s=how-to-back-up-securely
with the repeated warnings not to let a potential attacker get
copies of the encrypted volume over successive periods in time.
These warnings are given because it is possible to analyse the
changes and get hints towards the encryption key.
Now multiply that by the number of rows in which you are going
to store encrypted fields... then add in the old version row
data that have not yet been cleaned up.
Then weaken the encryption scheme according to the large number
of hints available in the surrounding plain-text data. Perhaps
it is known the encrypted data is text, perhaps the surrounding
data makes it possible to make good guesses at the actual
contents of just one or two of the fields (with the UDF
restrictions on encryption this is effectively the same as
handing the attacker the key).
But wait, there's more:
You are wanting to encrypt because you believe an attacker may
be able to read the source/original field data. (If they never
see it you would not need to encrypt it.) If the attacker is
an authorised user it may well be that they can prime the field
with known data... they read back the encrypted result and once
again you have handed them the key.
If all you want to do is stop your little brother from reading
your diary then some simple obscuring of data may be all you
need (beware of under-estimating the younger generations ;-).
I would much rather we did not attempt to pretend it was real
security.
Sure there are many commercial enterprises out there selling
products with "strong encryption" features worth almost as much
as the paper it was printed on, but Firebird does not have to
follow their example.
--
Geoff Worboys
Telesis Computing