-
Notifications
You must be signed in to change notification settings - Fork 555
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve API of asymmetric algorithms #3706
Labels
enhancement
Enhancement or new feature
Comments
5 tasks
This comment was marked as resolved.
This comment was marked as resolved.
lieser
added a commit
that referenced
this issue
Dec 6, 2023
lieser
added a commit
that referenced
this issue
Dec 6, 2023
For the record, here's an example of the hoops one needs to jump through to load a private key that is not wrapped in PKCS#8: #3902 (reply in thread). |
Thiesius
pushed a commit
to Roboauto/botan
that referenced
this issue
May 20, 2024
Use furo Sphinx theme Add OpenSSL 1.1 to Botan 3.x migration guide FIX: handling of TLS protocol errors in the ASIO wrapper A complete revamp of the state management in the ASIO stream wrapper to properly disentangle TLS state transitions even when receiving coalesced TLS records. Those can result in multiple state changes of Botan's underlying TLS implementation. For extensive technical details and a higher-level problem description, please see randombit#3801. Co-Authored-By: René Meusel <rene.meusel@rohde-schwarz.com> Add check to SM2_PrivateKey::check_key() that private key x is in ]0, q-1[ ./botan tls_client_hello can deal with TLS 1.3 Add Private_Key::remaining_operations() (randombit#3706) FIX: clang-tidy warnings Extend documentation for encryption and signing parameters note disabled modules in build/build_config.json Dynamically select a disabled module for the CMake test Before we just hard-coded the TPM module. Though, this causes issues when running the test in a build configuration where TPM is actually available. Like in the BSI build configurations. See also: sehlen-bsi/botan-docs#159 Mention CMake configuration in docs ./configure.py --without-cmake-config disables cmake integration Add sig algos and key agreements to bench.py Co-authored-by: René Meusel <github@renemeusel.de> Update Doxygen landing page Adding references to XOF (base class), PK_KEM_En/Decryptor, Kuznyechik, BLAKE2b (as a MAC), KMAC, KEMs (Kyber, RSA), Dilithium, SPHINCS+ and SHAKE (as a XOF) FIX: don't assume that 'tpm' is generally not available This is a follow-up of 971d7d5 Cleanup after merge master
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This is a collection of potential API improvements found in #3609.
pk_algs.h
)The generic function
create_private_key()
takes string-typedalgo_name
andalgo_params
to identify the algorithm (see also Type-based algorithm instantation #3275). In contrastload_{public/private}_key()
requires anAlgorithmIdentifier
object. This is inconvenient, as it requires the user to find a way to translate between the two.Public_Key::raw_public_key_bits()
(Introduce Public_Key::raw_public_key_bits() #3985)
Currently, we provide
public_key_bits()
("BER encoded public key bits") andsubject_public_key()
("X.509 subject key encoding"). Especially the new PQC algorithms seem to converge on their own (concat-based) encodings. Key agreement public keys could make this an alias forPK_Key_Agreement_Key::public_value()
. Other keys might treatraw_public_key_bits()
as an alias for the existingpublic_key_bits()
.std::unique_ptr<Private_Key> Public_Key::generate_another(RNG&)
(Feature:
AsymmetricKey::generate_another()
#3770)... to generically generate an equivalent new key pair with the same algorithm (and configuration) as the public key at hand. Use case: Mapping a KEM interface using a Key Agreement algorithm. The abstract "Encaps()" function needs
::generate_another()
to conveniently create an ephemeral keypair without knowledge about the exact underlying algorithm.std::optional<uint64_t> Private_Key::remaining_operations() const
(Add Private_Key::remaining_operations() #3821)
LMS and XMSS both have stateful operation, but there is no generic way to detect how many operations remain on a key. The proposed method should return
nullopt
for non-stateful algorithms, otherwise the remaining number of valid usages. [1]Allow accessing algorithm parameters (such as "shared key length", ...) statically. This would simplify some internal implementations that statically know which algorithm they are going to deal with. That might be useful not just for asym algos but in general (1, 2). For instance to avoid magic number such as: Feature: x448 and Ed448 #3933 (comment)
The text was updated successfully, but these errors were encountered: