HMAC exchange API credentials use a shared secret to authenticate requests. RSA and Ed25519 use a private key to sign and a public key for the exchange to verify. The API-key identifier, signing material and request format must match the exact venue interface and connector. Choosing an algorithm does not grant permissions or prove that a trading application supports it.
A setup screen might offer “system-generated” and “self-generated” keys, while an application asks only for an API key and secret. Those labels describe different credential arrangements. Pasting a private-key file into a secret field does not make the application an asymmetric signer.
The useful first decision is therefore a compatibility decision: which credential form does this specific connection accept?
Three materials people call an API key
Separate the identifier from the authority to authenticate a request.
- The API-key identifier lets the venue locate a registered credential and its permissions.
- An HMAC secret is shared signing material. The client and venue can both calculate the message authentication code.
- An asymmetric private key stays with the signing system; its corresponding public key lets the venue verify signatures.
HMAC is a keyed message-authentication mechanism, rather than encryption of the request. It protects authenticity and integrity under its security assumptions; it does not conceal the message. The underlying definition uses a shared secret. RFC 2104's HMAC definition.
RSA and Ed25519 are distinct signature families. They do not use interchangeable private keys, even when both keys are stored in files ending in .pem. A filename is packaging, not an algorithm declaration.
| Credential family | Material used by the signer | Verification material at the venue | Common setup mistake |
|---|---|---|---|
| HMAC | The registered shared secret | The same shared secret | Treating the API-key identifier as the secret |
| RSA | The private member of the registered RSA pair | Its matching RSA public key | Selecting an RSA key but retaining an HMAC-only client |
| Ed25519 | The private member of the registered Ed25519 pair | Its matching Ed25519 public key | Assuming an RSA-compatible connector also accepts Ed25519 |
Binance Spot's API-key type reference describes all three arrangements, recommends Ed25519 and currently labels HMAC keys deprecated. That is a provider-specific status reviewed on 23 October 2026. It is not evidence that another venue has retired HMAC, nor that a particular connector can already migrate.
Check the interface before choosing the key
Support has several dimensions: venue, regional account, product, environment, protocol and client version. “The exchange supports RSA” is too broad to serve as an acceptance test for a particular integration.
Bybit's V5 guidance documents system-generated HMAC credentials and self-generated RSA credentials. It specifies HMAC-SHA256 output as hexadecimal and RSA-SHA256 output as Base64. Bybit V5 authentication guidance. This article does not infer Ed25519 support for that interface.
Encoding belongs to the connector contract too. Binance Spot REST's RSA procedure specifies RSASSA-PKCS1-v1_5 with SHA-256, a Base64 signature and percent-encoding for transport. Its documentation also specifies supported key packaging. An RSA library's default padding or output format is not automatically correct. Binance Spot REST signing procedures.
Do not repair a compatibility gap by stripping headers from a key file or relabeling its contents. Confirm the accepted algorithm and key format through the integration's documented flow first.
KLINEO's connection policy tells readers to use the credential type shown for their venue. The reviewed Binance and Bybit exchange clients use HMAC signing; this article does not establish RSA or Ed25519 support in KLINEO. If the available exchange credential type and the connection's supported form do not match, resolve the compatibility question before connecting.
A worked key-pair mismatch worksheet
Consider a fictional integration test, with no customer credentials or live orders. An operator generates two RSA pairs, labeled A and B. Public key A is registered with a venue, which assigns API-key identifier R1. The deployment accidentally loads private key B.
The requests have fresh timestamps and correct permissions. They still cannot authenticate as R1 because the registered verification key and signing key do not match.
| Test case | Signer receives | Venue registration | Expected finding |
|---|---|---|---|
| Original deployment | Private B | R1 → public A | Mismatched pair; investigate deployment selection |
| Attempted “fix” | Public A only | R1 → public A | Verification material cannot replace the private signer |
| Corrected local check | Private A | Public A used locally | Local verification succeeds for the exact test message |
| Remote account read | Private A through a supported RSA client | R1 → public A | Authentication can now be tested; permissions, timing and encoding still matter |
| Wrong client | Private A pasted into an HMAC secret field | R1 → public A | Wrong signing mechanism; matching files alone cannot fix it |
A local sign-and-verify result proves only that the tested pair and message agree locally. It does not prove the connector signed the venue's required representation, sent the right API identifier or reached the intended environment.
Use this worksheet with non-secret labels. Record the registered public-key fingerprint, signer configuration reference, algorithm, client version and environment. Compare public fingerprints derived through a trusted local tool where supported. Do not paste private material into a support conversation to demonstrate that two files differ.
If the remote check fails, preserve its exact error code and request family. The timestamp and signature diagnostic covers clocks and request serialization; repeating that investigation without first confirming the key family can waste the entire test.
Asymmetric signing changes custody, not permissions
With RSA or Ed25519, the exchange can verify without holding your private signing key. However, the system performing signatures still needs that authority. If a hosted service loads the private key, asymmetric authentication has not removed the need to trust that service's signing environment.
A private key encrypted with a passphrase also needs a supported unlocking arrangement. Do not remove its protection merely because an undocumented integration cannot load it. Establish the supported key-handling path first.
Keep signing material out of source repositories, debug traces, screenshots and generic credential-testing sites. Access control, rotation and revocation remain separate operational responsibilities. OWASP's secrets lifecycle guidance provides the broader handling principles.
The algorithm does not choose withdrawal, transfer or trading permissions. Review exchange API-key permissions separately. A correctly signed trade can still be unwanted or loss-making.
Authentication is one acceptance gate
Before enabling work, write down four distinct observations: the connector accepts this key family, a supported authenticated read succeeds, the returned account and environment are correct, and the requested action is within the intended permissions.
Then verify the request's meaning. A valid signature does not establish that an instrument identifier names the contract you intended. The symbol and contract mapping worksheet addresses that separate mapping boundary.
Likewise, a successful signed REST read does not establish that a private event stream is authenticated and subscribed for the full operating period. Follow the private-stream session-expiry guide when assessing that session.
For an exposed HMAC secret or asymmetric private key, use credential incident response. Changing the algorithm in a local configuration does not revoke the old credential at the venue. Revocation also leaves a separate account-state job: inspect existing orders, fills and positions.
Editorial method: Prepared with AI assistance on 23 October 2026 from the cited primary specifications, exchange documentation and KLINEO connection-source review. The pair-mismatch worksheet is an original fictional example. No live credential, production authentication test or security certification was used.