Re: Encrypted Fields

From: Michael Gentry (mgentr..asslight.net)
Date: Fri Feb 06 2009 - 10:43:27 EST

  • Next message: Ramachandran Rajashri: "RE: Encrypted Fields"

    I don't think I have an easy way to share it (except via e-mail) until I get
    home. If you'd like, I could e-mail, but it might be good to make it
    available to all.

    On Fri, Feb 6, 2009 at 9:46 AM, Ramachandran Rajashri <
    rramachandra..axton.com> wrote:

    > Hi Michael,
    > I would be very interested in reading you paper. How do I get access to
    > it?
    >
    > Thanks
    > Raji
    >
    > -----Original Message-----
    > From: Michael Gentry [mailto:mgentr..asslight.net]
    > Sent: Friday, February 06, 2009 9:36 AM
    > To: use..ayenne.apache.org
    > Subject: Re: Encrypted Fields
    >
    > Joe, something I've explored doing (wrote a little paper on it, but
    > never
    > implemented it) was to have a pair of values for sensitive fields. One
    > is
    > the encrypted value (socialSecurityNumber) and the other is a version
    > (socialSecurityNumberVersion). The version field maps to different keys
    > used to encrypt the main field. This allows for the keys to be changed
    > (due
    > to an employee leaving or perhaps you have a 3 month mandate for key
    > changes) while still allowing you to read the old values. The key file
    > should be kept on the disk and protected by Unix file permissions so
    > others
    > can't read it easily.
    > I'm not sure if I made sense, but I've you'd like, I can dig up my
    > little
    > paper to send you (it might be more helpful). Just tell me the formats
    > you
    > can read (right now it is a Google Doc).
    >
    > mrg
    >
    >
    > On Thu, Feb 5, 2009 at 11:01 PM, Joe Baldwin
    > <jfbaldwi..arthlink.net>wrote:
    >
    > > These are all good points. I can do it either way as far as the
    > business
    > > rules go. I was just looking for some suggestions as to best
    > practices.
    > > The downside to using the database-managed encryption, is that it
    > makes the
    > > Cayenne code pretty messy (unless of course that I have missed some
    > > Utility/Convenience method that deals with applying MySQL functions to
    > > fetched data).
    > >
    > > I can brute-force this, as I mentioned earlier, by making the
    > conversions
    > > via Cayenne select queries and the #result directives pattern. My
    > > implementation turned out to be kind of messy and so I was thinking
    > there
    > > has to be a better way.
    > >
    >
    >
    >
    >
    >
    > This message may contain information that is confidential or privileged.
    > If you are not the intended recipient, please advise the sender immediately
    > and delete this message.
    >



    This archive was generated by hypermail 2.0.0 : Fri Feb 06 2009 - 10:43:59 EST