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 <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> 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
