cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrus Adamchik <and...@objectstyle.org>
Subject Re: cayenne-crypto
Date Tue, 08 Apr 2014 07:53:53 GMT
> The management of the symetrical encryption keys, it the trickiest thing in this space
and
> reducing their exposure.

Right, I am dealing with that myself now.

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

Good idea. Will put it on TODO list.

Andrus



On Apr 8, 2014, at 8:13 AM, Malcolm Edgar <malcolm.edgar@gmail.com> wrote:
> 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
View raw message