I have 2 unique random 256-bit keys, 1 is public, 1 is secret that need to be combined into 1 secret key.
That's weird, since we don't expect keys to be public, outsize of public key cryptography which uses asymmetric algorithms such as RSA. Usually public keys are not input to derive new keys.
In my search, I found that HMAC is more suited for this purpose and does not require an iteration count.
What you are looking for is a KDF or Key Derivation Function. There are two common KDF types: PBKDF's and KBKDF's:
- PBKDF's such as PBKDF2, bcrypt, Argon etc. take a password or -phrase. Due to the limited entropy they require a work factor; the iteration count is the work factor parameter of PBKDF2. This can extend the work for an adversary so that the security is about 20 bits higher than before, assuming one million as iteration count.
- KBKDF's are less well known. There are some particular ones such as HKDF, counter based KDF's from NIST and more modern KDF's build from e.g. SHAKE.
Quite often KBKDF's are not named as KDF's. Instead they are proprietary functions build on top of primitives such as HMAC. This is for instance the case of the unnamed KDF (or PRF) of TLS 1.2, which is specified directly in the TLS RFC and configured using the hash algorithm at the end of the cipher suite name. In contrast TLS 1.3 directly uses HKDF.
Does this mean that if PBKDF2 is used with the two input keys as the passphrase and salt, the iteration count can be set to only 1 since the passphrase is not password-based and is practically impossible to bruteforce?
That's a poor mans option for those that do not have direct access to a KBKDF such as HKDF. The same goes for the direct use of HMAC instead of a well-defined KDF.
EDIT: Both options would probably be considered secure as long as the secret would be set as the password or key, possibly as part of a concatenation with the public key. Using standardized algorithms is however recommended.
Personally I would try and find a HKDF implementation based on your API of HMAC and use that. If it is not available then it is best to build it yourself; HMAC is the only cryptographic primitive used for HKDF. Test vectors are included in the linked-to RFC.
The security should not rely on the "public key". I would find it more logical to use the public key as (part of) the Info parameter. The secret key would be the input keying material or IKM.
It's always wise with regards to security to include a random salt, but it depends on the use case if that's a good option.
The assumption here is that your secret key contains at least 128 bits of entropy. That's for instance the case if there are at least 128 to 245 fully random bits within that secret key.