feat(zk): add ElGamal & AES key derivation - #413
Conversation
|
Hey @sonicfromnewyoke seems a small conflict. Should it be retargeted to the v2 branch? If so, rebase on v2 pls:) |
4a5fd47 to
cbda857
Compare
|
|
||
| // AeKeyFromSignature derives an AeKey from an ed25519 signature by using | ||
| // SHA3-512(signature) as the seed. Mirrors AeKey::seed_from_signature + | ||
| // from_seed in solana-zk-sdk. No default-signature check is performed here; |
There was a problem hiding this comment.
shall we add a check for default-signature or add a // SECURITY: warning?
|
Code quality and doc are excellent! @sonicfromnewyoke it would be great to consider add an example under programs/token-2022/zkencryption/examples/ Let's merge it to v2 after reviewed & merged all current PRs in main:) |
done 🫡 |
Greptile SummaryThis PR adds a new
Confidence Score: 5/5Safe to merge; the KDF logic is correct and byte-for-byte verified against Rust reference vectors across all derivation paths. The core cryptographic derivation — SHA3-512 hashing, edwards25519 wide-reduction via SetUniformBytes, double-hash for the signature paths, and BIP39 PBKDF2 — all match the Rust solana-zk-sdk contract and are confirmed by the cross-SDK test vectors. Seed-bound checks, domain-separation prefixes, and default-signature rejection are all present and tested. The only open item is that the unreachable SetUniformBytes error path drops the original library error rather than wrapping it, but this does not affect correctness. No files require special attention. Important Files Changed
Flowchart%%{init: {'theme': 'neutral'}}%%
flowchart TD
A([Signer + publicSeed]) -->|Sign domain+seed| B[ed25519 signature 64 bytes]
B -->|reject if all-zero| C{Default sig?}
C -->|yes| ERR[ErrDefaultSignature]
C -->|no| D[SHA3-512 signature]
E([Raw signature 64 bytes]) --> D2[SHA3-512 signature]
F([BIP39 mnemonic + passphrase]) -->|PBKDF2-HMAC-SHA512| G[64-byte seed]
H([Raw seed bytes]) --> BOUNDS{Length bounds check min/max}
BOUNDS -->|too short / too long| ERR2[ErrSeedTooShort / ErrSeedTooLong]
BOUNDS -->|ok| HASH[SHA3-512 seed]
D --> BOUNDS
D2 --> BOUNDS
G --> BOUNDS
HASH -->|first 16 bytes| AE[AeKey 16 bytes]
HASH -->|SetUniformBytes wide-reduction| EL[ElGamalSecretKey 32-byte scalar mod l]
Reviews (2): Last reviewed commit: "test: add elgamal too long case" | Re-trigger Greptile |
8a9c84f to
9ce7456
Compare
Problem
solana-gohas no Token-2022 confidential-transfer key-derivation support #412. Rust solana-zk-sdk and JS@solana/zk-sdkship deterministic KDFs that turn a Solana signer + public seed into an ElGamal secret scalar and an AES-128-GCM-SIV key;Go users currently have to call into Rust or JS/WASM just to produce the key material a confidential transfer needs.
First step of the port is the KDF itself, byte-for-byte compatible with the reference SDKs.
Summary of Changes
solana.PrivateKeysatisfies it; hardware wallets and remote signers can plug in without changes.related to #412