JWE For Encryption, Custom Provider for Decryption?

[pavgup]

Heyyo! I've got a curious question, I'm working on scenarios where I'd like to use the public half of an RSA key to encrypt content with skopeo as the runner (e.g., skopeo copy --encryption-key jwe:mymagicprivkey.key oci:alpine oci:encrypted) and then use a custom provider to handle decryption (e.g., skopeo copy --decryption-key provider:mysimpleprovider oci:encrypted oci:decrypted) with a configuraiton that looks a little like:

{
    "key-providers": {
        "mysimpleprovider": {
            "cmd": {
                "path":"/bin/mysimpleprovider",
                "args": []
            }
        }
    }
} 

Naturally, when ocicrypt sees the encrypted content, it sees it with the jwe scheme and thusly finds no match to decrypt when the only option is mysimpleprovider.

Can I have a mismatched encryption/decryption scenario?

[stefanberger]

Can I have a mismatched encryption/decryption scenario?

I am not sure whether it would work, likely that not. Though why would the built-in decryption provider not be sufficient?

[pavgup]

It's a somewhat special case where the private half of a key is only available remotely in an HSM to decrypt content and requires a series of programatic steps to authenticate. The public half of the key, is however, easily available.

I also wonder if there's a scenario that would allow the direct use of an symmetric key with ocicrypt, but this doesn't seem to exist as far as I can tell...

[stefanberger]

I also wonder if there's a scenario that would allow the direct use of an symmetric key with ocicrypt, but this doesn't seem to exist as far as I can tell...

At least not with any of the provided crypto implementations. All of them rely on public key crypto.

It's a somewhat special case where the private half of a key is only available remotely in an HSM to decrypt content and requires a series of programatic steps to authenticate. The public half of the key, is however, easily available.

That's like pkcs11, but pkcs11 is also handled internally.

Likely you solution would have to rely on your own external provider handling both the encryption and the decryption.

[pavgup]

Likely you solution would have to rely on your own external provider handling both the encryption and the decryption.

Would this project be open to a PR that would enable the scenario where a built-in provider can be swapped out for a custom provider in either the encryption or decryption scenario? This would enable a class of RATS-style interactions inside a confidential computing context that are otherwise hard for users to implement.

For example, if I wanted to override the internal JWE implementation for decryption, I'd first attempt to use the internal JWE implementation, but before failing, I'd allow a specific attempt to override an internal provider that looked something like this:

{
    "key-providers": {
        "jwe": {
            "cmd": {
                "path":"/bin/mycustomjwe",
                "args": []
            }
        }
    }
} 

Similarly, if I brought a custom provider.jwe in to encrypt content, but I couldn't provide this in a decryption context for whatever eason, I'd first attempt to find this provider.jwe, and if that failed, I'd make an attempt to use the internal jwe provider before failing.

Thoughts?

[stefanberger]

Would this project be open to a PR that would enable the scenario where a built-in provider can be swapped out for a custom provider in either the encryption or decryption scenario?

Sure, you can send the PR. I am currently out of the office...