# google/keytransparency

A transparent and secure way to look up public keys.

Repository: https://github.com/google/keytransparency
Canonical: https://ross.abutalabs.com/products/keytransparency
Homepage: https://security.googleblog.com/2017/01/security-through-transparency.html
Language: Go
License: Apache-2.0
License Family: permissive
Topics: public-keys, verifiable-data-structures, block-chain, key-management, merkletree, secure-by-default, verifiable-random-function, vrf, coniks
Archived: true
Last push: 2021-07-05T06:39:36+00:00

## Health v2 (maintenance only)
Score: 10/100 (v2, computed 2026-09-03T02:20:16.233290+00:00)
- activity 0, release rhythm 8, longevity 100
- inputs: {"age_days": 4103, "days_push": 1885, "days_rel": null, "gap_med": null, "n_releases_24m": 0}
- flags: archived
- formula: round(0.45*activity + 0.35*rhythm + 0.20*longevity); archived -> min(score, 10)

## Adoption (not part of the score)
Stars 1569, forks 157 (observed 2026-08-28T04:05:05.247368+00:00)

## What it is
A Google open-source key transparency service that provides a lookup service for public keys backed by a publicly auditable, tamper-proof log of all record changes. It uses verifiable data structures like Merkle trees and verifiable random functions to let users authenticate public keys while keeping the service accountable.

## Use cases
- look up public keys for a user securely
- verify what public keys are associated with my account
- run a public key discovery service for end-to-end encryption
- audit changes to user key records tamper-proofly
- authenticate users before trusting their encryption keys
- check how long an account's keys have been stable
- add verifiable auditing to U2F security key registration

## When to choose
- you need a publicly auditable public key directory for E2E encrypted messaging
- you want users to verify which keys are bound to their accounts
- you need transparency-log-backed key discovery similar to CONIKS
- you want verifiable data structures (Merkle trees, VRFs) for key lookups

## When to avoid
- you need a production-ready, actively maintained deployment - the project is a work-in-progress with the last release in 2021
- you just need simple key storage without transparency or auditing guarantees
- you are not working in Go or with gRPC/HTTPS-based services

## Facets
- artifact type: service
- maturity: experimental
- function: auth, security, cryptography, search-engine, api-framework, http-server, rpc
- domain: security, privacy, developer-tools, backend, apis
- platform: go, self-hosted, cross-platform
- tags: key-transparency, public-key-discovery, merkle-tree, verifiable-random-function, vrf, coniks, audit-log, end-to-end-encryption, key-management, tamper-proof, linux, macos, docker

## Member repositories
- google/keytransparency (main) score 10

## Provenance
- Observed fields: from GitHub, fetched 2026-08-28T04:05:05.247368+00:00.
- Health v2: computed from the inputs above; adoption is never an input.
- Inferred fields (summary, facets, guidance): AI-extracted, prompt v1, taxonomy v1, on 2026-08-30T03:58:52.991186+00:00, confidence not recorded.
  - readme: https://github.com/google/keytransparency (fetched 2026-08-28T04:05:05.247368+00:00, sha 80f4bd995afe)
  - homepage: https://security.googleblog.com/2017/01/security-through-transparency.html (fetched 2026-08-29T11:28:16.810162+00:00, sha 12cd8dd52e43)
- Data as of 2026-08-30T08:39:29.467469+00:00.