cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Malcolm Edgar <malcolm.ed...@gmail.com>
Subject Re: cayenne-crypto
Date Tue, 08 Apr 2014 05:13:18 GMT
Hi Andrus,

Yes I think it would be useful, for storing data. The management of the
symetrical encryption keys, it the trickiest thing in this space and
reducing their exposure.

Its probably worthwhile having an option to GZIP compress the data before
you store it, for larger values (> 1K).

regards


On Tue, Apr 8, 2014 at 12:18 AM, Andrus Adamchik <andrus@objectstyle.org>wrote:

> Hi Malcolm,
>
> Cool. Yeah, that's what cayenne-crypto will use by default (AES/CBC).
>
> BTW, since you are already using cryptography on your projects, what's
> your opinion on the Cayenne crypto effort? Would that be useful in your
> situation? (not saying you should switch immediately, just your general
> assessment)
>
> Cheers,
> Andrus
>
>
> On Apr 7, 2014, at 5:09 PM, Malcolm Edgar <malcolm.edgar@gmail.com> wrote:
>
> > We use AES-256 CBC for data encryption, it an approved crypto algorithm
> for
> > Top Secret classification data, in US and Australia, and its still very
> > fast.
> >
> > The only issue with AES-256 is that you will need to ensure the JDK is
> > patched with the 'Java Cryptography Extension (JCE) Unlimited Strength
> > Jurisdiction Policy Files' to support it.
> >
> >
> http://www.oracle.com/technetwork/java/javase/downloads/jce-7-download-432124.html
> >
> > regards Malcolm Edgar
> >
> >
> > On Mon, Apr 7, 2014 at 6:42 PM, Andrus Adamchik <andrus@objectstyle.org
> >wrote:
> >
> >> I can't "name names", but I can answer in general terms. This is to
> >> protect sensitive business data. Not (yet) about any specific gov.
> >> compliance. This protects pieces of data against DBA's, QA and
> developers
> >> who have legitimate access to production DB and its backups. As well as
> >> hackers who may steal such a backup from someone's laptop.
> >>
> >> The app server will keep unencrypted data in memory, so hacking an
> >> appserver and taking a memory dump will leak some of the data. With
> default
> >> KeySource it will also reveal the key. A more secure version
> >> (certificate-based logins?) might keep user-specific keys in a session,
> >> reducing the attack time window. This improvement may also serve as an
> >> authorization tool - different users have different keys, so they can
> only
> >> decrypt the data they are authorized for.
> >>
> >>> Are you seeing the AES encryption performance to be symmetrical between
> >> select and insert?
> >>
> >> Meaning the speed of encryption vs. decryption? Will need to check. I
> only
> >> did a combined test now. But I suspect both will be of the same order.
> >>
> >> Andrus
> >>
> >>
> >>
> >> On Apr 7, 2014, at 11:14 AM, Aristedes Maniatis <ari@maniatis.org>
> wrote:
> >>> Out of curiosity, if you can discuss, what are you using this for? Is
> >> this some sort of PCI DSS compliance, or privacy or health? Do you get
> any
> >> real security (since all the objects must exist in plain text everywhere
> >> between Cayenne/html rendering engine/servlets/container/proxy until the
> >> SSL layer kicks in). Or is this to prevent the DBA from poking their
> nose
> >> where it should not be?
> >>>
> >>> Are you seeing the AES encryption performance to be symmetrical between
> >> select and insert?
> >>>
> >>>
> >>> Ari
> >>>
> >>>
> >>> On 7/04/2014 4:56pm, Andrus Adamchik wrote:
> >>>> Also some early performance data. In my tests with a local DB and a
> mix
> >> of select/insert operations using AES with 128-bit key wasn't noticeably
> >> slower than using no encryption at all. Using 256-bit key resulted in
> 10%
> >> overhead. While these are great results, take it with a grain of salt
> for
> >> now until we get more use cases and start using it in production.
> >>>>
> >>>> Andrus
> >>>>
> >>>>
> >>>> On Apr 4, 2014, at 3:21 PM, Andrus Adamchik <andrus@objectstyle.org>
> >> wrote:
> >>>>
> >>>>> So the crypto module is done and available on trunk. Here is a
> minimal
> >> configuration that will do AES/CBC encryption:
> >>>>>
> >>>>> 1. Create a keystore and generate a secret key in it:
> >>>>>
> >>>>> keytool -genseckey -keystore /tmp/ks1.jceks -storetype JCEKS -alias
> >> mykey
> >>>>>
> >>>>> 2. Start Cayenne with crypto:
> >>>>>
> >>>>> // this can also be a URL or a String representing URL
> >>>>> File keyStore = new File("/tmp/ks1.jceks");
> >>>>>
> >>>>> // obtain this somehow
> >>>>> char[] keyPassword = ..
> >>>>>
> >>>>> // "mykey" is the key alias in #1
> >>>>> Module crypto = new CryptoModuleBuilder().keyStore(keyStore,
> >> keyPassword, "mykey").build();
> >>>>>
> >>>>> // this will enable encryption/decryption for all columns matching
> >> ^CRYPTO_ regex
> >>>>> // those must be either character or binary columns
> >>>>> ServerRuntime  runtime = new ServerRuntime("cayenne-myproject.xml",
> >> crypto);
> >>>>>
> >>>>>
> >>>>> So just 3 lines of code give you the encryption. Of course it is
> fully
> >> customizable. See 'CryptoModuleBuilder' for what can be extended. Also
> the
> >> code is pretty raw, so it may break or may be refactored as we find
> bugs. I
> >> still need to study the performance and tweak as needed. Also there are
> >> certain strategies are not yet available. E.g. we only support block
> >> ciphers in CBC mode (as this is what I am planning to use in my apps).
> We
> >> will add support for ECB and also streaming ciphers eventually.
> >>>>>
> >>>>> But ... everyone is free to give it a try ;)
> >>>>>
> >>>>> Andrus
> >>>>>
> >>>>>
> >>>>
> >>>
> >>> --
> >>> -------------------------->
> >>> Aristedes Maniatis
> >>> GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A
> >>>
> >>
> >>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message