Just including Jorg so he knows what's up. Alex
On Jan 15, 2008 6:05 PM, Emmanuel Lecharny <[EMAIL PROTECTED]> 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 <[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 > > >
