Maybe somewhere in the code it says

    key_string = to_string(*key);

instead of

    key_string = to_string(key);

▲ Athas 17 hours ago | parent | next [-]

This is the C explanation perspective, but a similar thing could happen in Python, if you write `s[0]` instead of `s`, perhaps due to a refactoring that changes an array of keys to a single key. This is because Python does not distinguish characters from strings. (Not an indictment of Python; just another proposal for how this could happen, and I would say it is more likely to use Python than C in some hacked-up signing script.)

	▲	account42 14 hours ago \| parent \| next [-]
		That should still produce uniformly random 8-bit numbers but these keys don't even look all that random in that range.
	▲	lionkor 14 hours ago \| parent \| prev [-]
		Well, my example is C++, it relies on function overloading existing for, for example, to_string(uint8_t[]) and to_string(uint8_t) separately, which means this error would come down to overloading instead of catching the type error. Just saying, because C++ is very popular everywhere in this "kind" of company, if you catch my drift.

▲ motionlessveloc 20 hours ago | parent | prev [-]

This should be higher. They mentioned a "coding error", and getting valid keys from the HSM and then truncating the string to a single byte through buggy array handling (see above) is exactly how you'd end up with a bunch of integers in the range 0-255.