Add support for tink primitives - AEAD AES-CTR HMAC #13033

Activity

1. reaperhulk commented on Jun 4, 2025

   

   reaperhulk

   on Jun 4, 2025

   Member

   More actions

   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 😄

   👍React with 👍1Reacted by Vjeran Grozdanić
2. alex commented on Jun 4, 2025

   

   alex

   on Jun 4, 2025 via email

   Member

   More actions

   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.

   👍React with 👍1Reacted by Vjeran Grozdanić
3. alex

   added

   api design

   on Oct 4, 2025
4. fury0928 commented on Jan 21, 2026

   

   fury0928

   on Jan 21, 2026

   More actions

   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?
5. alex commented on Jan 21, 2026

   

   alex

   on Jan 21, 2026

   Member

   More actions

   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.
6. fury0928 commented on Jan 21, 2026

   

   fury0928

   on Jan 21, 2026

   More actions

   I see, I thought this was ready to start, would you assign me any other issue to contribute?
   Thank you
7. alex commented on Jan 21, 2026

   

   alex

   on Jan 21, 2026

   Member

   More actions

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