> 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 <[email protected]> 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 > <[email protected]>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 <[email protected]> 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 <[email protected] >>> 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 <[email protected]> >> 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 <[email protected]> >>>> 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 >>>>> >>>> >>>> >> >>
