Live data from Hacker News

Spotting base64 encoded JSON, certificates, and private keys

ergaster.org

21–30 of 135 posts

Re: Spotting base64 encoded JSON, certificates, and private keys

#22

Isn't this obvious to anyone who has seen a few base64 encoded json strings or certificates? ey and LS are a staple.

`MII` for RSA private keys.

MII is not RSA, it's an opening header of asn1 structure encoded to DER -- 30 82 0x which is basically "{" when which can be pretty much anything from x509 certificate to private keys fro ECDSA.

Actual RSA oid is somewhere in the middle.

Re: Spotting base64 encoded JSON, certificates, and private keys

#23
post #8

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.

>Everything speaks it and can write it.

asn.1 is super nice -- everything speaks it and tooling is just great (runs away and hides)

Re: Spotting base64 encoded JSON, certificates, and private keys

#24
post #21

After staring one time too much at base64-encoded or hex-encoded asn1 I started to believe that scene in the Matrix where operator was looking at raw stream from Matrix at his terminal and was seeing things in it.

Years ago I was part of a group of people I knew who could read and edit large parts of sendmail.cf by hand without using m4. Other people who had to deal with mail servers at the time certainly treated it like a superpower.

Re: Spotting base64 encoded JSON, certificates, and private keys

#25

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.

For reference, a program to generate the quasi-fixed point from scratch:

  #!/usr/bin/env python3
  import base64

  def len_common_prefix(a, b):
      assert len(a) = length:
              return tmp[:length]
          print(tmp[:l].decode('ascii'), tmp[l:].decode('ascii'), sep='\v')
          # Slicing beyond end of buffer will safely truncate in Python.
          start = tmp[:l*4//3+4] # TODO is this ideal?

  if __name__ == '__main__':
      final = calculate_quasi_fixed_point(b'\0', 80)
      print(final.decode('ascii'))
This ultimately produces:

  Vm0wd2QyUXlVWGxWV0d4V1YwZDRWMVl3WkRSV01WbDNXa1JTVjAxV2JETlhhMUpUVmpBeFYySkVUbGho

Re: Spotting base64 encoded JSON, certificates, and private keys

#26
post #24
post #21

After staring one time too much at base64-encoded or hex-encoded asn1 I started to believe that scene in the Matrix where operator was looking at raw stream from Matrix at his terminal and was seeing things in it.

Years ago I was part of a group of people I knew who could read and edit large parts of sendmail.cf by hand without using m4. Other people who had to deal with mail servers at the time certainly treated it like a superpower.

Where I work right now superpower of the day is pressing ctrl-r in the terminal.

Re: Spotting base64 encoded JSON, certificates, and private keys

#27

I built a JWT support library at work ( https://github.com/geldata/gel-rust/tree/master/gel-jwt ) and I can confirm that JWTs all sound like "eyyyyyy" in my head.

>JWTs all sound like "eyyyyyy" in my head.

"eeey bruh, open the the API it's me"

Re: Spotting base64 encoded JSON, certificates, and private keys

#28
post #14

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…

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.

Re: Spotting base64 encoded JSON, certificates, and private keys

#30
post #14

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…

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