Where is P-256 actually used? From Anthropic's research to runtime evidence

A cryptography article names a curve your software might use. Can you identify the application, the library and the operation that depend on it?

That was the question we explored after Anthropic published its research on the origins of ECDSA curve seeds. We reproduced the public P-256 seed, then used Laviq to follow P-256 usage in a running OpenSSL service: from an observed public key to the signing operation, process and implementation behind it.

The useful result is a concrete answer to who uses this cryptography, and where?

What Anthropic found

In Claude reveals ECDSA curve origins, published on October 16, 2026, Anthropic described how Claude reconstructed the generation of several published elliptic-curve seeds. The recipe used the C library’s lrand48 generator initialized with a Unix timestamp.

For P-256, the published seed is candidate 1,842 from a run initialized at 1997-08-16 01:52:34 UTC:

C49D360886E704936A6678E1139D26B7819F7E90

These are public values used to define a curve. Anthropic explicitly states that the result is not a cryptographic break or a new attack, and does not require changes to deployed systems. Its contribution is a reproducible explanation of the parameters’ provenance. Some questions, including the origin of P-256’s base point, remain open. Read the research and reproduction code.

From a published curve to a running application

We started by running a small reproduction of the P-256 seed recipe. It matched the published seed exactly. Changing the candidate number or timestamp failed the match, as expected.

That establishes the connection to the research. The next step asks an operational question: where is that same curve being used by software today?

For this controlled demonstration, we built a small C HTTP service using OpenSSL on an AWS Linux instance. It generates P-256 keys and performs ECDSA signing. The service uses OpenSSL’s normal key generation; the historical seed recipe is only used in the separate public-parameter reproduction.

Laviq observes the native signing path. For the qualified OpenSSL implementation exercised here, it collects a public-key fingerprint and binds that identity to the actual key object used by the signing operation.

The fixture also prints public fingerprints for validation. Those outputs are ground truth for the test, not the source of the Agent’s evidence.

Start with the public key, then follow Relationships

The walkthrough starts in Evidence with a public-key observation labeled ECDSA / secp256r1. Here, secp256r1 names the P-256 curve.

The fingerprint is SHA-256 over the public key’s canonical DER-encoded SubjectPublicKeyInfo, labeled spki_der_sha256. The curve name tells us which parameters the operation uses; the fingerprint identifies the specific public key.

From there, Relationships exposes the supporting evidence:

Question	Evidence in the demonstration
Which curve is in use?	The observed public key has parameter set secp256r1, or P-256.
Which operation used the key?	A qualified native ECDSA_sign observation is bound to the key identity.
Which program performed it?	The observed process is p256_http_demo.
Which implementation executed it?	The graph identifies libcrypto.so.3, with implementation identity retained in the evidence.
Which handler enclosed the signing call?	An explicitly instrumented native handler activation, where the collection supports that link.

This gives an engineer a path from a curve named in research to a specific workload and implementation. A library inventory alone would leave the actual signing operation and key identity unanswered.

Why the request link needs direct evidence

To demonstrate request context, we added explicit native markers around the service’s synchronous HTTP handler. The Agent uses the handler’s observed entry and return, the signing invocation, and matching process generation and thread identity to establish containment.

It does not assign a request merely because a signing event happened nearby in time or in the same process.

The proof run included two overlapping signing requests on different threads, each using a distinct key. It also included a health request that performed no signing and a signing operation outside any request handler.

The retained result was specific:

• Two signing handlers had supported links to their signing operations and public keys.
• The outside-handler signing operation retained its key identity without acquiring a request link.
• The health request acquired no signing association.
• The same request-binding metadata survived ingest and exact backend readback; the graph returned two request nodes with the corresponding key links.

The UI labels this as instrumented handler evidence. The HTTP method, numeric route tag and socket descriptor are handler declarations. An independent network connection identity was not collected; the graph preserves that limitation.

Watch the recorded walkthrough

This 40-second screen recording shows the article, service code, public-key evidence and Relationships graph. Captions explain each step. It is footage of the controlled demonstration, not a general coverage or performance benchmark.

The video includes visible English captions. The optional caption track provides the same text.

What this demonstrates, and what remains unknown

The Agent captured the public-key identity and operation evidence; the platform persisted it and returned the supported relationships. The recording shows those records in the UI. Collection is limited to the qualified implementation and instrumentation exercised in this test. Unsupported implementations remain unqualified.

We did not demonstrate private-key recovery, an ECDSA vulnerability, automatic detection of weak randomness, or whole-application coverage. No private-key material was collected. The native handler markers are an explicit addition to this demo service; the result does not establish passive HTTP correlation across arbitrary applications.

The scenario deliberately pauses inside handlers to create overlap. Its timings should not be used as signing benchmarks. Focused tests and runtime/readback checks passed; full-suite qualification remains outstanding.

Use research to ask a better inventory question

When a paper, standard or migration requirement names an algorithm or curve, start with one representative workload. Establish the exact curve, capture an actual operation, identify the key and implementation where supported, and retain the scan and event references behind the result.

That evidence helps a team choose which application path to investigate or test next. It also keeps the conclusion scoped to what was exercised.

For this demonstration, the conclusion is straightforward: this process used this OpenSSL implementation to sign with this P-256 key, with handler context supported by explicit instrumentation.

Bring a representative Linux workload to a Laviq assessment.