Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Received-SPF: pass (athena.apache.org: domain of elecharny@gmail.com
 designates 72.14.220.158 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=gG2FygV2/gS4ZynqnQ+ZGFQyjoRpkDw6K1cIxCT/GXO9u28au6noy9a3tztN66lDhiw2T0eaKnH6cku1Zd0u5uW7axGK2O+sn9tZm1Hl+1sy7gXABJdUqoTn3n11WPpKW7Nx2tzXKiR9K36CP0eLeRWhGpTaCiPJx1Lhc2fXzqQ=
Message-ID: <478D3C56.60408@gmail.com>
Date: Wed, 16 Jan 2008 00:05:58 +0100
From: Emmanuel Lecharny <elecharny@gmail.com>
User-Agent: Thunderbird 1.5.0.14pre (X11/20071023)
MIME-Version: 1.0
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: Re: Entry serialization
References: <478B92D6.1040300@gmail.com>
 <478B9778.7070905@levigo.de>	 <478B9A43.3090907@gmail.com>
 <478B9BB9.3020103@levigo.de>
 <a32f6b020801151415n2176ad4m4340567ecb6217db@mail.gmail.com>
In-Reply-To: <a32f6b020801151415n2176ad4m4340567ecb6217db@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

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