directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <>
Subject Re: Entry serialization
Date Tue, 15 Jan 2008 22:15:16 GMT
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?


On Jan 14, 2008 12:28 PM, Jörg Henne <> 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

View raw message