paulmillr/noble-ed25519

const hashes = {
  sha512Async: async (message: TArg<Uint8Array>): Promise<TRet<Uint8Array>> => {
  sha512: undefined as undefined | ((message: TArg<Uint8Array>) => TRet<Uint8Array>),

etc and utils are frozen, but the exported hashes object is not. It is one object shared by every importer in the process, so any module, including a transitive dependency, can replace sha512 or sha512Async. That changes how every other consumer signs and verifies. The wrapper only checks that the output is 64 bytes, not that it is a correct SHA-512 digest, so a wrong or malicious provider would make signatures silently invalid or non-standard. The slot is configurable on purpose, so this is a hardening note, not a demonstrated defect.

State clearly in the docs that the slots are process-global, and that only the application entry point should assign them, never library code. You could also accept an optional per-call hash provider, or let sha512 be set only once and refuse later reassignment.

static fromAffine(p: AffinePoint): Point {
  return new Point(p.x, p.y, 1n, modP(p.x * p.y));

A Point is meaningful only if (X, Y, Z) is on the curve and T·Z = X·Y. The public constructor and Point.fromAffine only check that each coordinate is in range, as the comment at index.ts:267-268 says. add() relies on T, while equals() ignores it. A point built from arbitrary coordinates therefore produces wrong results without any error unless the caller remembers assertValidity(). The library's own entry points decode points through fromBytes, which is safe. The risk only reaches callers who build points directly, so it is LOW.

Make fromAffine call .assertValidity() on the result. Alternatively, document prominently that points built from untrusted coordinates must be validated, and steer callers to fromBytes/fromHex.

await mark('signAsync', () => curve.signAsync(msg, keys.secretKey));
await mark('verifyAsync', () => curve.verifyAsync(sig, msg, keys.publicKey));

Server-side users mostly call the async API many times at once. A sequential benchmark shows neither throughput under concurrency nor tail latency (p99 and above).

Optionally add a concurrent scenario for the async paths, such as N parallel promise chains of M operations each, and report total time plus latency percentiles.

static fromHex(hex: string, zip215?: boolean): Point {
  return Point.fromBytes(hexToBytes(hex), zip215);

hexToBytes runs a regex over the whole string, allocates a buffer and loops over every byte before fromBytes enforces the 32-byte point width. An attacker-supplied hex string of arbitrary size costs work in proportion to its length before it is rejected. The work is linear, so the impact is small. It is still the one decode path that does no cheap size check first, unlike the signature and public-key inputs.

In fromHex, reject any string whose length is not 64 before calling hexToBytes.

let Gpows: Point[] | undefined = undefined; // shared process-wide cache of base-point precomputes

One file holds the byte/hex helpers, field arithmetic, the Point class, the hash-provider slots, the base-point precompute with its own mutable module cache, the sign/verify API and about 110 lines of TypeScript compatibility types. That makes changes harder to review in isolation. The single-file "5KB" design is a stated product goal, so this is a maintenance note, not a defect.

If the single-file layout is not a hard requirement, split the file along its existing section markers. Otherwise, record the single-file decision as intentional, for example in the README or a contributing note, so reviewers do not revisit it.

import * as ed from '../index.ts';

uses: paulmillr/jsbt/.github/workflows/release.yml@84f47b72e990ae11999fbe06c3efa449e943de60

All test files import the TypeScript source ../index.ts. npm consumers receive the compiled index.js and index.d.ts produced by tsc (package.json "files", "main": "index.js"). The release job delegates to an external reusable workflow whose steps cannot be seen in this repository. Nothing shown here proves that the artifact users install passes the test vectors. A build-configuration change, a compiler upgrade or a packaging mistake could ship a broken or different artifact while every test still passes.

Add a post-build check that runs npm pack, installs the tarball in a clean directory, imports it by package name, and runs a sign/verify round trip plus a sample of the vectors. Run it in CI, and make the release job depend on it.