Elliptic Curve Private Key Bytes

ECPrivateKey is where every modern-signature ARG workflow in this pack starts. It generates a fresh elliptic curve private key, optionally encrypts it, and hands you two things: the key as raw serialized bytes (keyfile) and the parsed key object (private_key) you can pass to ECSign. It's the "Elliptic Curve Private Key Bytes" node, and despite the dry name it's doing real cryptography via Python's cryptography library - not a toy cipher.

How it works

Under the hood it calls ec.generate_private_key() for your chosen curve, then serializes the result with private_bytes(). The curve is picked by name (curve_name), the output container by encoding, the layout by formatting, and whether it's password-protected by encryption.

The one genuinely cool input is private_value. Leave it blank and you get a fresh random key each run (so if you want reproducibility, save the bytes). Type a number into it and the node derives a specific key from that scalar - same input, same key, forever. That's a nice way to make a deterministic signing setup inside a workflow, though it also means anyone who knows the value can forge your key, so treat it as a puzzle mechanic, not a secret.

The inputs that matter

• curve_name - nine choices from the small modern curves (SECP256K1 is the Bitcoin one, SECP256R1/P-256 is the boring default everyone trusts, plus 192/224/384/521-bit SECP and Brainpool variants). For ARG purposes, SECP256R1 or SECP256K1 are the sensible picks.
• formatting - PKCS8 (modern standard, use this), Traditional OpenSSL (old BEGIN EC PRIVATE KEY style), or OpenSSH. OpenSSH is only meaningful with PEM encoding.
• encoding - PEM (text, readable) or DER (binary, compact).
• encryption - Best Available will AES-encrypt the key, but only if you actually provide encryption_password. None writes it in the clear.

Outputs

• keyfile (BYTESLIKE) - the serialized key bytes; wire into a DERPublicKey/PEMPublicKey loader, or save it out to feed a peer.
• private_key (KEYOBJ) - the parsed object; this is what ECSign wants on its private_key input.

There's also an optional pem_key input in the schema. Be aware the current code doesn't actually consume it - it's vestigial. Ignore it; you won't need it.

Installing it

It's part of the ComfyUI ARG Toolkit:

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

Then restart ComfyUI. ComfyUI Manager also finds it by searching "ComfyUI ARG Toolkit" and handles the pip dependencies (cryptography is the real workhorse here) automatically.

Where people get burned

• Random keys. Because a fresh key is generated on every run, two "identical" workflows produce different keys. If you're signing on one machine and verifying on another, you have to export the keyfile and transport it - don't expect the verification side to guess it.
• Encryption that silently does nothing. Pick Best Available and forget the password and you get an unencrypted key, because the code only encrypts when a password is present. It won't error; it just quietly writes plaintext. If you think a key is protected, double-check.
• Wrong curve on the other end. ECDSA signatures and keys are curve-bound. Generate on SECP256K1 and try to verify with a P-256 public key and nothing matches. Keep the curve consistent across every node in the chain.

This is the node to reach for when a workflow needs "real" asymmetric crypto rather than the classical ciphers the pack is better known for. Generate, sign, verify, and you've got a genuine PKI loop living entirely inside ComfyUI.