Trying to get back on this.  I got no response from the incubator PMC on the email I sent regarding their advice on this situation.  Perhaps Emmanuel you can reping and ask if anyone can advise what to do here?

Alex

On Jan 14, 2008 12:28 PM, Jörg Henne <j.henne@levigo.de> wrote:
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