Inconsistent use of bytes length/encodings?

[raxell]

createSalt generates keyLength bytes and then transform it in a base64 string. This string is passed to pbkdf2 as salt, but pbkdf2 treats strings as utf8, so the given salt is not the same random sequence of bytes generated early.
Can be assumed that the salt is still random even if has been expanded by the inconsistent use of the encodings? Are there any security implications? Usually in cryptography when you introduce some fixed points you open yourself to some kind of attacks.

[ericelliott]

createSalt generates keyLength bytes and then transform it in a base64 string. This string is passed to pbkdf2 as salt, but pbkdf2 treats strings as utf8, so the given salt is not the same random sequence of bytes generated early.

I'm not sure I understand the question. Doesn't UTF8 deterministically encode all base64 strings? Where does the inconsistency arise?

[raxell]

Where does the inconsistency arise?

The thing is that the lib is encoding the bytes with one encoding and decoding it with a different one. The decoding is not explicit in this lib, but is done by the pbkdf2 of the crypto module.
I don't know if this can be a problem, just asking if it is. The salt given to pbkdf is a 88 byte sequence, not the 66 bytes randomly generated

[tjconcept]

So, I assume, with my newbie cryptography knowledge, that the entropy is by definition the same regardless of how you encode the bytes. If that is the only desirable property of the salt, it may be alright. I don't know if it can cause unintended side-effects though. I would also guess that the back and forth encoding would mean the bytes get a pattern (usually not good for randomness) even if compensated for by length. I chose not to coerce types in https://github.com/srcagency/credentials due to the above unknowns.