[dchest]

You seem to be confusing encoding (base64 for example), and encryption (AES for example).

I don't.

Where a side channel attack studying the decryption speed/power use can reveal information, the encoding of said encrypted data can not as far as I ever heard about. (It will still be encrypted after base64 decoding has taken place).

Encoding/decoding a value to/from base64 depends on the value, and many implementations use a lookup table or branches. While the table is small, so it fits in CPU cache thus making timing differences harder to detect, it's important for code dealing with secret values to avoid any timing differences by using simple branchless instructions that we know are constant-time on CPUs.

[jnwatson]

Unless you’re doing something out of the ordinary, secrets and plaintext aren’t base64 encoded. A variably-timed encoder/decoder will leaks bits of the ciphertext, which the attacker presumably already has.

[dchest]

Most web servers on the Internet store unwrapped base64-encoded secret keys.

Most SSH hosts store their secret keys encoded in base64 (/etc/ssh/).

Then, there's JWK which supports unwrapped secret keys.

Basically, you can't guarantee that the whole world is only encoding encrypted keys. That's why it's a good software engineering practice to prevent possible attacks by using constant-time encoder/decoder. As you can see from the link in posted, BoringSSL implements one.

Finally, the context of this thread is encoding and decoding of secret data, so I'm not sure why you had to post your opinion stating that it never happens. 1) It happens in real world. 2) I mentioned a solution for the case when it happens.