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).
I don't really love this. It just feels so wasteful.
JWT does it as well.
Even in this example, they are double base64 encoding strings (the salt).
It's really too bad that there's really nothing quite like json. Everything speaks it and can write it. It'd be nice if something like protobuf was easier to write and read in a schemeless fashion.
reactordev · 10m ago
We just need to sacrifice n*field_count to a header describing the structure. We also need to define allowed types.
delecti · 24m ago
Oh that's nifty. Spotting base64 encoded strings is easy enough (and easy enough to test that I give it a shot if I'm even vaguely curious), but I'd never looked at them closely enough to spot patterns.
morkalork · 22m ago
After copy and pasting enough access tokens into various tools you pick up on it pretty fast.
athorax · 9m ago
Base64 encoded yaml files will also be LS-prefixed if they have the document marker (---)
snickerdoodle12 · 13m ago
Isn't this obvious to anyone who has seen a few base64 encoded json strings or certificates? ey and LS are a staple.
mmastrac · 9m ago
`MII` for RSA private keys.
FelipeCortez · 6m ago
I thought so too, but xkcd 1053 / lucky 10000, I guess! I knew about ey but not LS
rgovostes · 21m ago
There is a Base64 quasi-fixed point:
$ echo -n Vm0 | base64
Vm0w
It can be extended indefinitely one character at a time, but there will always be some suffix.
thaumasiotes · 18m ago
Note that the suffix will grow in length with the input, making it less and less interesting.
(Because the output is necessarily 8/6 the size of the input, the suffix always adds 33% to the length.)
gabesullice · 15m ago
I love this post style. Never stop learning friend!
shortrounddev2 · 17m ago
I discovered this when I created a JWT system for my internship. I got really good at spotting JWTs, or any base64 encoded json payloads in our Kafka streams
yahoozoo · 8m ago
babby's first base64
metalliqaz · 19m ago
Something similar pops up if you have to spend a lot of time looking at binary blobs with a hex editor. Certain common character sequences become familiar. This also leads to choosing magic numbers in data formats that decode to easily recognized ASCII strings. I'm sure if I worked with base64 I'd be choosing something that encoded nicely into particular strings for the same purpose.
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
JWT does it as well.
Even in this example, they are double base64 encoding strings (the salt).
It's really too bad that there's really nothing quite like json. Everything speaks it and can write it. It'd be nice if something like protobuf was easier to write and read in a schemeless fashion.
(Because the output is necessarily 8/6 the size of the input, the suffix always adds 33% to the length.)