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.154 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=PYGfnximRTW9VReuWxjyTY5occicfxBC+XRaExcrlVNauI5a1cT3CR6n2oufEOARCJyaXyM4OJpd5PfuUMWjwT2jEzM+UroFcXw0ycwcPAwoc9PVBQ4Pb37zjNp1/D15Q3zSwsBFrfGQMBsb4FxvCFIXFsEPEnK3zPeO5dPP1cc=
Message-ID: <478B9A43.3090907@gmail.com>
Date: Mon, 14 Jan 2008 18:22:11 +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>
In-Reply-To: <478B9778.7070905@levigo.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

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
www.iktek.com
directory.apache.org