Hacker News new | past | comments | ask | show | jobs | submit login

Base64 is commonly used in cryptography to exchange keys.

Note that if you're encoding or decoding secret data, such as keys, you most likely want a constant-time encoder (example: https://boringssl.googlesource.com/boringssl/+/master/crypto...), not the fastest one.




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

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).

Please correct me if I'm wrong.

EDIT: I see you updated your original message with different wording, please ignore this rant.


Side-channel attacks against base64 encoding have yet to be proven, but constant-time implementations are available just in case.

My contribution is here: https://github.com/paragonie/constant_time_encoding


I'll add a high-assurance implementation from Galois to that which is probably not constant time. Their blog and Github has quite a few useful tools.

https://galois.com/blog/2013/09/high-assurance-base64/

Also, anyone wanting constant time implementation might just run a verified implementation through something like FaCT or Jasmin:

https://cseweb.ucsd.edu/~dstefan/pubs/cauligi:2017:fact.pdf

https://acmccs.github.io/papers/p1807-almeidaA.pdf


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.


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.


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.


Re “trusting trust” - do you know if it is possible to build a constant time encoder on top of a maliciously compromised system/toolchain? I assume it is not possible in general. Maybe this is a worthless observation because it applies to almost everything and is not exploited often in practice.


You're right, it's applies to everything.

There's also a problem with trust in CPU, and specifically, knowing which operations are constant time. See: https://bearssl.org/constanttime.html


When doing so programmatically, yes, but I actually assumed what you quoted was referring to manual key exchange. I.e. Certificates, PEM format, etc.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: