directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject Re: Entry serialization
Date Mon, 14 Jan 2008 17:22:11 GMT
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.

cordialement, regards,
Emmanuel Lécharny

View raw message