Thanks Antonio, I appreciate the feedback and I empathize with the time constraints.
Current JIRA for donating https://issues.apache.org/jira/browse/SLING-7255 Source Code for donation https://github.com/JEBailey/sling-encrypt -----Original Message----- From: Antonio Sanso [mailto:asa...@adobe.com.INVALID] Sent: Tuesday, December 05, 2017 5:41 AM To: dev@sling.apache.org Subject: Re: value level encryption - Donating? EXTERNAL hi Jason, firstly I really want to thank you for this great effort. I was more than happy to give a quick look at this solution and provide some feedback. Unluckily though I do not have at this moment any free cycle to give the attention this donation deserves. If any of the other committers would like to standup is more than welcome to continue with the donation process. Another option would be to keep this code in github (as you already noticed Sling migrated to git and is highly modularized in any case) regards antonio On Dec 4, 2017, at 3:55 PM, Jason Bailey <jason.bai...@sas.com> wrote: > Hi Antonio, > > I added a couple of things to the repository based on your feedback. The > primary change was the addition of a key provider that would allow you to > separate the management and the storage of secret keys away from the > encryption provider. I also added two implementations of that service as > well. One which utilizes the java keystore and the other which provides you > the ability to define keys in the OSGi Configuration. The secondary one being > useful for testing and for environments where you don't have access to the > filesystem. I will most likely be implementing another variant to integrate > with the thycotic secret server. > > To support Key rotation, I added additional identifying bytes after the IV > that is used by the KeyProvider to provide the correct key for decryption. > While all encryption processes are done with the KeyProvider's primary key. > > Example of how this would work: I am using a KeyProvider with a primary key > for 6 months. As part of a Security Policy this needs to be changed. I then > take the existing primary key and add it to the secondary list and provide a > new key as primary. At this point all new encryptions will occur with the > primary key, however I will still be able to access the older encrypted > messages as well. To update the older keys with the new key, it's a matter of > iterating over the stored encrypted resources with the EncryptableValueMap > and using the encrypt(propertyName) method. Which will re-encrypt the > property with the new primary. > > I'm running with the AES/GCM because it provides the best overall security > and fits my use cases and the key rotation support should alleviate some > concerns as well. > > -Jason > > -----Original Message----- > From: Antonio Sanso [mailto:asa...@adobe.com.INVALID] > Sent: Tuesday, November 21, 2017 5:37 AM > To: dev@sling.apache.org > Subject: Re: value level encryption - Donating? > > EXTERNAL > > hi Jason, > > I basically see 3 options: > > * ship with AES/CBC that is ok but suboptimal > - ship with AES-GCM that is good but has the problem of the nonce highlighted > before. The key rotation would help but than what do you do on rotation? > Decrypt all the encrypted value and re-encrypt with the new key... ? > - Encrypt-than-MAC > > I have also noted that the key is stored as OSGi configuration... This might > also be part of a bigger discussion.... > > regards > > antonio > > On Nov 20, 2017, at 10:03 PM, Jason Bailey <jason.bai...@sas.com> wrote: > >> 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 >>>>>> >>>>> >>> >> >
