It's all good. I have less meetings today then I normally would and the exercise was beneficial as it got me thinking about other potential vectors.
Since the key for this is configurable via the OSGi console I would have taken key rotation as being a business process exercise rather than a technical one. But I don't mind changing it, I'm having a lot of fun with this. To make sure I'm on the same page. The direction right now is AES/CBC/PKCS5Padding but with encrypt and MAC? -----Original Message----- From: Antonio Sanso [mailto:asa...@adobe.com.INVALID] Sent: Monday, November 20, 2017 3:07 PM To: dev@sling.apache.org Subject: Re: value level encryption - Donating? EXTERNAL hi Jason, I get your point On Nov 20, 2017, at 4:57 PM, Jason Bailey <jason.bai...@sas.com> wrote: > Thanks Antonio. I had considered doing GCM, but I hesitated since it's not > listed as a standard transformation that a Java platform must support. As I > couldn't know what platform it would be running on I tried to be as much OOTB > as possible. That desire to be OOTB is also why it's 128bit. My idea was to > provide a generic level of encryption with the assumption that a downstream > implementer would/should implement the EncryptionProvider service to the > level of security their company requires. > > Saying that, if the desire is to have it GCM I will get that implemented. Thanks a lot taking this consideration and speed the implementation. You are right about AES GCM. On top there is also another problem with it. AES GCM uses a nonce of 96 bits. It is vital important to never reuse the same nonce with the same key otherwise the result is a real catastrophe (cryptographically wise). This implies, given the birthday paradox, that we need to rotate the key after 2^48 encryptions. This is a pretty big number but you know the life of the key can be also long. Hence, without key rotation, it wouldn't probably good to ship with this (now I am sorry you already jumped on it and implemented but I did not think you were so fast). Another more conservative approach would be encrypt-than-mac (or we can simply keep AES/CBC as default). An overall observation would be also that given the sensitive topic it would be good to have a more extensive test suite for this feature... my 2 cents regards antonio > > -----Original Message----- > From: Antonio Sanso [mailto:asa...@adobe.com.INVALID] > Sent: Monday, November 20, 2017 10:29 AM > To: dev@sling.apache.org > Subject: Re: value level encryption - Donating? > > EXTERNAL > > hi Jason, > > thanks a lot for the donation. > I already commented on the issue, just pasting inline part of the > comment though > > On Nov 20, 2017, at 2:50 PM, Jason Bailey <jason.bai...@sas.com> wrote: > >> So I'm just about done implementing this. >> >> https://github.com/JEBailey/sling-encrypt >> >> Value level encryption. IV is stored inline so there's no repetition. >> Accessing encrypted data via the EncryptionValueMap will decode it >> automatically on access and will handle automatically encrypting values if >> an encrypted value is updated. >> >> Only problem I had besides catching up on the last 15 years of >> cryptography > > I have seen you have used AES/CBC that is not (extremely) bad. Said that if > we really want to put this in Sling we'd better do things as the state of art > requires. > As rule of thumbs you never (only) encrypt . You'd better add some integrity > check mechanism (eg AES GCM or encrypt-then-mac). > > regards > > antonio > >> was that the downstream application I use has a non configurable whitelist >> filter for post processors that contain an '@' So I had to make the post >> processor configurable. >> >> As mentioned earlier I wrote this with the intention of donating. I tried to >> make it as easy as possible for it to be pulled into where it needs to go. >> >> However I don't know the process for Donating. Can someone point me the way >> or to some documentation? >> >> Thanks. >> -Jason >> >> -----Original Message----- >> From: Justin Edelson [mailto:jus...@justinedelson.com] >> Sent: Friday, November 03, 2017 3:37 PM >> To: dev@sling.apache.org >> Subject: Re: value level encryption >> >> EXTERNAL >> >> In AEM, posting encrypted properties to /etc/cloudservices is historically >> the primary use case for @Encrypted, but the PostProcessor applies to all >> post requests. >> >> I think this would be a useful addition to Sling. We may want to have some >> kind of SPI to support different encryption schemes, but that's an >> implementation detail. >> >> Regards, >> Justin >> >> >> On Fri, Nov 3, 2017 at 2:48 PM Jason Bailey <jason.bai...@sas.com> wrote: >> >>> They only docs I can find on that, assuming we're talking AEM, >>> mentions it only works for posting things into /etc/cloudservices. So >>> that's out. >>> It's been a while, but I'm under the impression that all >>> implementations of the java platform now come with a certain level >>> of crypto >>> >>> https://docs.oracle.com/javase/8/docs/api/javax/crypto/Cipher.html >>> >>> I'd probably add a configuration so you could define the level of >>> cryptography, and then that would allow people who needed a higher >>> level to install their own providers. Is this something that Sling >>> would be interested in? Since I'm going to be writing this, if >>> you're interested, I'd rather write it with the intent of directly donating >>> it. >>> >>> >>> >>> -----Original Message----- >>> From: Justin Edelson [mailto:jus...@justinedelson.com] >>> Sent: Friday, November 03, 2017 1:35 PM >>> To: dev@sling.apache.org >>> Subject: Re: value level encryption >>> >>> EXTERNAL >>> >>> We have this in our commercial product. At a high level, the way it >>> works is that there is a PostProcessor which looks for an @Encrypted >>> postfixed property and, if that is present, the corresponding >>> property is stored in an encrypted fashion. Decryption is all done >>> manually, although personally the idea of an EncryptionValueMap seems >>> really cool to me. >>> >>> I believe the challenge in bringing this into Sling relates to the >>> encryption libraries. >>> >>> On Fri, Nov 3, 2017 at 8:45 AM Jason Bailey <jason.bai...@sas.com> wrote: >>> >>>> Here's the use case >>>> >>>> My organization has decided that to conform to the GDPR, any >>>> sensitive data should be encrypted while at rest. From a Sling >>>> perspective that is a challenge since we've empowered the authors >>>> to create forms the way they want. So to be on the safe side, we're >>>> looking at encrypting all form fields as they are persisted, and >>>> then decrypting the values from the resource when we need to processes >>>> them. >>>> >>>> Now I'm thinking of an EncryptionValueMap that will simplify this >>>> process and encapsulate the functionality. You guys are usually >>>> ahead of me when I come up with this stuff and I don't like >>>> replicating effort. So is there any functionality currently or >>>> planned to handle encryption of resource values? >>>> >>>> Thanks >>>> Jason >>>> >>> >
