Live data from Hacker News

Spotting base64 encoded JSON, certificates, and private keys

ergaster.org

71–80 of 135 posts

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

#71

Good knowledge, now explain why it's like that. {" is ASCII 01111011, 00100010 Base64 takes 3 bytes x 8 bits = 24 bits, groups that 24 bit-sequence into four parts of 6 bits each, and then converts each to a number between 0-63. If there aren't enough bits (we only have 2 bytes = 16 bits, we need 18 bits), pad them with 0. Of course in reality the last 2 bits would be taken from the 3rd character of the JSON string,…

I think the audience already understands why it works, it's more the knowing there's a relatively small set of mnemonics for these things that's interesting. "eyJ" for JSON, "LS0" for dashes (PEM encoding), "MII" for the DER payload inside a PEM, and so on.

I've been doing this a long time but until today the only one I'd noticed was "MII".

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

#73

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.

From the other direction, you'd call it a tail-eating unquine?

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

#74

Good knowledge, now explain why it's like that. {" is ASCII 01111011, 00100010 Base64 takes 3 bytes x 8 bits = 24 bits, groups that 24 bit-sequence into four parts of 6 bits each, and then converts each to a number between 0-63. If there aren't enough bits (we only have 2 bytes = 16 bits, we need 18 bits), pad them with 0. Of course in reality the last 2 bits would be taken from the 3rd character of the JSON string,…

That’s really a leap about the writer’s interest.

They could just as easily have felt the underlying reason was so obvious it wasn’t worth mentioning.

I know how base64 encoding works but had never noticed the pattern the author pointed out. As soon as read it, I ubderstood why. It didn’t occur to me that the author should have explained it at a deeper level.

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

#75
post #67

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.

It's like how all certificates sound like "miiiiii".

"It's miiiii! And I can prove it!"

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

#77

Earlier quoted context omitted.

I'd be very hesitant to consider this as some runaway symbol of "CS people being incurious now" over the author simply not being this deeply invested in this at the time of writing in the context of their discovery, especially since it almost certainly doesn't actually matter for them beyond the pattern existing, if even that does.

> it almost certainly doesn't actually matter for them beyond the pattern existing, if even that does. https://web.cs.ucdavis.edu/~rogaway/classes/188/materials/th...

And there goes my limit of curiosity now regarding this. I'm interested in what you have to say, but not 25 page mini-novel PDF from someone else interested. I'm glad you enjoyed that piece, but I have no interest in reading it, nor do I think it's reasonable for you to expect me to be interested. Much like with the author and the specifics of this encoding.

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

#78
post #37

Kind of reminds me of a junior being amazed when I was able to read ascii strings out of a hex stream. Us old folks have seen a lot .

For anyone here who's never pondered it ("today's lucky 10,000"?), there's a lot of intentional structure in the organization of ASCII that comes through readily in binary or hex.

https://altcodeunicode.com/ascii-american-standard-code-for-...

The first nibble (hex digit) shows your position within the chart, approximately like 2 = punctuation, 3 = digits, 4 = uppercase letters, 6 = lowercase letters. (Yes, there's more structure than that considering it in binary.)

For digits (first nibble 3), the value of the digit is equal to the value of the second nibble.

For punctuation (first nibble 2), the punctuation is the character you'd get on a traditional U.S. keyboard layout pressing shift and the digit of the second nibble.

For uppercase letters (first nibble 4, then overflowing into first nibble 5), the second nibble is the ordinal position of the letter within the alphabet. So 41 = A (letter #1), 42 = B (letter #2), 43 = C (letter #3).

Lowercase letters do the same thing starting at 6, so 61 = a (letter #1), 62 = b (letter #2), 63 = c (letter #3), etc.

The tricky ones are the overflow/wraparound into first nibble 5 (the letters from letter #16, P) and into first nibble 7 (from letter #16, p). There you have to actually add 16 to the letter position before combining it with the second nibble, or think of it as like "letter #0x10, letter #0x11, letter #0x12..." which may be less intuitive for some people).

Again, there's even more structure and pattern than that in ASCII, and it's all fully intentional, largely to facilitate meaningful bit manipulations. E.g. converting uppercase to lowercase is just a matter of adding 32, or logical OR with 0x00100000. Converting lowercase to uppercase is just a matter of subtracting 32, or logical AND with 0x11011111.

For reading hex dumps of ASCII, it's also helpful to know that the very first printable character (0x20) is, ironically, blank -- it's the space character.

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

#79
Not directly correlated but I know a old guy that can decrypt EBCDIC and credit card positional data format on the fly. And sometimes it was a "feeling" he couldn't explain it properlly but knew exactly the value, name and other data.

It was amazing to see him decode VISA and MASTER transactions on the fly in logs and other places.

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

#80

Earlier quoted context omitted.

> it almost certainly doesn't actually matter for them beyond the pattern existing, if even that does. https://web.cs.ucdavis.edu/~rogaway/classes/188/materials/th...

And there goes my limit of curiosity now regarding this. I'm interested in what you have to say, but not 25 page mini-novel PDF from someone else interested. I'm glad you enjoyed that piece, but I have no interest in reading it, nor do I think it's reasonable for you to expect me to be interested. Much like with the author and the specifics of this encoding.

[flagged]
Post reply on HN