Digests now use bearssl + libsodium instead of openssl + libsodium.
It fits better with the API looking more similar and I don't think it
will be that much of a bottleneck.
Instead of a apk_pkey that mimicks the EVP_PKEY semantics, have seperate
public and private key structures. However, apk is broken because of it
and needs fixing. The rest of the code might compile but won't work
as I haven't handled the cases where pkey corressponds to public/private
keys in codebase properly. Also, DSA signatures are removed.
Public and private keys impls' now use a static array of vtables
internally. The indicies correspond to the signature scheme version and
checking `< APK_*_MAX` should be enough? I tried to make so that higher
values correspond to more desirable constructs, this might come in handy.
Signing/verifying start is free from keys as it isn't used though it
might be brought back for domain seperated hashes, ability to get
timestamps involved with epheremal keys in the future etc.
`apk_crypto.h` is free from openssl includes although some headers still
use them for now.
Start working on "cute" signatures because why not? Cute signatures are
inspired/ripped of from the signify and minisign design:
Key (URL-Safe, padded base64):
- 2 bytes of version tag (specifies the algorithm)
- 16 bytes of key ID
- Public/Private key (size depending on the version tag)
Signature (raw):
- 2 bytes of version tag (specifies the algorithm)
- Signature depending (size depending on the version tag)
The new scheme uses libsodium and thus the work of
abstracting cryptographic operations from libcrypto should also be
completed. Also, since the key of the signature is provided in the
filename, there shouldn't be a need for ID
There is also the possibility of using epheremal keys for signatures and
sign the package's public key, signature and signing timestamp in the header
such as:
- 2 bytes of version tag
- signing timestamp
- epheremal public key used
- epheremal signature
- signature of the previous sections