Mailing-List: contact dev-help@cayenne.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cayenne.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
Subject: Re: cayenne-crypto
From: Andrus Adamchik <andrus@objectstyle.org>
In-Reply-To: 
 <CAN-d2bDMqCp+skfMQ187s3DTqbKDe7iG4Z=HRuHvOMMsLyv-sw@mail.gmail.com>
Date: Mon, 7 Apr 2014 17:18:28 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <F10D5F82-B4A2-4ADC-A939-36F4754C9C05@objectstyle.org>
References: <371C206B-90E3-40E1-AC1D-B9401A18F14F@objectstyle.org>
 <8341D757-D397-41C0-B27C-89563BFF7E90@objectstyle.org>
 <53425E4F.6090901@maniatis.org>
 <5098F15A-9F01-4129-BBAD-61F1513A8063@objectstyle.org>
 <CAN-d2bDMqCp+skfMQ187s3DTqbKDe7iG4Z=HRuHvOMMsLyv-sw@mail.gmail.com>
To: dev@cayenne.apache.org

Hi Malcolm,

Cool. Yeah, that=92s what cayenne-crypto will use by default (AES/CBC).

BTW, since you are already using cryptography on your projects, what=92s =
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.
>=20
> 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.
>=20
> =
http://www.oracle.com/technetwork/java/javase/downloads/jce-7-download-432=
124.html
>=20
> regards Malcolm Edgar
>=20
>=20
> On Mon, Apr 7, 2014 at 6:42 PM, Andrus Adamchik =
<andrus@objectstyle.org>wrote:
>=20
>> 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.
>>=20
>> 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.
>>=20
>>> Are you seeing the AES encryption performance to be symmetrical =
between
>> select and insert?
>>=20
>> 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.
>>=20
>> Andrus
>>=20
>>=20
>>=20
>> 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?
>>>=20
>>> Are you seeing the AES encryption performance to be symmetrical =
between
>> select and insert?
>>>=20
>>>=20
>>> Ari
>>>=20
>>>=20
>>> 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.
>>>>=20
>>>> Andrus
>>>>=20
>>>>=20
>>>> On Apr 4, 2014, at 3:21 PM, Andrus Adamchik =
<andrus@objectstyle.org>
>> wrote:
>>>>=20
>>>>> So the crypto module is done and available on trunk. Here is a =
minimal
>> configuration that will do AES/CBC encryption:
>>>>>=20
>>>>> 1. Create a keystore and generate a secret key in it:
>>>>>=20
>>>>> keytool -genseckey -keystore /tmp/ks1.jceks -storetype JCEKS =
-alias
>> mykey
>>>>>=20
>>>>> 2. Start Cayenne with crypto:
>>>>>=20
>>>>> // this can also be a URL or a String representing URL
>>>>> File keyStore =3D new File("/tmp/ks1.jceks");
>>>>>=20
>>>>> // obtain this somehow
>>>>> char[] keyPassword =3D ..
>>>>>=20
>>>>> // "mykey" is the key alias in #1
>>>>> Module crypto =3D new CryptoModuleBuilder().keyStore(keyStore,
>> keyPassword, "mykey").build();
>>>>>=20
>>>>> // this will enable encryption/decryption for all columns matching
>> ^CRYPTO_ regex
>>>>> // those must be either character or binary columns
>>>>> ServerRuntime  runtime =3D new =
ServerRuntime("cayenne-myproject.xml",
>> crypto);
>>>>>=20
>>>>>=20
>>>>> 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.
>>>>>=20
>>>>> But ... everyone is free to give it a try ;)
>>>>>=20
>>>>> Andrus
>>>>>=20
>>>>>=20
>>>>=20
>>>=20
>>> --
>>> -------------------------->
>>> Aristedes Maniatis
>>> GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A
>>>=20
>>=20
>>=20