directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <akaras...@apache.org>
Subject Re: Entry serialization
Date Tue, 15 Jan 2008 23:10:04 GMT
Just including Jorg so he knows what's up.

Alex

On Jan 15, 2008 6:05 PM, Emmanuel Lecharny <elecharny@gmail.com> wrote:

> Alex Karasulu wrote:
> > 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?
> Sure. Will do tomorrow.
> >
> > Alex
> >
> > On Jan 14, 2008 12:28 PM, Jörg Henne <j.henne@levigo.de
> > <mailto: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
> >
> >
> >
> >
>
>
> --
> --
> cordialement, regards,
> Emmanuel Lécharny
> www.iktek.com
> directory.apache.org
>
>
>

Mime
View raw message