ogar-encryption: the single generic encryption surface for all Ada consumers#190
Open
AdaWorldAPI wants to merge 5 commits into
Open
ogar-encryption: the single generic encryption surface for all Ada consumers#190AdaWorldAPI wants to merge 5 commits into
AdaWorldAPI wants to merge 5 commits into
Conversation
…nsumers The forward crypto suite (Argon2id KDF, XChaCha20-Poly1305 AEAD, Ed25519, SHA-384, the wasm-capable seal/open envelope) was re-exported through ogar-auth from the ndarray `encryption` crate. Split it into its own crate so consumers that need RAW crypto (seal client-side, verify a licence sig, hash for merkle) pull ONE classid-agnostic crate — not the ndarray fork directly and never a hand-rolled argon2/chacha/ed25519 copy. - crates/ogar-encryption: thin, `#![forbid(unsafe_code)]` re-export of the encryption crate's kdf/aead/hash/sign/envelope (+ seal/open/EnvelopeError/ KdfParams/RngError root aliases); `wasm` feature forwards to encryption/wasm-bindings for browser (client-side envelope::seal) consumers. Implements nothing — a re-export crate cannot dilute the audited suite. - ogar-auth now deps ogar-encryption (path) instead of the ndarray git dep for the forward suite; its password/totp/legacy modules + public API (ogar_auth::kdf/aead/hash/sign/envelope) are unchanged, now resolved through ogar-encryption. This is the "globally reusable" structural half; the ndarray::simd::chacha20_block hardware-accel primitive (ndarray 7923c177) is the acceleration the encryption crate's AEAD hot path adopts next.
Captures the cross-repo reusability audit: the one crypto+SIMD spine (ndarray::simd::chacha20_block <- encryption <- ogar-encryption <- ogar-auth; lance-graph-rbac as ogar-rbac), the three migration tiers (Tier 1 byte-compatible password/totp drop-ins; Tier 2 data-compat AES-GCM/3DES/vault rekeys; Tier 3 keep-local content hashing + the JWT-session surface gap), the RBAC status per consumer, and the blockers to confirm (woa-rs BBB allowlist ruling for the OGAR namespace; Sharepoint-rs missing Cargo.tomls). Durable record so the migration is trackable across sessions.
Bugbot couldn't run - usage limit reachedBugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit. A user or team admin can review and increase usage limits in the Cursor dashboard. (requestId: serverGenReqId_1ee2a9d8-95cd-4103-a79b-a0fc893d9b7a) |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: c9eb501195
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| # Forward to the ndarray crate's wasm bindings, so browser consumers (e.g. a | ||
| # hub-client-style SPA that wants client-side `envelope::seal` before secrets | ||
| # ever reach a server) get the wasm-bindgen surface through this crate too. | ||
| wasm = ["encryption/wasm-bindings"] |
There was a problem hiding this comment.
When using the new wasm feature to build/package ogar-encryption directly for browser consumers, this manifest still has Cargo's default crate type (cargo metadata --no-deps reports crate_types: ["lib"]), so the documented cargo build -p ogar-encryption --target wasm32-unknown-unknown --features wasm produces only an rlib and wasm-pack/wasm-bindgen have no cdylib to package. The upstream encryption crate sets crate-type = ["rlib", "cdylib"] for these bindings; this wrapper needs the same [lib] crate type or the promised browser-facing ogar-encryption wasm surface is unusable.
Useful? React with 👍 / 👎.
…uling The ndarray ChaCha20 keystream (scalar + AVX-512 + wasm128) is complete and byte-parity-proven vs RustCrypto — sequencing step updated to DONE. Record the security ruling: the encryption XChaCha20-Poly1305 AEAD is NOT re-wired to the primitive (that would mean hand-composing HChaCha20 + Poly1305 = the roll-your-own-AEAD footgun the stack forbids); the primitive is for raw- stream use sites with a caller-owned MAC. Flags the open operator decision (add optional ndarray dep to the lean encryption crate?) and advances the sequence to the Tier-1 password/totp consumer migrations. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…cision
Byte-compatibility of medcare-core::{crypto,totp} vs ogar-auth confirmed by
source read (Argon2::default() PHC parity; RFC 6238 TOTP verbatim parity).
Record the exact body-only delegation recipe (zero caller changes) so it is
cheap to execute once green-lit, and flag the operator decision that gates
it: ogar-auth pulls `encryption` via git into a workspace that vendors
ndarray locally — accept the git pull, or repoint ogar-encryption at the
local path first (fork-policy-consistent). Staged, not shipped, pending that
call — not forcing a heavy cross-repo dep + build under the disk budget.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…ar-auth) medcare-core now delegates crypto password + the totp module to ogar-auth (medcare-rs 6d2c372): 56/56 tests green through the delegated path incl. RFC 6238 Appendix-B vectors, all medcare crates compile. Dep-wiring resolved as option (b) — a root [patch] folds ogar-encryption's git `encryption` onto the locally-vendored fork copy (one source, no git fetch). ogar-auth is now a live, working consumer dependency, not just a documented surface. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Makes the Ada crypto surface globally reusable by splitting the forward suite into its own generic crate.
ogar-encryption(new) — OGAR's single, classid-agnostic encryption surface: a thin#![forbid(unsafe_code)]re-export of the ndarrayencryptioncrate (Argon2id KDF, XChaCha20-Poly1305 AEAD, Ed25519, SHA-384, the wasm-capable seal/open envelope). Every Ada consumer that needs raw crypto pulls THIS crate — not the ndarray fork directly, and never a hand-rolled argon2/chacha/ed25519 copy. Implements nothing (a re-export crate cannot dilute the audited suite); awasmfeature forwards toencryption/wasm-bindingsfor browser (client-sideenvelope::seal) consumers.ogar-auth— now depends onogar-encryption(path) instead of the ndarray git dep for the forward suite; itspassword/totp/legacymodules and public API (ogar_auth::kdf/aead/hash/sign/envelope) are unchanged, now resolved throughogar-encryption.docs/OGAR-CRYPTO-CONSUMER-MIGRATION.md— the cross-repo reusability map: the one crypto+SIMD spine (ndarray::simd::chacha20_block←encryption←ogar-encryption←ogar-auth;lance-graph-rbacas theogar-rbacrole), the three migration tiers (Tier-1 byte-compatible password/totp drop-ins for MedCare/woa/openproject; Tier-2 data-compat AES-GCM/3DES/vault rekeys; Tier-3 keep-local content hashing + the JWT-session gap), and the blockers to confirm (woa-rs BBB allowlist ruling for the OGAR namespace; Sharepoint-rs missing Cargo.tomls).Pairs with ndarray #240 (
ndarray::simd::chacha20_block, the ARX hardware-accel primitive theencryptionAEAD adopts next).Test Plan
ogar-encryptionimplements nothing — it re-exports the (already-tested)encryptioncrate; the Sonnet author verified every re-exported module name againstencryption/src/lib.rs.ogar-authpublic API preserved (re-export chainogar-auth → ogar-encryption → encryption); its ownpassword/totp/legacytests are unchanged.encryptiongit dep resolves there); no crypto logic changed.