directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg Henne <>
Subject Re: Entry serialization
Date Mon, 14 Jan 2008 17:28:25 GMT
Emmanuel Lecharny schrieb:
> Jörg Henne wrote:
>> Emmanuel Lecharny wrote:
>>> as I need to rewrite the serialization for ServerEntry, 
>>> ServerAttribute, ServerValue, DN, RDN and AttributeTypeAndValue, I 
>>> have had some ideas, and I would like to know your opinion :
>>> - what about adding a flag to tell the serialization methods (those 
>>> classes are Externalizable) to encrypt/decrypt the data on disk ? 
>>> Tis would be a much better solution than to define an encryption 
>>> option to be added to all the attributes (like 
>>> "cn;encrypted=fR5*za"). All the data will be encrypted before being 
>>> serialized to disk. It would be off by default, of course
>> To make the encryption cryptographically sound, the message to be 
>> encrypted must be sufficiently random. In a scheme where each entry 
>> is encrypted individually, this requires an initialization vector 
>> (i.e. some random bits) which amounts to relatively high percentage 
>> of wasted space. A scheme where the encryption happens in larger 
>> chunks (e.g. B-Tree nodes or pages) will typically have better 
>> "randomness" in the first place and reduce the space wasted by the iv.
>> I don't know how the storage engine works at the bottom end, but I'd 
>> guess that this would be a better place to do encryption.
> The idea is not to build a 100% secure system. There are better ways 
> to do that (for instance, relying on an encrypted file system on 
> linux, etc).
> The thing is that with an encryption on entries, during the 
> serialization, we will be able to keep an encrypted version of an 
> entry on disk AND in memory, as we store the read entry in a cache.
> Let's say it's a step in the right direction for people who want some 
> better security when it comes to store personal data, which is likely 
> with a LDAP server.
Right, as long as the goal is just to hide things from casual 
"observers" and to fend off low-tech attackers with hex-editors, there's 
nothing wrong with your approach.

Joerg Henne

View raw message