Add support for tink primitives - AEAD AES-CTR HMAC

[vgrozdanic]

Hi all, as per discussion in #12968 (comment) i would propose the first supported primitive to be AES-CTR HMAC.

Instead of a one quite large PR, I propose the work to be separated into multiple "smaller" PRs/tasks:

• implement AES-CTR-HMAC primitive following the tink's wire format and the draft for AES-CBC-HMAC from Mcgrew
• implement keyset
• implement keyset JSON serialization/deserialization
• (optional, but needed for full tink support) protobuf support <-- this requires additional dependency (protobuf package) to cryptography library :/

If this sounds good, we can discuss more in detail and I can start slowly working on this.

DISCLAIMER: I am very inexperienced with (more advanced) cryptography, so my understanding could be totally wrong :)

[reaperhulk]

Separating into small, reviewable PRs that can be independently reviewed and landed is a good idea, yes.

We shouldn't need to add a Python dep for protobuf for this because what we implement here is going to live chiefly on the Rust side. Instead, we can use a tool that builds rust structs from proto files with no additional deps. I haven't done the research here, but things like prost-build may be a way forward (and some rust tink projects have done this with prost, see: https://docs.rs/tink-proto/latest/tink_proto/).

For any primitive we'll also need a set of test vectors; preferably tink's own!

As an aside, as such a low level dependency in the ecosystem adding something like protobuf and its myriad dependencies is really not an option. Fortunately we've got alternatives here 😄

[alex]

In theory rust protobuf can be entirely by hand-writing the structs with https://docs.rs/prost/latest/prost/

…

On Tue, Jun 3, 2025 at 8:05 PM Paul Kehrer ***@***.***> wrote: *reaperhulk* left a comment (pyca/cryptography#13033) <#13033 (comment)> Separating into small, reviewable PRs that can be independently reviewed and landed is a good idea, yes. We shouldn't need to add a Python dep for protobuf for this because what we implement here is going to live chiefly on the Rust side. Instead, we can use a tool that builds rust structs from proto files with no additional deps. I haven't done the research here, but things like prost-build may be a way forward (and some rust tink projects have done this with prost, see: https://docs.rs/tink-proto/latest/tink_proto/). For any primitive we'll also need a set of test vectors; preferably tink's own! As an aside, as such a low level dependency in the ecosystem adding something like protobuf and its myriad dependencies is really not an option. Fortunately we've got alternatives here 😄 — Reply to this email directly, view it on GitHub <#13033 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAAGBFDW77REPJSEYO3PN33BYZ5HAVCNFSM6AAAAAB6Q3LLKWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSMZXG44TANRWGI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

-- All that is necessary for evil to succeed is for good people to do nothing.

[eureka0928]

Hi @alex @reaperhulk , nice to meet you
Is this still valid issue?

• implement AES-CTR-HMAC primitive following the tink's wire format and the draft for AES-CBC-HMAC from Mcgrew
• implement keyset
• implement keyset JSON serialization/deserialization

I'd like to contribute on this project, may I try on first or second PR of these three?

[alex]

This is still an open issue, however there's a lot of open design questions about what the API would look like, what our implementation strategy woudl be, etc. before you start implementation we'd like someone to share a design here.

[eureka0928]

I see, I thought this was ready to start, would you assign me any other issue to contribute?
Thank you

[alex]

We don't assign issues, if you want to start on something you don't need that.