FLE -Is it possible to ignore decrypting non-encrypted fields in FLE?

For FLE, we use the SDK3.0 default encryptor/decryptor. At document level fields, use the @Encrypted annotation. We’d like to begin encrypting newly added documents, but existing documents must be retrieved without being decrypted (since they never have encrypted fields). Is it possible to ignore decryption if non-encrypted data is discovered?

1 Like

Hi Pavan,

That’s a reasonable request. There’s no easy way to do it today, but with some minor tweaks to the SDK we might be able to make it happen. I filed JCBC-1852 for tracking.

One benefit of encrypted fields is that they are authenticated. That is, you know they were written by someone in possession of the secret key. That benefit is lost when you allow reads from either encrypted or unencrypted fields, so it’s important for this to be an “opt-in” feature.

Thanks,
David

Thanks @david.nault . As an opt-in feature, I agree with you. This feature is extremely useful during the migration process and will eliminate system downtime. We already have a Couchbase database with over 70 million documents and an active-active datacenter model. We are not permitted to take any downtime and must implement FLE.

Could you please advise on what changes I need to make to the SDK to make this happen? According to my understanding, I must override the custom implementation of the EncryptedFieldDeserializer class. But I can’t figure out how to connect this.

Could you please advise on what changes I need to make to the SDK to make this happen? According to my understanding, I must override the custom implementation of the EncryptedFieldDeserializer class. But I can’t figure out how to connect this.

A future version of the SDK will have a config option you can simply enable. This will likely be included in the September 6th release.

If you can’t wait, you’ll need to find a way to prevent this line from being executed. (There are actually two versions of EncryptedFieldDeserializationModifier; one for if Jackson is present on the class path, and a “repackaged” verson for the repackaged Jackson bundled with the SDK.)

You could copy & paste the code for EncryptionModule, and change it so it uses your custom EncryptedFieldDeserializationModifier. Then configure the SDK as shown in Using a Custom ObjectMapper.

Thanks,
David

Hi @pavan5000 ,

There’s an SDK code change up for review that would add an optional migration attribute to the @Encrypted annotation. For example, if you were to write:

@Encrypted(migration = FROM_UNENCRYPTED)

then either encrypted or unencrypted values would be accepted when deserializing. Would that work for you?

Thanks,
David

Hello @david.nault ,

This accomplishes exactly what I was looking for. I appreciate your promptness. Can you confirm that this change will be incorporated into the September release candidate?

FYI… This is a Comcast requirement.

Thanks
Pavan.

Yes, the code is checked in and will be present in Java SDK 3.2.1, scheduled for release on September 6th.

It’s also available right now in 3.2.1-SNAPSHOT. Here’s a StackOver flow post about configuring a project to use dependencies from the Sonatype snapshot repository.

FYI… This is a Comcast requirement.

Thanks, that’s good to know. I should probably mention that support on this public forum is provided on a “best effort” basis, and response times can vary a lot depending on how busy we are. If you don’t get a super-speedy response next time, you can also contact our support team directly and they will prioritize your issue.

Let us know if you have more ideas for improving the FLE library :slight_smile:

Thanks,
David

@david.nault Thank you.

Hi Pavan,
3.2.1 was released early,
we have added a short note on the migration addition to the docs: Field Level Encryption from the Java SDK | Couchbase Docs

1 Like

Thank you very much. We appreciate your quick response time.

2 Likes