Replace vetkd skill with a new vetkeys covering BLS, IBE, and timelock. - #162
Replace vetkd skill with a new vetkeys covering BLS, IBE, and timelock.#162andreacerulli wants to merge 1 commit into
Conversation
The old vetkd skill was too low-level and complex. The new vetkeys skill covers three practical primitives: BLS threshold signatures, identity-based encryption (IBE), and timelock encryption with compile-tested code examples.
Skill Validation ReportValidating skill: /home/runner/work/icskills/icskills/skills/vetkeysStructure
Frontmatter
Markdown
Tokens
Content Analysis
Contamination Analysis
Result: passed Project Checks |
| "@dfinity/agent": "^3.4.0", | ||
| "@dfinity/principal": "^3.4.0", |
There was a problem hiding this comment.
is there a reason we cannot use the new core library? can we make a new release for the vetkeys lib if it still relies on old dependencies?
There was a problem hiding this comment.
Yeah, I think is only because of the vetkeys library. I can look into it.
Review: vetkeys skillGreat direction — replacing the old DescriptionRemove "verifiable randomness (VRF)" from the description. The skill has no VRF content, so an agent routed here for VRF finds nothing actionable. Add it back only if a VRF section is included. Cycle costs — precise numbers + missing pitfallThe Key Concepts section uses
The local PocketIC deviation should be a dedicated pitfall, not buried in Key Concepts. This is the exact error that caused issue #156. Recommending IBE backend — missing types"The canister structure is the same as the BLS example" leaves an agent unable to compile. Missing: IBE frontend —
|
## Summary Replaces the outdated `vetkd` skill with **two** skills split by abstraction level, updated to the current vetKeys libraries and verified end-to-end. - **`vetkeys`** — the vetKD management API plus advanced primitives: symmetric key derivation, IBE, timelock encryption, threshold BLS signatures, offline public-key derivation, and VRF. Feature depth lives in `references/ibe.md` and `references/bls-signing.md`. - **`encrypted-maps`** — high-level, access-controlled encrypted key-value storage (the default for password managers / encrypted notes): the Rust `export_encrypted_maps_canister!` macro, the Motoko `EncryptedMapsCanister` mixin, the TS `EncryptedMaps` client, a short `KeyManager` section, and the metadata / custom-value-endpoint variant in `references/metadata.md`. Each skill's description routes to the other, so agents land on the right one (bidirectional routing verified in the trigger evals). ## Why replace `vetkd`? The shipped `vetkd` skill was inaccurate against the current libraries. It used the renamed `@dfinity/vetkeys` (frozen at 0.4), told Motoko developers to hand-roll the management canister (a full Motoko `ic-vetkeys` library now exists), pinned Rust `ic-vetkeys` 0.6 (now 0.9), used the deprecated `ic-cdk` call API, referenced a non-existent `toDerivedKeyMaterial()`, and misstated cycle costs. ## What's corrected - `@icp-sdk/vetkeys` 0.5 (renamed from `@dfinity/vetkeys`); frontend agent/identity from `@icp-sdk/core`, not `@dfinity/agent` - Rust `ic-vetkeys` 0.9 + `ic-cdk` 0.20 + `ic-cdk-management-canister`; Motoko `ic-vetkeys` 0.6 (moc 1.13 / core 2.6.1) - Library management helpers (`ic-cdk-management-canister`, `mo:ic-vetkeys/ManagementCanister`) instead of hand-rolled Candid + `actor "aaaaa-aa"` - `VetKey.asDerivedKeyMaterial()` → `encryptMessage`/`decryptMessage` (the old skill's `toDerivedKeyMaterial()` does not exist) - Correct cycle costs — `test_key_1` and `key_1` behave the same locally and on mainnet; helpers attach the amount - `verifyBlsSignature(DerivedPublicKey, …)`, `persistent actor` (compiles with or without `--default-persistent-actors`), and the Motoko-has-no-frontend-crypto asymmetry documented ## Verification Every code block is derived from the canonical `dfinity/examples` sources (Rust `master`, Motoko from dfinity/examples#1475, frontends `master`) and the library source. All Motoko snippets compiled verbatim on `moc 1.13.0` / `ic-vetkeys 0.6.0` / `core 2.6.1`, in both mops configurations (bare and `--default-persistent-actors`). Cycle costs were measured on a local replica. `npm run validate` passes for both skills. ## Honoring prior contributions This supersedes and builds on prior community work — thank you both: - **@andreacerulli** — the `vetkeys` / `encrypted-maps` split and the BLS / IBE / timelock scoping (#162, #158) - **@raymondk** — the accuracy review and eval seed (#272, #285, #286, #308) Closes #73, #272, #285, #286. Supersedes #158, #162, #308. ## Evals <details> <summary>Output evals — all cases pass with the skill; strong with-skill vs baseline deltas</summary> **vetkeys** | Case | WITH skill | WITHOUT (baseline) | |---|---|---| | ibe_encrypt_to_principal | 4/4 | 2/4 | | symmetric_key_material_api | 3/3 | 1/3 | | motoko_has_no_low_level_primitives | 4/4 | 0/4 | | cycle_cost_and_helpers | 3/3 | 0/3 | | bls_verify_uses_derived_public_key | 3/3 | 0/3 | **encrypted-maps** | Case | WITH skill | WITHOUT (baseline) | |---|---|---| | scaffold_backend_with_macro | 4/4 | 1/4 | | share_map_access_rights_variant | 2/2 | 0/2 | | scaffold_motoko_backend_mixin | 5/5 | 0/5 | | derived_key_material_caching | 3/3 | 1/3 | </details> <details> <summary>Trigger evals — 100% on both skills, including bidirectional routing</summary> - **vetkeys** — should_trigger 4/4, should_not_trigger 2/2 (declines the password-manager query → routes to `encrypted-maps`) - **encrypted-maps** — should_trigger 3/3, should_not_trigger 2/2 (declines the IBE / BLS queries → routes to `vetkeys`) </details> 🤖 Generated with [Claude Code](https://claude.com/claude-code)
The original vetkd skill was overly low-level and unnecessarily complex. In contrast, the new vetkeys skill focuses on three practical, high-impact primitives: BLS threshold signatures, identity-based encryption (IBE), and timelock encryption.
I evaluated the skill by building example dApps for all three primitives, and the results seemed reasonable. I also compared the experience of developing a Random Beacon dApp with and without the skill. Using the skill produced a more advanced implementation with noticeably less effort. Without it, development took significantly longer, the architecture was more cumbersome, and the end result felt comparatively basic.