Historical software and public mailing-list pass, 2026-10-17

Outcome: no source-backed positive recipe for the SEC131 or SEC193 starting
values was found. The useful new source evidence is the actual surviving
SECG mailing-list interface and its limited capture inventory. No unknown
seed search, mailing-list subscription, message submission, or outreach
was performed. Research used the Exa Search skill and public archive reads.

1. The 131-bit resemblance

Certicom ECC2-131 publishes seedP
b55555555554d696e67687561517586aa17bf3f4.
Its SHA-1 is 33255631db221deb61dc208ada4d88885a787969.
The documented low-131-bit result is
U_x=0x1db221deb61dc208ada4d88885a787969.
The recovered SEC starting x is instead
X=0x10134db223421eb623422888a7879682.
The visible resemblance is not an exact hash, encoding, or arithmetic
recipe. The last 16 bits already differ (0x7969 versus 0x9682), so a
direct conversion preserving the final 16-bit word cannot account for it.
The nibble-shifted suffix relation is (16*U_x-X) mod 2^32 = 14.
That is not the observed +0/+2 first-valid-x adjustment. A deliberately
edited literal remains only speculation; no source or predictive rule
was found. Pure field-isomorphism and Gaussian normal-basis tests belong
to the separate curve_followups investigation.

As an exploratory ranking, Python SequenceMatcher compared each target
with 286 public numeric fields parsed from the Certicom challenge table.
For SEC131, ECC2-131 U_x ranked first (ratio 0.615, next 0.400). For SEC193,
the largest ratio was 0.380, without a similarly conspicuous candidate.
These heuristic scores have no calibrated probability interpretation and
are not proof of reuse. They should not be promoted to a discovery claim.

Primary sources:
https://www.certicom.com/content/certicom/en/curves-list.html
https://www.certicom.com/content/dam/certicom/images/pdfs/cert_ecc_challenge.pdf

2. MIRACL source constraints

The archived 1988-1993 MRRAND.C (archive listed April 1996) implements
bigdig(n,b,x) by rejecting results shorter than n base-b digits.
The known SEC131 and SEC193 starting values have bit lengths 125 and 182.
Therefore direct bigdig(131,2,x) and bigdig(193,2,x) cannot emit these
values for any initial state. This narrow observation does not exclude
bigrand, randbits, shorter requested bit lengths, or later transforms.
The standalone check_fixed_source_facts.py replays those exact bounds
and the single published Certicom hash control.

The official MIRACL update history introduces native binary elliptic
curves at version 4.3.0. The current upstream schoof2.cpp retains a
March 2000 author header. This is chronology evidence, not proof that
all code in today's file is unchanged since that date. The archive team
has not yet verified the numeric body of the September 1999 GEC1 draft,
so this chronology alone cannot exclude MIRACL as a historical source.

Careful correction to an initial shorthand: the present schoof2 output
block repeatedly draws fresh x=rand(2^m) until GG.set(x,x) succeeds. For
an ideal curve it checks cofactor*GG != O and n*GG == O, then outputs GG
itself. It does NOT output the cofactor-multiplied temporary point. Thus
this specific output block does not directly model the recovered small
pre-cofactor starting points. No fixed seed for these SEC curves is
documented in this source.

Primary code/documents:
https://www.mirrorservice.org/sites/ftp.wiretapped.net/pub/security/cryptography/libraries/math/miracl/miracl.zip
https://github.com/miracl/MIRACL/blob/master/update.txt
https://github.com/miracl/MIRACL/blob/master/source/curve/schoof2.cpp
https://github.com/miracl/MIRACL/blob/master/docs/miracl-explained/reference-manual/advanced-arithmetic-routines.md

3. LiDIA is period-relevant but gives no newly justified fixed seed

The original February 5, 1997 LiDIA 1.3 announcement lists binary-field
arithmetic. Its 1997-dated random_generator documentation describes a
platform-dependent interface that initializes the operating-system RNG.
The later maintained source uses process/time information; it supplies
no one fixed default seed suitable for a provenance prediction.

The separately retrieved LiDIA 1.1 archive (directory dated November 6,
1995) contains a libI backend which calls timeseed() before random().
Its LIP backend's randomize(a) delegates directly to zrandomb(a).
Therefore applying a bare libc default seed would not faithfully replay
that wrapper's actual initialization, and the LIP backend is not an
independent new generator model. No additional seed range was tested.
The maintained 2.3.0-derived source must not be described as an unchanged
1997 implementation.

Sources:
http://math.albany.edu/g/Math/Comp/cas/LiDIA-feb97
https://github.com/mkoeppe/LiDIA
https://github.com/mkoeppe/LiDIA/blob/master/doc/random_generator.tex
https://github.com/mkoeppe/LiDIA/blob/master/src/base/system/random_generator.cc
https://ftp.mizar.org/pub/security/replay/crypto/LIBS/math/LiDIA-1.1.tar.gz

4. Recovered SECG public archive interface

The November 28, 1999 lists.certicom.com root lists the Security Builder
Developer's Forum and the Standards for Efficient Cryptography Group.
The April 2001 SECG topic page lists secg-talk and secg-x509. The April
29, 2001 secg-talk entry page identifies the list as Standards for
Efficient Cryptography WG and explicitly offers visiting without joining.
Its form declares list_no_search=F and list_no_archive=F. The public visit
is a POST form; no form was submitted in this investigation.

A Wayback CDX request for successful HTML captures from 1999-2001,
collapsed by URL, returned 18 URLs. A second request for all successful
captures of lists.certicom.com/*, all years and all MIME types, returned
36 unique URLs: 31 HTML pages and five images. Both limits were above
the actual returned row count. None of these URLs is a message body:
the HTML results are root, topic, entry, and administration/login pages.
This establishes the public archive interface existed but does not
recover the conversations or prove that no other mirror survives.

Saved receipts: certicom-list-cdx.json, certicom-list-all-cdx.json,
lists-root-1999.html, secg-list-topic-2001.html, secg-list-enter-2001.html.
Earlier informal messages counted the CDX header as a URL; the corrected
total is 36 captured URLs, not 37.

Exact archived pages:
https://web.archive.org/web/19991128154115id_/http://lists.certicom.com:80/
https://web.archive.org/web/20010420140627id_/http://lists.certicom.com:80/cgi-bin/lyris.pl?site=certicom&page=topic&topic=secg&text_mode=1&lang=english
https://web.archive.org/web/20010429083508id_/http://lists.certicom.com:80/cgi-bin/lyris.pl?enter=secg-talk&text_mode=1&lang=english

CDX request scope:
https://web.archive.org/cdx/search/cdx?url=lists.certicom.com/*&output=json&filter=statuscode:200&collapse=urlkey&fl=timestamp,original,mimetype&limit=500

The next evidentiary step is an independently controlled representation
conversion or an actual draft/message describing point selection.
Unexplained visual similarity and further arbitrary seed ranges do not
meet that threshold.

5. Independent normal-basis controls completed

The companion audit_normal_basis_control.py and its result file
normal-basis-independent-audit.json verify two additional facts.

First, direct polynomial long-division arithmetic gives absolute trace
zero for both SEC131 precursors X and X+2, whereas the exact published
ECC2-131 U_x bitstring has odd bit parity. Every vector in a normal basis
has absolute trace one: the sum of the conjugate basis vectors is in
GF(2), and cannot be zero because the vectors are linearly independent.
Consequently the trace of a field value equals the parity of its normal
basis coordinates. No normal basis, or permutation of its coordinates,
can map that exact U_x bitstring directly to either SEC131 precursor.
This proof does not cover edits, nonlinear processing, or a numeric
increment applied after converting the representation.

Second, an external control of the separate Gaussian-period converter
passes against five published FIPS 186-2 normal/polynomial basis pairs:
B-163 coefficient b and Gx/Gy, and K-163 Gx/Gy. At degree 163/type 4,
all five pairs require the same Frobenius exponent, 42, to align the
converter's arbitrary period root with NIST's chosen basis. The published
B-163 seed also reproduces the published normal-basis b through SHA-1
expansion. The audit uses its own polynomial squaring/remainder routine
to apply the Frobenius map. It is an external positive control, not an
exhaustive audit of every converter degree or the separate seed corpus.

Primary source: FIPS 186-2, Appendix 6, printed pages 36-37:
https://nvlpubs.nist.gov/nistpubs/Legacy/FIPS/fipspub186-2.pdf
The corresponding PDF indices in the scanned edition are 72 and 74.
