Skip to content

SYSTEM Cited by 2 sources

FBCrypto

FBCrypto is Meta's managed cryptographic library — the unified crypto implementation used by "the majority of our core infrastructure services" at Meta. Canonical wiki framing from the 2024-12-02 Meta Engineering post on cryptographic monitoring at Meta scale.

FBCrypto matters to this wiki not because of its primitives (the post is not an algorithm post) but because it is the fleet-wide crypto monoculture that makes company-wide observability of cryptographic operations possible without client-side migration: instrumentation added once inside FBCrypto provides inventory + key-overuse detection + migration-prioritisation across every service that calls it.

Role

  • Unified crypto primitive surface. AES-GCM-SIV, X25519, KDF-based derived-key features, and (per the 2024-05 post-quantum-readiness TLS post) asymmetric primitives undergoing PQC migration.
  • Host-side telemetry owner. The buffered logger that counts cryptographic events lives inside FBCrypto on each client host. No client-visible API change, no per-service migration.
  • Derived-crypto producer. Supports deriving "child" keysets from "parent" keysets via a KDF + salt — used by features that need to generate "millions of keys." See concepts/derived-key-aggregation for the logging discipline this drove.

Scale datum

  • ~0.05 % of Meta fleet CPU is spent on X25519 key exchange alone — disclosed in the 2024-12-02 post. A library this hot in the fleet CPU footprint cannot afford a per-event Scribe call; this single datum forces the buffer-and-flush telemetry architecture.
  • Millions of cryptographic operations per host per day — baseline event rate from the post.

Cryptographic monitoring integration (2024-12-02)

FBCrypto's public API is unchanged by monitoring — the buffered logger sits inside the library. On every operation:

  1. Perform the cryptographic operation (e.g. encrypt()).
  2. Increment a counter in an in-process folly::ConcurrentHashMap keyed on the event's identifying tuple ("in practice we log more fields than just key name, method, and algorithm").
  3. A background thread periodically flushes the accumulated counts through Scribe to Scuba (warm) and Hive (cold), and clears the map.

First-flush is delayed by a per-host random jitter (see patterns/jittered-flush-for-write-smoothing). On shutdown a synchronous final flush drains remaining counts — made possible by folly::Singleton's lifecycle semantics.

Use cases enabled

  • Post-quantum migration prioritisation. The dataset is the call-site inventory Meta uses to scope PQC migration work on asymmetric primitives.
  • Emergency algorithm migration. When a primitive is broken, the monitoring dataset identifies every call-site to migrate.
  • Key-overuse detection. Symmetric keys have finite data-volume budgets before security degrades; the counter dataset enables proactive rotation.
  • Library-rollout health proxy. FBCrypto emits its own version alongside events, letting Meta see in real time which fleet hosts run which library version during a rollout + correlate success rates / call volumes for bug detection.

Seen in

Last updated · 319 distilled / 1,201 read