Closed jwright-stripe closed 1 year ago
Thank you for filing the issue.
The test is wrong as is; it should additionally add an "AesGcmKey" to the keyset (i.e., a symmetric Aead key). When you have a keyset which contains both symmetric Aead keys, and HybridEncrypt keys, you shouldn't be able to create a hybridencrypt primitive.
I will fix this.
Thank you @tholenst! That makes perfect sense to me.
As an aside, I appreciate y'all having the existing test for the buggy behavior of using an AEAD keyset in HPKE - I came across that in my own testing and it was nice to see that was already known and expected!
Describe the bug:
Hi there! 👋
I'm seeing some inconsistent information on how to use hybrid encryption in Go.
I see this test that demonstrates "buggy behavior" by creating a new key using the
hybrid.DHKEM_X25519_HKDF_SHA256_HKDF_SHA256_AES_128_GCM_Key_Template
template, fetching the public keyset from that handle, and then creating a newhybrid.NewHybridEncrypt
with it.Could you please help me understand the bug here? This seems like the way hybrid keysets are designed to be used, but it's possible I'm missing some background on the way these keysets are expected to operate.
The reason I'm labelling this as "inconsistent" is that from what I can tell the round-trip tests use this same behavior to show that things are working as expected. And any other tests for the public key manager seem to use the same logic that
.Public()
uses to get the public key associated with a keyset containing a private key.If there is buggy behavior in the above example, could you please detail what the expected route is for using hybrid keysets?
Provide your version information:
master
(or 1.7.0 for the long-term version)Is there anything else you’d like to add?
As always, I appreciate all the work y'all do to make Tink a useful library! 💚