You can spot Base64 encoded JSON.

The PEM format (that begins with `-----BEGIN [CERTIFICATE|CERTIFICATE REQUEST|PRIVATE KEY|X509 CRL|PUBLIC KEY]-----`) is already Base64 within the body.. the header and footer are ASCII, and shouldn't be encoded[0] (there's no link to the claim so perhaps there's another format similar to PEM?)

You can't spot private keys, unless they start with a repeating text sequence (or use the PEM format with header also encoded).

[0]: https://datatracker.ietf.org/doc/html/rfc7468

▲

ctz 7 days ago | parent | next [-]

The other base64 prefix to look out for is `MI`. `MI` is common to every ASN.1 DER encoded object (all public and private keys in standard encodings, all certificates, all CRLs) because overwhelmingly every object is a `SEQUENCE` (0x30 tag byte) followed by a length introducer (top nibble 0x8). `MII` is very very common, because it introduces a `SEQUENCE` with a two byte length.

▲

schoen 7 days ago | parent | next [-]

You'll also see "AQAB" a lot. This is the base64 version of the integer representation of 65537, the usual public exponent parameter e in modern RSA implementations.

▲

Muromec 7 days ago | parent | prev [-]

I for one wait for the day when quantum computers will break all the encryption forever so nobody will have to suffer broken asn1 decoders, plaintext specifications of machine-readable formats and unearned aura of arcane art that surrounds the whole thing.

	▲	ctz 7 days ago \| parent [-]
		asn1 enjoyers can also look forward to the sweet release of death. though if you end up in hell you might end up staring at XER for the rest of eternity

▲

mschuster91 7 days ago | parent | prev | next [-]

> The PEM format (that begins with `-----BEGIN [CERTIFICATE|CERTIFICATE REQUEST|PRIVATE KEY|X509 CRL|PUBLIC KEY]-----`) is already Base64 within the body.. the header and footer are ASCII, and shouldn't be encoded[0] (there's no link to the claim so perhaps there's another format similar to PEM?)

In practice, you will spot fully b64 encoded PEMs all the time once you have Kubernetes in play... create a Secret from a file and that's what you will find.

▲

CBLT 6 days ago | parent [-]

I don't always store my Kubernetes Secrets in files, but when I do, I prefer stringData.

	▲	mdaniel 6 days ago \| parent [-]
		I believe OP meant $(kubectl get secret) which by default returns them in JSON and base64 encoded. I do agree with you that it would be stellar if kubectl were bright enough to recognize "there's no weird characters, show me in stringData" but there are already other way more important DX issues that haven't gotten any traction

▲

thibaultamartin 7 days ago | parent | prev [-]

Thanks for pointing it out! I've added an errata to the blog post