AES Key Wrap With Padding

AESKeyWrapWithPadding is the fix for the one genuinely annoying limitation of the plain AES Key Wrap node. RFC 3394, the original key wrap standard, only works on keys whose length is a multiple of 8 bytes - fine for a 16 or 32-byte AES key, useless for a 20-byte token you'd like to lock up. This node implements the RFC 5649 variant, which adds padding and an alternative initial value to the wrap, so it can wrap keys of any length. That's the entire difference, and it's the reason you'd pick this node over its sibling in the same pack menu.

The mechanism is worth a sentence because it explains the name: instead of demanding a clean block boundary, RFC 5649 pads the key up to the nearest 8-byte block and records how much padding it added, so unwrapping can strip it back off exactly. The alternative initial value (a fixed 32-bit "A" + the length) also hardens it against certain padding-oracle attacks. You don't need to remember any of that to use the node - but it's why this is the "correct" choice whenever your key isn't a clean multiple of 8, and it costs you nothing to use it for clean keys too. If you're only ever wrapping standard AES keys, plain AESKeyWrap is fine; if you ever touch odd-length secrets, just reach for this one and never think about it again.

The inputs

Identical to the plain wrap node - because the interface is the point of the consolidation:

• wrapping_key (BYTESLIKE) - the key doing the wrapping. Guard this one.
• secondary_key (BYTESLIKE) - the key to wrap, or the wrapped key when you're unwrapping. Same dual role as the sibling node.
• mode - "Wrap" on / "Unwrap" off.

Output is wrapped_key (BYTESLIKE), and the wrap is deterministic for a given input, so wrapping the same key twice with the same wrapping key gives the same output. Everything in and out is the pack's BYTESLIKE type.

Where people get burned

Honestly, not much to burn here - the padding variant exists precisely to remove the length footgun. The remaining traps are the shared wrap-node ones: swapping the two key inputs (unwrap takes the wrapped key as secondary input), and forgetting that the wrapped result is bytes, not text, so you'll want ByteslikeDecode if you plan to paste it anywhere. Also worth noting: wrapping and unwrapping must use the same node. A padded wrap unwrapped through plain AESKeyWrap will fail, and vice versa - the padding changes the framing.

Installing it

It's part of the ARG Toolkit pack; install once, use all its nodes:

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

Restart ComfyUI and find it under ARG Toolkit → Cryptography → Modern → Key Wrap (or via ComfyUI Manager → search "ComfyUI ARG Toolkit"). It rides on cryptography, which is in the pack's requirements.txt and typically already in your environment. No models, no downloads.

Troubleshooting

• Unwrap error → confirm both directions used this padded node, not its RFC 3394 sibling.
• Input order wrong → swap wrapping_key and secondary_key.
• Output looks like gibberish you can't read → that's correct; run it through ByteslikeDecode (Base64 or Hexadecimal) before pasting.

If AESKeyWrap is the nesting-doll node, this is the version with the flexible hinge. Same job, no length tantrums, and it's the one I'd wire by default whenever a key's byte length isn't something I bothered to count.