AES Key Wrap

Key wrap is the cryptography equivalent of nesting dolls: you take a key, encrypt it with another key, and hand the wrapped result to someone who can only open it with the right unwrapping key. It's how real systems ship encryption keys between machines without ever exposing them in plaintext, and it's what this node does - RFC 3394 AES Key Wrap, the standard from NIST's toolkit. In ComfyUI terms, this is the node you reach for when you want to encrypt a key (say, an AES key for a message) rather than a message, which is a different operation with a different tool.

The mechanism is worth understanding because it's why the inputs look the way they do. Key wrap uses a 64-bit block cipher in a specific mode: it processes the key in 8-byte blocks and bakes an integrity check into the last block. The practical upshot - and the "gotcha" - is that RFC 3394 only wraps keys whose length is a multiple of 8 bytes (64 bits). A 16, 24, or 32-byte AES key wraps fine. An odd 21-byte blob doesn't, because the standard's block size won't divide it evenly.

The inputs and outputs

• wrapping_key (BYTESLIKE) - the key doing the encrypting. This is the one you guard.
• secondary_key (BYTESLIKE) - the key being wrapped. The tooltip says it plainly: for wrapping, this is the key to wrap; for unwrapping, this is the wrapped key. So it's input-or-output depending on direction, and the node's single input slot has to serve both.
• mode - the wrap/unwrap toggle (labeled "Wrap" on / "Unwrap" off).

Output is wrapped_key (BYTESLIKE). Both keys and the result are BYTESLIKE, so everything upstream and downstream should come from the pack's keygen nodes, ByteslikeEncode, or ByteslikeDecode - not from typing text.

Where people get burned

The 8-byte multiple rule is the classic failure. Try to wrap a 21-byte key and the cryptography backend throws an error about the data length. It's not a bug - that's the standard being honest about its block size. If you need to wrap arbitrary-length keys (including, say, a random secret that isn't a clean multiple of 8), that's exactly what the pack's other wrapper, AESKeyWrapWithPadding, is for: it applies the RFC 5649 padding variant and drops the constraint. Short version: clean 16/24/32-byte AES keys → this node; anything else → the padded one.

A second trap is direction confusion. The tooltip's phrasing ("for wrapping this is X, for unwrapping this is Y") is a hint that people flip the inputs by accident. The unwrap operation takes the wrapped key as the secondary input and your wrapping key as the primary - swap them and you get a decrypt error, not a helpful message.

Installing it

This node ships in the ARG Toolkit pack, so install the pack once:

cd ComfyUI/custom_nodes
git clone https://github.com/AzelusLightvale/ComfyUI-ARG-Toolkit

Restart ComfyUI and look under ARG Toolkit → Cryptography → Modern → Key Wrap. ComfyUI Manager (search "ComfyUI ARG Toolkit") does the same thing with a click. The dependency is cryptography - pinned in the pack's requirements.txt, usually already present in your ComfyUI Python environment. Nothing heavy, no models.

Troubleshooting

• Length error on wrap → your key isn't a multiple of 8 bytes. Switch to AESKeyWrapWithPadding.
• Decrypt/unwrap error → check input order; wrapping_key and secondary_key are easy to swap.
• Won't connect → BYTESLIKE everywhere. Run your strings through ByteslikeEncode first.

Key wrap is a niche tool, and honestly, most ARG puzzle-building won't need it - you usually encrypt messages, not keys. But the moment you're hiding multiple secrets and want to lock them under one master key, this is the standard way to do it, and now it's a node in your graph instead of a five-line Python script.