If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/tink-crypto/tink shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across all four use cases

• 12 active contributors
• Distributed ownership (top contributor 35% of recent commits)
• Apache-2.0 licensed
• CI configured
• Tests present
• ⚠ Stale — last commit 2y ago

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live tink-crypto/tink repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/tink-crypto/tink.

What it runs against: a local clone of tink-crypto/tink — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in tink-crypto/tink | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.0 | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | Last commit ≤ 781 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of tink-crypto/tink. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/tink-crypto/tink.git
#   cd tink
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of tink-crypto/tink and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "tink-crypto/tink(\\.git)?\\b" \\
  && ok "origin remote is tink-crypto/tink" \\
  || miss "origin remote is not tink-crypto/tink (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Apache-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Apache-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is Apache-2.0" \\
  || miss "license drift — was Apache-2.0 at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 781 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~751d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/tink-crypto/tink"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Tink is a multi-language cryptographic library providing secure, misuse-resistant APIs for Java, C++, Go, Python, and Ruby. It abstracts away cryptographic complexity by offering high-level primitives (AEAD encryption, key management, serialization) that are hard to use incorrectly, eliminating common pitfalls like weak key derivation, improper padding, or algorithm misuse. Monorepo organized by language: cc/ (C++ with subdirs like cc/aead/, cc/signature/), java/ (Java implementation), go/ (Go bindings), python/ (Python wrappers), ruby/ (Ruby support). Each language has WORKSPACE/CMakeLists.txt alongside BUILD.bazel files. Core abstraction is the Key Management System (KMS) with pluggable key managers, wrappers for composition, and proto-based serialization.

Backend engineers, security teams, and mobile developers at organizations like Google who need to integrate production-grade encryption without cryptographic expertise. This includes Android developers using the Java bindings, C++ system engineers building secure services, and Go backend developers needing authenticated encryption.

Production-ready across Java/Android, C++, Go, and Python (all field-tested per README); latest version 1.7.0 (Aug 2022). However, the main repo is now read-only and archived—active development has moved to split repos under github.com/tink-crypto. This monorepo is no longer maintained and should not be used for new projects.

Critical risk: This repository is archived and unmaintained. New code should target language-specific repos at tink-crypto instead. The monorepo shows no recent commits and the README explicitly warns it's read-only. Security patches and bug fixes will not be applied here; you must migrate to the split repositories for ongoing support.

No active development—this repo is frozen. The split occurred as planned per the Tink roadmap, moving language-specific code to separate GitHub orgs. Use github.com/tink-crypto/tink-java, tink-cc, tink-go, etc., for active maintenance.

This repo should not be used for new development. For active work, clone language-specific repos instead:

# Example: for C++
git clone https://github.com/tink-crypto/tink-cc.git
cd tink-cc
bazel build //cc/...

# Example: for Java
git clone https://github.com/tink-crypto/tink-java.git
cd tink-java
bazel build //src/main/java/com/google/crypto/tink/...

If you must use this archived repo for reference: git clone https://github.com/tink-crypto/tink.git && cd tink.

Daily commands: This repo contains no runnable binaries—it's a library. To use Tink in your project:

Java/Gradle: Add com.google.crypto.tink:tink-java to dependencies.

C++ with Bazel: bazel build //cc/aead:aead_factory builds the AEAD factory library.

Python: pip install tink (from the split tink-py repo).

Go: go get github.com/tink-crypto/tink-go/v2.

For development in archived repo: bazel build //cc/... or bazel build //java/....

• cc/aead/aead_factory.h: Defines the primary public API for AEAD encryption—factory pattern entry point for getting Encrypt/Decrypt primitives from keysets
• cc/aead/aes_ctr_hmac_aead_key_manager.h: Concrete key manager for AES-CTR-HMAC, demonstrates how algorithm-specific key management and primitive creation is implemented
• cc/aead/aead_key_templates.h: Pre-configured secure key templates (AES-128-GCM, AES-256-GCM, etc.) reducing misuse-prone key selection
• cc/aead/aead_wrapper.h: Wrapper pattern for composing multiple AEAD primitives (e.g., key rotation scenarios), core to Tink's flexibility
• java/src/main/java/com/google/crypto/tink/Aead.java: Java interface for AEAD primitives, language-specific abstraction boundary
• BUILD.bazel: Root Bazel configuration showing monorepo structure across languages

