AES-based Authenticated Key Generator

AESAuthenticatedKeygen exists to answer the question you'll have the moment you wire up the pack's AESAuthenticated node: where does a valid key come from? You can't type one - it's raw bytes, and it has to be the exact right length for the mode you picked. This node generates one, sized correctly, and hands it back as a BYTESLIKE output ready to plug straight into the encryption node.

The interesting part is that it does the mode-aware length math for you. Standard AES keys are 128, 192, or 256 bits, and the dropdown offers exactly those three. But AES-SIV is special: per the node's own tooltip, it needs both an encryption key and a MAC key, so the generator doubles the length you ask for internally. Pick "128" with SIV and you get a 256-bit key, because that's what the algorithm actually requires. That's a genuinely thoughtful touch - SIV's double-length requirement is exactly the kind of detail that turns into an hour of "why is my key invalid" debugging in hand-rolled code.

The inputs

Only two, both dropdowns:

• bit_length - 128, 192, or 256. For every mode except SIV this is the literal key size.
• aes_type - the same five-mode list as the encryption node: AES-GCM, AES-GCM-SIV, AES-OCB3, AES-SIV, AES-CCM. Match this to the aes_type you'll use in AESAuthenticated - a GCM key and a SIV key aren't interchangeable, and the node won't stop you from mixing them up.

Output is a single key of type BYTESLIKE. That's all there is - this is a two-knob node with one job.

How to actually use it

The clean flow in the pack is: AESAuthenticatedKeygen → key into AESAuthenticated's key input, a SystemRandom node → nonce, and your message → text. Generate a new key per message if the message is a one-off secret; reuse the same key across messages only if you're treating them as one corpus (and even then, fresh nonces every time - see the AESAuthenticated article for that lecture).

Where people get burned: wiring the key from the wrong keygen. The pack has several key nodes - Fernet's, ChaCha's, this one - and they're not cross-compatible. If your decrypt throws a key-length error, check that the key actually came from this node with the matching aes_type, not from a cousin.

Installing it

Part of the ARG Toolkit pack, so the install is the same as everything else in it:

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

Restart ComfyUI, find it under ARG Toolkit → Cryptography → Modern → Authenticated. Or use ComfyUI Manager → search "ComfyUI ARG Toolkit" → Install. It depends on cryptography, which ships with the pack's requirements.txt (and is usually already in your environment). No models, no GPU, nothing heavy.

Troubleshooting

• "Invalid key size" from the encryption node → you likely grabbed a non-matching key type, or mixed bit_length between the keygen and an assumption in your head about the mode. Pick 128 and match the modes.
• Key is the wrong length for SIV → it isn't; SIV legitimately wants double. Trust the tooltip.
• Key won't connect to the encryption node → both sides use the BYTESLIKE type, so if it won't snap in, you're holding a key from a different node (Fernet's is also BYTESLIKE, and also wrong here).

It's a tiny node with a tiny job - but it's the one that turns "I have an AES node" into "I have an AES node that will actually decrypt."