Skip to content

docs: document the +cric cryptosuite that replaced +crub in Ames and Jael - #271

Open
sigilante wants to merge 1 commit into
urbit:masterfrom
sigilante:docs/pr7-crypto-suite
Open

docs: document the +cric cryptosuite that replaced +crub in Ames and Jael#271
sigilante wants to merge 1 commit into
urbit:masterfrom
sigilante:docs/pr7-crypto-suite

Conversation

@sigilante

Copy link
Copy Markdown
Contributor

Sixth PR from the audit against urbit/urbit@08026c84b2. Cross-cutting — this one was flagged independently by two passes of the audit, in two different doc trees, which is what pushed it up the queue.

Companion PRs: #266, #267, #268, #269, #270.

What changed upstream

+cric:crypto (zuse.hoon:1489) is the suite Ames and Jael now use. Unlike +crub, which is fixed to Suite B, +cric is a door over a tagged payload and can carry either suite:

$%  [suite=%b pub=[cry=@ sgn=@ ~] sek=...]
    [suite=%c pub=[cry=@ sgn=@ tw=[ugn=@ dat=@ xtr=@]] sek=...]
==

Counted rather than assumed: sys/vane/ames.hoon contains zero references to crub and 26 to cric. Jael builds keys through +cric too (pit:nu:cric:crypto, nol:nu:cric:cryptojael.hoon:266,338,854,1260,1271,1306).

+crub still exists in zuse (:1703) and its documentation is kept — it's now labelled superseded rather than deleted, since the docs previously called it "the only cryptosuite which Ames makes use of".

One structural change worth calling out: the symmetric arms moved into a +cyf sub-core. What the docs called +en:crub:crypto is now +en:cyf:cric:crypto. All four sub-cores are documented: as, ex, nu, cyf.

Corrections that required reading the current state, not the migration code

Two things here are worth a reviewer's attention, because the obvious search gives the wrong answer.

1. Ames no longer stores a crypto core at all. The audit described Ames as wrapping _cric:crypto in an internal +acru-25 core with a legacy +acru-12 for old peers. That is true of the migration types only. The current +$ axle (lull.hoon:1601, axle-31) has no crypto-core field — it stores [saf=keypairs =ring =pass], where +$ keypairs is [pub=public-keys sek=private-keys] (lull.hoon:1069). +acru-12 (ames.hoon:817) and +acru-25 (:881) appear only inside versioned definitions like ames-state-13 and ames-state-22.

The docs now state this explicitly, so the next reader doesn't repeat the mistake. (This is the same shape of trap as the heeds field in #269.)

2. Comet self-attestation no longer signs via an acru core. +etch-open-packet (ames.hoon:423-438) signs with (sign-raw:ed:crypto - [sgn.pub sgn.sek]:saf). The documented +sign:as:crub was wrong in both suite and arm.

Not changed, having been checked

  • jael/data-types.md $point and $key-update already carry crypto-suite=@ud and match lull.hoon:4323,4327. The audit listed these as needing the field added — they did not. Only $point's prose omitted an explanation of what crypto-suite means, which is now supplied.
  • +crub:so (stdlib/4l.md) is an unrelated date-parsing arm in +so. Untouched.
  • core-academy/ca02.md quotes +crub source, but Core Academy declares itself a snapshot at Zuse 412k.

All anchor links in the touched files were verified to resolve, and this branch was test-merged against the five open companion PRs — all clean.

🤖 Generated with Claude Code

…Jael

Cross-cutting correction against urbit/docs.urbit.org@08026c84b2. Flagged independently by two
passes of the audit, in two different doc trees.

WHAT CHANGED UPSTREAM

  +cric:crypto (zuse.hoon:1489) is the suite Ames and Jael now use. Unlike
  +crub, which is fixed to Suite B, +cric is a door over a tagged payload and
  carries either suite:
    $%  [suite=%b pub=[cry=@ sgn=@ ~] sek=...]
        [suite=%c pub=[cry=@ sgn=@ tw=[ugn=@ dat=@ xtr=@]] sek=...]
    ==

  Counted rather than assumed: sys/vane/ames.hoon contains ZERO references to
  `crub` and 26 to `cric`. Jael builds keys through +cric as well
  (pit:nu:cric:crypto, nol:nu:cric:crypto -- jael.hoon:266,338,854,1260,1271,1306).

  +crub still exists in zuse (:1703) and its documentation is kept; it is now
  labelled as superseded rather than "the only cryptosuite in use".

  Structural change worth calling out: the symmetric arms moved into a +cyf
  sub-core. What the docs called `+en:crub:crypto` is now `+en:cyf:cric:crypto`
  (ames.hoon uses en:cyf: / de:cyf: / dy:cyf: throughout). Documented all four
  sub-cores: as, ex, nu, cyf.

CORRECTIONS THAT REQUIRED READING THE CURRENT STATE, NOT THE MIGRATION CODE

  The audit described Ames as wrapping _cric:crypto in an internal +acru-25
  core, with a legacy +acru-12 for old peers. That is true of the MIGRATION
  types only. The current `+$ axle` (lull.hoon:1601, axle-31) has no
  crypto-core field at all -- it stores `[saf=keypairs =ring =pass]`, where
  `+$ keypairs [pub=public-keys sek=private-keys]` (lull.hoon:1069).
  +acru-12 (ames.hoon:817) and +acru-25 (:881) appear only inside versioned
  state definitions such as ames-state-13 and ames-state-22. The docs now say
  this explicitly, so the next reader does not repeat the mistake.

  Comet self-attestation no longer signs via an acru core. +etch-open-packet
  (ames.hoon:423-438) signs with `(sign-raw:ed:crypto - [sgn.pub sgn.sek]:saf)`,
  so the documented `+sign:as:crub` was wrong in both suite and arm.

NOT CHANGED, having been checked:

  jael/data-types.md $point and $key-update ALREADY carry `crypto-suite=@ud`
  and match lull.hoon:4323,4327. The audit listed these as needing the field
  added; they did not. Only $point's prose omitted an explanation of what
  crypto-suite means, which is now supplied.

  `+crub:so` (stdlib/4l.md) is an unrelated date-parsing arm and is untouched.

  core-academy/ca02.md quotes +crub source, but Core Academy declares itself a
  snapshot at Zuse 412k.

All anchor links in the touched files were verified to resolve.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant