3 ms·

> They do say "there may not be any practical ed448 implementations", however the cryptography.hazmat.primitives.asymmetric library used by the reference implem

> They do say "there may not be any practical ed448 implementations", however the cryptography.hazmat.primitives.asymmetric library used by the reference implementation has an ed448 function that could very likely slide right in. They would however need to change some hardcoded lengths. But that's not what that sentence means at all. It meant that APT might start just with support for ed25519, as IIRC I was told that ed448 is overkill right now. I successfully have signed and verified signatures using Ed448 using the branch of python-aptsign for it. > I do feel their discussion about not using separators to avoid coding string splitting actually makes it more complicated to code around variable lengths. I don't follow

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 ago
  It'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 ago
    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

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 ago
It'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 ago
  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