Today at #TROOPERS25 I released a reimplementation of a set of protocols used to interact with a DHL #Packstation without using the official app: https://github.com/frereit/pydhl

It's more of a proof of concept than an actual utility, but maybe it's interesting for some.

hi crypto people, I could use a crypto vibe check on some black box crypto:

I'm looking at a key encryption mechanisms where some "inner" encryption keys are used to encrypt some data, and then encrypted themselves with a main key and stored along the data. The data decryption is therefore a two step process where you first decrypt the inner key using your main key and then the data with the inner key. The concept is pretty much exactly like the AWS KMS.

I am in a position where I can see something about the inner keys but I'm not sure exactly what it is. It might be either the keys themselves, or some seed used to derive the inner key. This is where I'd be interested in some educated guesses on the format.

This something is mostly 144 bytes long, but weirdly sometimes it's 143 bytes long (~7%), and sometimes only 142 bytes (~7%). Based on one hundred samples, the content looks like it's random. Flipping any bit in the key material causes the system to reject it.

In my armchair crypto gut feeling, it seems like 144 bytes is quite long for only a key, even if there was some tag added to the key, and the differing lengths are also a bit curious.

Obviously there's a bunch of scenarios where there's just no way to tell what I'm actually looking at without looking at any code but I wonder if there are any standard ways to create such a mechanisms that would result in these long variable-length inner keys. Has anyone seen something like that before?

#crypto #cryptography

The big Google outage was apparently some kind of null pointer deref:

The issue with this change was that it did not have appropriate error handling nor was it feature flag protected. Without the appropriate error handling, the null pointer caused the binary to crash. Feature flags are used to gradually enable the feature region by region per project, starting with internal projects, to enable us to catch issues. If this had been flag protected, the issue would have been caught in staging.
https://status.cloud.google.com/incidents/ow5i3PPK96RduMcb1SsW

I can't help but wonder if this was LLM-assisted code. I mean, if normally new features get a feature flag, but this one didn't, I wonder if it's because it's something an LLM doesn't emit when asked to implement a feature. Also, based on my experience with LLMs, the emitted code often lacks error handling and fails to consider edge cases.