11 ms·
For reference why I don't follow, the two word approach to determine the algorithm and then be able to parse the base64 directly into a struct are easy. like i
by julian-klode 5y ago
For reference why I don't follow, the two word approach to determine the algorithm and then be able to parse the base64 directly into a struct are easy.
like in C++, I can
std::string algo, encoded;
in >> algo >> encoded;
if (algo == ed25519)
base64_decode(encoded, ed25519_pointer);
return std::move(ed25519_pointer);
else if (algo == ed448)
base64_decode(encoded, ed448_pointer);
return std::move(ed448_pointer);
Where the _pointer are std::unique_ptr of Ed25519Signature and Ed448Signature which are each subclasses of Signature, and the return type hence std::unique_ptr<Signature>.
- technion 5y agoIt's only upon the later clarifications in this thread that I've understood "key option 1" and the second option with subkeys are options for the standard and you won't need to support both. Both of these options have different lengths, and if both were supported you've have to split based on.. magic? It's been 20 years since I looked at C++, so I don't understand how you're splitting the public key from the signature given they are one concatenated blob, but that could just be me.
- julian-klode 5y agoC++ 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