On 13/03/2014 5:25pm, Andrus Adamchik wrote: > > > On Mar 13, 2014, at 1:55 AM, Aristedes Maniatis <[email protected]> wrote: > >> On 12/03/2014 6:13pm, Andrus Adamchik wrote: >>> A heads up. I am looking to extend ExtendedType API to be a little more >>> context-aware (know which attribute is being read/written). My motivation >>> is quite interesting on its own - I need to implement generic data >>> encryption extensions that would encrypt/decrypt certain columns on the >>> fly. And I feel like ExtendedType is a place that is low-level enough to >>> make the encryption transparent to the rest of the stack. Very excited >>> about this project :) >> >> Out of interest, what are you doing for key storage? That's often the most >> complex part of the problem. > > Yes, you are exactly right about that. For now planning on using normal java > keystore facility. Starting the servers will require an admin to enter > password which will unlock the keystore. There will likely be additional > security enhancements protecting the keystore.
Ah, the automatic failover at 3am is going to be fun for some sysadmin :-) > The important thing is to move all these concerns outside Cayenne, so that > each org could make their own decisions as to the levels of security > required. Cayenne will provide an abstract way to do transparent per-column > crypto. I am thinking of a very simple Cayenne-side “cayenne-crypto” Maven/DI > module, free of key management code and defining 2 abstract services: (1) > Cypher - a pluggable encryption mechanism with ability to version keys (2) > Metadata - telling Cayenne which columns are encrypted. And also declaring > overrides of RowReaderFactory and other relevant services to enable > encryption. It would be nice public relations to have "Cayenne has out-of-the-box crypto support" as a feature. Are you storing a key version as part of the encrypted data stream? Ari -- --------------------------> Aristedes Maniatis GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
