Bug report: "Derive KDF key" gets wrong result

[YanWQ-monad]

Describe the bug
In "Derive KDF key", if the Salt is in HEX mode and Salt contains multi-bytes of UTF-8, it will get the wrong result.

To Reproduce

1. Add recipe "Derive EVP Key"
2. Set its parameters to:
   • Passphrase: hello (UTF8)
   • Key size: 128
   • Iterations: 1
   • Hashing Function: MD5
   • Salt: deadbeef (HEX)

And it should output a06aeae0a8790070445991fd480c0d91 in CyberChef.

Reproduce Link

Expected behaviour
As CyberChef use CryptoJS as backend for this recipe, here use CryptoJS to show the expected behaviour:

const CryptoJS = require("crypto-js");  // 4.1.1

const key = CryptoJS.EvpKDF(
    'hello',
    CryptoJS.lib.WordArray.create([ 0xdeadbeef ], 4),
    {
        keySize: 4,
        hasher: CryptoJS.algo.MD5,
        iterations: 1,
    }
);

console.log(key.toString());  // -> 467e8570f8a641fcd5411176b1740d53

Possible Cause
In CyberChef's "Derive KDF key",

CyberChef/src/core/operations/DeriveEVPKey.mjs

Line 69 in 1bc8872

salt = Utils.convertToByteString(args[4].string, args[4].option),

it first parses the hex sequence back to byte string. So, 0xdeadbeef is parsed to Þ\xad¾ï.

Next, in CryptoJS.EvpKDF, when appends salt to the hasher,
https://github.com/brix/crypto-js/blob/4dcaa7afd08f48cd285463b8f9499cdb242605fa/src/core.js#L564
it will parse the "byte string" to its WordArray by Utf8.parse. So, the non-ASCII characters are encoded again, but in UTF-8 encoding, which gets c39ec2adc2bec3af.

That is, although the salt is 0xdeadbeef in frontend, but in fact it's treated as c39ec2adc2bec3af, and thus it gets the wrong result.

[YanWQ-monad]

Maybe related: #210

[a3957273]

Fixed in #1767