Feature Request : Encrypt / Decrypt

[daamien]

Hi,

My name's Damien Clochard, I am working for DALIBO, a french PostgreSQL company and we are currently
building a new PostgreSQL extension named "The Cryptic Elephant" that aims to implement Transparent
Column Encryption (TCE).

The project is currently released in alpha under the PostgreSQL License:
https://gitlab.com/dalibo/the_cryptic_elephant

The extension is written in Rust. We plan to manage keys using an external KMS using the KMIP protocol.

We have identified your project as a great candidate to implement communication between our
extension and the various KMS of the market.

However as far as we can tell, your crate does not implement some features that would be super useful
for us. Namely would need to encrypt/decrypt messages using 2 functions that would look like this:

pub fn decrypt(
    key_unique_identifier: &str,
    nonce: Option<Vec<u8>>,
    ciphertext: Vec<u8>,
) -> Result<Vec<u8>>

pub fn encrypt(
    key_unique_identifier: &str,
    nonce: Option<Vec<u8>>,
    plaintext: Vec<u8>,
) ->  Result<Vec<u8>>

Before going further into technical details, we have a handful of questions:

• Can you confirm that this project is actively maintained ?
• Is this something you plan to do in the near future ?
• Do you accept external contributions ?
• More generally, how can we help moving forward this feature ?

We're open to discuss about this in depth with you in any manner you prefer.

Regards,

[ximon18]

Hi @daamien,

Thanks for taking an interest in this crate and taking the time to submit your questions.

The short version is that this project is maintained but only as much as needed for our own purposes. We will continue to maintain it as long as we continue to use it. We currently use it in our Krill and our in-development Cascade products so it is unlikely that we would stop using or maintaining this crate without notice.

While we don't need encrypt and decrypt support ourselves at the moment I would not be against support for them being added, I think such a change would only be additive and not conflict with anything we are doing or planning. We're not against external contributions but we do have to be mindful of the time and resources that we have available to support them and the feedback they require, and any contributions should be aligned with the existing style and purpose of the code.

I think it's worth pointing out a couple of things in particular.

Firstly, we have concerns with "AI" generated contributions for various reasons and thus are not willing to accept "AI" generated work. We will be publishing an "AI" policy in the near future.

Secondly, we are making, as time permits, breaking changes in the next branch including moving over to new (de)serialization code and removing the need for the kmip-ttlv crate. That work is currently complete enough for us to use for our purposes but still lacking things we want to do before merging it into the main branch. Any proposed changes should be aware of the changes being made in the next branch and consider whether targeting the next branch directly would make more sense to avoid later re-work.

Thanks,

Ximon

[daamien]

Hi @ximon18 !

Thanks for your quick answer !

After some discussion, we're going to give it a try !

Here's a recap of the changes we plan to do on the next branch

• client/client.rs : Add fn encrypt(..)
• types/response.rs : Add a struct EncryptResponsePayload based on the KMIP V1.2 spec
• types/request.rs : Add RequestPayload::Encrypt(..)
• types/request.rs : modify RequestPayload::fast_scan(..)
• types/request.rs : modify RequestPayload::format(..)

( and then do something similar for decrypt(..) )

Did we miss something ? Any input, comments or advices would be appreciated before we start working on this....

Regarding the next branch, do you have a tentative schedule for its release ? Of course we're not asking for an engagement but rather a vague idea of when it would be available.

About AI, we share your concerns. For our own open source projects, we also have limited time to review external contributions. Likewise we don't want to waste that time with poor "AI" generated contributions. That being said, some of us may use AI from time to time for certain tasks : prototyping, translating, summarizing documents, etc. However the code we will produce and submit will be written and reviewed by humans.

[ximon18]

Hi @daamien,

Did we miss something ? Any input, comments or advices would be appreciated before we start working on this....

I expect at the moment you are more familiar with the next branch code than I am, I have been working on other projects for quite a while and hope to get back to this project soon.

Regarding the next branch, do you have a tentative schedule for its release ? Of course we're not asking for an engagement but rather a vague idea of when it would be available.

We don't have a schedule per se, but we do have an intent to release a production ready version of our Cascade product in the coming months, and Cascade's use of HSMs is done via Cascade-HSM-Bridge which uses this crate. Ideally for a production release we would want all involved crates to be published on crates.io and we would want to publish main so next would need to be merged for that. Ideally we would also recover some of the lost error reporting fidelity that the next branch suffers from compared to the main branch. So that should mean the timeline for merging next to main is the coming months.

However, we won't push releases out that aren't ready, and as the rest of the s/w development world we are experiencing a big increase in LLM based security bug reports on our other products which is consuming more of our time and resources than usual. So it's hard to make exact plans or commitments at the moment.

About AI, we share your concerns. For our own open source projects, we also have limited time to review external contributions. Likewise we don't want to waste that time with poor "AI" generated contributions. That being said, some of us may use AI from time to time for certain tasks : prototyping, translating, summarizing documents, etc. However the code we will produce and submit will be written and reviewed by humans.

Thanks, that's appreciated. FYI we are in the process of updating all of our projects to refer to our recently published LLM policy.

Ximon