Do not modify this archived repo. For bug fixes or features:

1. Find the corresponding split repo (e.g., tink-cc for C++ issues)
2. In that repo: modify source files in //cc/aead/aes_ctr_hmac_aead_key_manager.cc (example)
3. Add tests alongside (e.g., *_test.cc files)
4. Run Bazel: bazel test //cc/aead:all to verify

For this archived monorepo specifically: only reference architecture for understanding; all PRs are rejected.

1. This repo is archived—attempting to submit PRs or use it for new code will fail; migration to split repos is mandatory. 2. Bazel version locked (see .bazelversion file)—wrong Bazel version causes cryptic build errors. 3. Language separation is now strict—C++ code will not build Java bindings; each split repo is self-contained. 4. Proto files are language-specific post-split—don't rely on cross-language proto sharing from this monorepo. 5. CMake and Bazel coexist but may be out of sync; prefer Bazel for C++ builds in split repos.

• Key Management System (KMS) — Tink's entire security model revolves around KMS abstraction—understanding how keys are created, rotated, and serialized is essential to using Tink correctly. Each language split repo has language-specific KMS bindings.
• Authenticated Encryption with Associated Data (AEAD) — AEAD is Tink's recommended encryption primitive (replacing raw AES)—it provides both confidentiality and authenticity, preventing tampering. Most cc/aead/ code implements AEAD variants.
• Key Templates — Tink's philosophy: pre-approved key configurations (e.g., AES_128_GCM_KEY_TEMPLATE) prevent misuse by removing weak parameter selection. See cc/aead/aead_key_templates.h.
• Keyset Proto Serialization — Tink keys are serialized as Protocol Buffers—this enables language-agnostic key sharing and persistent key storage. Look at *_proto_serialization.cc files for implementation details.
• Wrapper Pattern (Primitive Composition) — Tink uses wrappers (e.g., aead_wrapper.h) to compose multiple crypto primitives—critical for key rotation where old and new keys coexist. Understand this to extend Tink.
• Registry and Plugin Architecture — Tink uses a Registry pattern where key managers register themselves—allows pluggable crypto algorithms and custom implementations. Critical for adding new primitives.
• Algorithm Agility — Tink abstracts algorithm details (AES vs ChaCha20, GCM vs EAX) behind common interfaces so swapping crypto doesn't break application code. Core philosophy preventing lock-in.

• tink-crypto/tink-java — Active split repo for Java/Android—use this instead of the archived java/ directory here for all new JDK projects
• tink-crypto/tink-cc — Active split repo for C++—use for all C++ work; this monorepo's cc/ is archived and unsupported
• tink-crypto/tink-go — Active split repo for Go—canonical source for Go Tink bindings; monorepo go/ directory is read-only
• google/wycheproof — Test vector collection for cryptographic primitives—Tink was born from fixing weaknesses found by these tests; referenced throughout Tink design
• google/boringssl — Underlying cryptographic library for C++ Tink on many platforms; Tink's AEAD/signature primitives delegate to BoringSSL for actual crypto

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add proto_serialization tests for all AEAD key types

The repo has proto_serialization files for AES-CTR-HMAC, AES-EAX, AES-GCM, and AES-GCM-SIV, but the file structure shows incomplete test coverage. Several key managers (aes_eax_key_manager.h, aes_gcm_key_manager.h, aes_gcm_siv_key_manager.h) lack corresponding proto_serialization implementations. Adding comprehensive proto_serialization tests would ensure round-trip serialization/deserialization works correctly for all AEAD variants, which is critical for key persistence and interoperability.

• [ ] Check cc/aead/ for missing *_proto_serialization.cc/h files matching existing key managers
• [ ] Create proto_serialization implementations for any missing AEAD types
• [ ] Add corresponding *_proto_serialization_test.cc files with round-trip serialization tests
• [ ] Verify tests cover both valid and invalid serialization cases
• [ ] Ensure proto definitions exist in any proto subdirectories

