AIGC BYOK 密钥解密

The problem it solves

BYOK means "bring your own key", and API-wrapper nodes want a credential pasted into a text field - same breed as every Runware or fal wrapper that phones out instead of sampling locally. The wrinkle here is that this platform hands users an encrypted key: a Base64 blob from a Java service, not an sk-... string. If every node in the pack decrypted that blob itself, you'd maintain the same crypto in a dozen places.

AigcByokDecrypt (display name AIGC BYOK 密钥解密) is the single point of decryption. Feed it the ciphertext, get a plaintext API key on one STRING output, and wire that into the api_key / auth_token inputs of whatever else in the graph needs to authenticate. It's the primitive-node pattern from the plumbing layer - one authoritative source fanning out to many consumers (see comfyui-node-plumbing.md) - applied to a secret instead of a seed.

How the decryption actually works

Read the source (module/byok_crypto.py), not the README, because the README has nothing to say about this node. The payload format is:

Base64( 12-byte IV || AES-256-GCM ciphertext || 16-byte auth tag )

That's the layout the Java AigcEncryptedAkCodec on the other end produces, and the node's docstring says compatibility with it is the point. The key is 32 bytes, written as 64 hex characters, read in order from the encryption_key field, then the AIGC_BYOK_ENCRYPTION_KEY environment variable, then a default committed in nodes_byok.py.

Two consequences worth internalising. GCM is authenticated, so a wrong key doesn't return garbage - it throws InvalidTag, which is why the error says "authentication failed" rather than "bad base64". And because that default key sits in a public repo, the default configuration is obfuscation, not security: anyone holding your workflow JSON can decrypt it. If the ciphertext is meant to protect anything, set your own key.

The inputs that matter

encryptedAk (required, STRING) - the ciphertext or a plaintext ak. Not a typo: the author's tooltip says plaintext passes through untouched in auto mode.

ak_mode (optional enum, default auto) - the one you'll actually touch. auto sniffs the input shape and only attempts decryption if it looks like ciphertext; plaintext never decrypts; encrypted forces decryption and hard-errors on any problem, which makes it the mode to use when a key is misconfigured somewhere and you want the failure to be loud.

encryption_key (optional STRING) - leave it alone on a single-user box, and see the gotchas below before relying on the env var.

The output is a single STRING named api_key. Wire it into api_key on 图片翻译 API or ADIC Common API, into auth_token on ADIC OpenAIGPTImage1 or 批量套版. The pack isn't consistent about what it calls the same credential, which is exactly the argument for decrypting once here. Note OUTPUT_NODE = False, so this does nothing at all until something downstream pulls on api_key.

Install

ComfyUI Manager → search ComfyUI-ADIC → Install, or:

cd /path/to/ComfyUI/custom_nodes
git clone https://github.com/jinchanz/ComfyUI-ADIC

Then restart ComfyUI. No model downloads, nothing heavy. But you need the crypto library, and the README won't tell you:

pip install cryptography requests

The import is wrapped in a try/except, so a missing cryptography still lets the pack load - it just prints [BYOK] 警告: cryptography 库未安装 at startup and fails the moment you try to decrypt. Install it into the same Python ComfyUI runs on, and restart.

Where people get burned

The env var does nothing until you empty the field. The fallback chain is field → env var → built-in default, and the field defaults to the built-in key. So setting AIGC_BYOK_ENCRYPTION_KEY while leaving the widget alone changes nothing. Clear the field, then let the env var win. And remember the tooltip's warning: whatever the field holds gets written into the workflow JSON.

Sharing a workflow can leak your key. Workflow JSON gets embedded in output PNGs by default (see comfyui-ecosystem.md), so a saved image carries whatever the field held. Leave encryption_key empty and put the key in the environment if the workflow travels at all.

auto mode fails quietly, on purpose. If the payload looks like Base64 but doesn't authenticate, the node logs a warning and passes the ciphertext through as if it were a plaintext key - downstream you get a 401 with a Bearer token that looks like a random string. Switch ak_mode to encrypted while debugging, get the real error, then switch back.

encryptedAk authentication failed almost always means the shared key is wrong or the payload came from a different environment. Check it's 64 hex characters (must be 64 hex characters is a separate, clearer error) and that you're not mixing prod and staging blobs.

One thing in the node's favour: the source is explicit that it never logs the ak, the shared key, or the decrypted plaintext - a modest point in a category where credential-handling nodes deserve suspicion by default, but the right one.