[PQ] Add experimental support for HPKE

[sgmenda-aws]

Description of changes:

Add experimental support for using AWS-LC HPKE as a Cipher using AWS-LC's hpke.h:

• update to building with an experimental branch of aws-lc
• add new AlgorithmParameterSpec HpkeParameterSpec
• add new EvpKey EvpHpkeKey
• add new PublicKey EvpHpkePublicKey and new PrivateKey EvpHpkePrivateKey
• add new KeyPairGenerator HpkeGen which generates a HPKE key, backed by the native hpke_gen.cpp
• add new Cipher``HpkeCipher, which performs single-shot HPKE encryption and decryption, backed by the nativehpke_cipher.cpp.

Call-outs:

• lines 40-209 in HpkeCipher.java contain the core java implementation
• native files hpke_gen.cpp and hpke_cipher.cpp contain the main cpp wrappers
• general code organization into classes and methods
• there are some outstanding TODO that will be addressed in a later revision

Testing:

Added HpkeGenTest and HpkeCipherTest to test basic correctness.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[geedo0]

Still have to cover cipher implementation and testing.

[geedo0]

What's the story here? Is this temporary? Will this branch exist in upstream AWS-LC? We can't be referencing submodules in personal forks.

[sgmenda-aws]

Yes, this is temporary till aws/aws-lc#1777 is merged.

[geedo0]

What's going on here?

[sgmenda-aws]

Github does not support git checkout <branch> in submodules. This is temporary till aws-lc merges the HPKE PR, once that's done, I'll add this back and replace the VersionId with a commit hash.

Sorry for not explicitly marking these temporary changes.

[geedo0]

This is looking pretty good. Only pending items I see are the placeholder AWS-LC references and failing CI. If we can get the CI passing, I'll happily approve.

[geedo0]

...which we discard

[initsecret]

Turns out -Xcheck:jni does not like splitting one java array into multiple buffers, like splitting output into enc and ct. And, it was silently preventing writes to ct, making encrypt return an all-zero buffer. This was causing the failures.

Since -Xcheck:jni is not enabled on MacOS, I didn't notice it initially. And since the truncated logs don't make it explicit that this test was failing with -Xcheck:jni (and passing without.) I was extremely confused.

The following commit fixes this issue, and the test now passes with -Xcheck:jni: initsecret@32eacb9

[geedo0]

Alright, just so I fully understand what's going on here. You understandably no longer have access to the original Github account so you pushed this fix to a separate fork/account?

Since you're no longer with us and this work is largely complete. The sensible next step is to cherry-pick this last commit to the branch and see how it runs against the tests. If we like the results enough, I'm inclined to merge the work into the experimental branch as-is since it's already largely complete. We can come back in later to do the necessary work to integrate it into the main trunk.

[initsecret]

@geedo0 Precisely. I figured out the bug after so pushed a fix to my personal account. Yes, if this passes the tests, I was hoping you'd merge into the experimental branch. Alternatively, if you prefer, I could open a new PR, but it seems easier to apply this fix on top with git am like

wget -O fix.patch https://github.com/initsecret/amazon-corretto-crypto-provider/commit/32eacb911d797e5352b3f8eb08271b543831f68d.patch
git am fix.patch
git push

[geedo0]

I've brought this to the team's attention and we are working on getting this PR integrated while being respectful of your personal time. The fact that we've locked you out of this account is problematic though. The idea we landed on is to have Amir fork your work and submit a new PR that includes your last change. We'll then test/review/iterate from there, but I've recommended that we simply bias towards merging it into the experimental branch as any further cleanup can be pulled into the greater effort of re-integrating this when the time comes.