Add cross-language integration tests for AEAD primitives

The repo structure shows C++ AEAD implementations but is split across multiple GitHub repositories per the README. New contributors could add integration tests that verify C++ AEAD implementations work correctly with serialized keys from other languages (Java, Go, Python). This is high-value because Tink's core value proposition is cross-platform compatibility. Tests should live in cc/aead/ and validate that key templates and encrypted data are compatible across language boundaries.

• [ ] Review cc/aead/aead_key_templates.h to identify standard templates
• [ ] Create cc/aead/aead_cross_language_test.cc with fixtures for each AEAD variant
• [ ] Add test cases that load pre-generated key material from other Tink language implementations
• [ ] Verify encryption/decryption operations work with cross-language serialized keys
• [ ] Document test setup instructions for generating test vectors from other languages

Refactor AES AEAD key managers to reduce duplication

The file structure reveals four very similar AES AEAD key managers (aes_ctr_hmac, aes_eax, aes_gcm, aes_gcm_siv) with nearly identical boilerplate code for key creation, validation, and factory registration. These could be refactored to use a template-based base class or factory pattern to reduce code duplication, improve maintainability, and reduce bug surface. This is concrete because all four files are present and likely follow similar patterns.

• [ ] Analyze cc/aead/aes_ctr_hmac_aead_key_manager.cc/h to identify boilerplate patterns
• [ ] Compare with aes_eax_key_manager.h, aes_gcm_key_manager.h, and aes_gcm_siv_key_manager.h
• [ ] Create a new cc/aead/aes_aead_key_manager_base.h with shared template logic
• [ ] Refactor each key manager to inherit from base template, reducing lines of code
• [ ] Ensure all existing unit tests (*_key_manager_test.cc files) still pass

• Port missing unit tests from archived C++ AEAD modules to tink-cc split repo. Specific gap: cc/aead/aes_eax_key_manager.h exists but aes_eax_key_manager_test.cc in this monorepo may be incomplete; validate coverage against Wycheproof test vectors.
• Document key template selection guide. Create a doc explaining when to use AES_128_GCM vs AES_256_GCM vs CHACHA20_POLY1305 with concrete security trade-offs—none exists at repo root or in docs/ except code comments.
• Add missing language bindings for a new primitive (e.g., AEAD to Ruby or Python). The Ruby stub at 556 bytes is incomplete; extend ruby/ directory with FFI bindings to underlying C++ or write pure Ruby wrappers.

The Tink cryptography library codebase shows a well-organized structure with proper separation of concerns (parameters, keys, wrappers, serialization). However, the critical issue is that this repository is archived and no longer maintained, with development moved to github.com/tink-crypto. No obvious hardcoded secrets, injection vulnerabilities, or Docker misconfigurations are visible in the file structure provided. The main security concern is using an unmaintained version of a security library. Complete source code and dependency information were not provided for comprehensive analysis. For active development, users should migrate to the maintained repositories at github.com/tink-crypto.

• Low · Repository Maintenance Status — README.md. The repository README indicates that Tink has moved to github.com/tink-crypto and this repository is no longer active and not maintained. This is a critical concern as security patches and updates will not be provided for this codebase. Fix: Migrate to the active Tink repositories at github.com/tink-crypto. Do not use this archived version for new projects or security-critical applications.
• Low · Missing Dependency Information — Repository root / Dependencies. No package dependency file (package.json, requirements.txt, pom.xml, go.mod, etc.) was provided in the analysis. Cannot assess for known vulnerable dependencies. Fix: Provide dependency files for complete vulnerability scanning. Implement automated dependency scanning (e.g., Dependabot, Snyk) in the build pipeline.
• Low · Limited Visibility into Core Implementation — cc/aead/ and related directories. The file structure shows only header files and test files for the C++ AEAD implementation. The actual cryptographic implementation details in .cc files were not provided for analysis, limiting the ability to identify implementation-level vulnerabilities. Fix: Provide complete source code for static analysis. Ensure all cryptographic implementations undergo third-party security audits.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.