C++ code isn't there yet, the Python one just tries to decode as one and if that fails, falls back to the other; for testing purposes. In C++ the blob can just

C++ code isn't there yet, the Python one just tries to decode as one and if that fails, falls back to the other; for testing purposes. In C++ the blob can just be directly decoded into a struct, though. e.g. the initial format looked like this: struct signature { uint8_t primary_key[ED25519_KEY_SIZE] = {}; struct { uint8_t pubkey[ED25519_KEY_SIZE]; unaligned_little<uint64_t> expiry; // seconds since epoch unaligned_little<uint32_t> serial; // serial number } subkey; uint8_t subkey_signature[ED25519_SIGNATURE_SIZE] = {}; uint8_t signature[ED25519_SIGNATURE_SIZE] = {}; bool decode(std::string_view view); } and then signature::decode effectively just needs to call a base64_decode(this, sizeof(*this), view.data(), view.size()). (given a base64 decode function that allowed a fixed size output buffer) You can see there are magic unaligned integer types in there so that the whole thing is not architecture specific. The entire sample is in https://gist.github.com/julian-klode/4514ce39d3dc62647b502e5a8cf6a3ef https://gist.github.com/julian-klode/4514ce39d3dc62647b502e5... Obviously it does not fully match the current spec. If you wanted to support both structs, you could just try decoding as one or the other, or change the spec to use ed25519 and ed25519-subkey algorithm names :D