René Meusel

In the code location you narrowed down, the public key is encoded as DER (while will likely cause the problematic 2-byte discrepancy). `m_key.point_encoding()` uses the private key's encoding as a...

> Maybe I'm doing something wrong, but set_public_point() doesn't exist in a Botan::ECDH_PrivateKey object like privkey_ecdh above. It looks only implemented in PKCS11_EC_PrivateKey. Oh sorry, I think I mixed something...

Yay! That is the behaviour I would have hoped for last week already. Sorry again for mixing up the variable names. I agree though, that this is a pretty "surprising"...

For the record: There seems to be a questionable internal structure hidden in both Streebog and Kuznyechik [1]. FWIW. [1] https://www.sstic.org/media/SSTIC2019/SSTIC-actes/RussianStyleRandomness/SSTIC2019-Article-RussianStyleRandomness-perrin_bonnetain.pdf

Sorry for the long waiting time, @radekgs. Admittedly, we're no experts on WASM (, yet). It would be great if you could try out the patch we provided in #2864...

Most probably you are seeing `BAD_CERTIFICATE` because Botan's default TLS policy has `require_cert_revocation_info()` enabled. Hence, the certificate verification fails if neither a valid OCSP response nor a CRL are available...

One other hypothesis (assuming the `http_util` works as expected): You might be seeing a clock skew issue. Given the OCSP response (fetched from the CA) is created instantaneously (with a...

> The result is a DLL, is it possible to eventually create a static library? You can call `configure.py` with the `--build-targets=static` option to build a static library.

Unfortunately, I don't have easy access to Cygwin. But this [seems to have to do with the `__STRICT_ANSI__` warning and GCC 11](https://github.com/clementine-player/Clementine/issues/6865). In fact the build system [undefines `__STRICT_ANSI__` explicitly...

Thanks for reporting this. Looking at [the implementation of those functions (`OS::get_cpu_total()`, `OS::get_cpu_available()`)](https://github.com/randombit/botan/blame/a44f1489239e80937ca67564ff103421e5584069/src/lib/utils/os_utils.cpp#L215): I assume that `OS::get_cpu_total()` falls back to the default return value (1) while `OS::get_cpu_available()` returns the correct...