6 ms·

Botan: Crypto and TLS for Modern C++

98 points by klaussilveira 2y ago

JanisErdmanis 2y ago
I personally don’t like that every single cryptography scheme is included in a single library. This creates a fake sense of powerfulness, but breaks down once some more complicated things need to be done such as zero knowledge proofs or homomorphic computations when it can become awkward at best. In a sensible language one makes seperate modules for hashing, cryptographic group library, pseudorandom number generation, cryptographic signatures, various zero knowledge proofs and TLS and uses package manager to install what one needs.
- volkadav 2y ago
  tbh i'm just happy to see "crypto" and have it mean cryptography. sic transit gloria mundi or something. :)
- deknos 2y ago
  Why? It's better if it's in one place and the overall quality is maintained there, than having different libraries with different authors, quality levels and guidelines.
  - JanisErdmanis 2y ago
    Small libraries are easier to get into and contribute. Also, let’s say one develops some zero knowledge crypto system with Botan and then latter finds out that their elliptic curve implementation is not that performant. Improving performance of elliptic curves is one of the dark arts that only few know to do hence he decides to wrap one that OpenSSL library provides. The essential question is whether he would be able to use OpenSSL implementation without changing internals of Botan or his own zero knowledge crypto system implementation. In modular libraries this is less of an issue as itself generally implies working with abstract groups and writing wrappers or implementations outside.
    - theamk 2y ago
      Small libraries are the biggest contributors to supply chain problems, and that is the last thing you want in your crypto libraries! If you assemble your own system out of random components found on the web, there is a good chance that one of those components will either disappear or stop being supported. A single monolithic library is much likely to survive once it gets a critical mass of developers.
      - JanisErdmanis 2y ago
        Every developer is responsible for verifying the trustworthiness of given components when bringing the dependencies in and their upgrades. If the libraries are with a small API surface that is much easier to do than verifying for a big monoliths. One can simply check the specs for inputs and outputs to remain unchanged and that already provides assurances for incorrect implementations. Regarding supply chain attacks one of the important points is to establish consensus on dependency versions and their hashes via distributed replication or transparency logs (like in go). The big monolith then does not offer any advantages in this aspect.
        theamk 2y ago
        (1) The small API surface does not mean small complexity. A high-level package like "curl" or some SSL library might have a very small API hiding lots of complexity (2) How come "simply check the specs for inputs and outputs to remain unchanged" helps with trustworthiness or gives _any_ assurance of the incorrect implementations? (unless it's agda/coq, but we are not talking about them). The specs can say whatever, and yet the program might full of bugs. (3) How do you select a library in an area you are not familiar with? It seems you know cryptography well, so let's choose a different topic - what would you examine to find, say, good audio capture library, or a good OpenGL wrapper? For me, I'd look at popularity (by number of reverse dependencies in my repo, mentions on the web, or github stats); liveness (activity in repo and mailing list, open/closed bugs); general quality (commit history, CI logs if they are public, etc..). All of those would be _vastly_ easier with a single large repo vs tons of smaller one. (4) Think of few supply chain compromises that come to your mind. How many of those would be prevented by "distributed replication or transparency logs"? I've thought of xz compromise, left-pad pull and Marak's colors.js. _None_ of them would be fixed by "consensus on dependency versions and their hashes". All of them would be fixed if people just kept packages bigger, so that every one has actual CI, release team, and so on.
- asveikau 2y ago
  It's good for most use cases for it to be a black box. TLS apis that were designed in the 90s still work with the newest protocols and ciphers and bug fixes. Consumers of the library can blindly and transparently adopt 30 years of research into the topic.
  - jeroenhd 2y ago
    TLS APIs with moving cryptography targets have proven quite useful. I'm only sad that more low-level cryptography never got popular. In a perfect world, you tell the OS what key/trust store to use, what domain to connect to, and you just get a plaintext socket that'll do all the cryptography for you, regardless of whether you're using TLS 1.0 or TLS 1.3. I know the layered network protocol design is flawed, but I really like the elegance of the old design where TLS/IPSec/DTLS/WireGuard is just an option you pass to connect() rather than a library you need to pull in and maintain. Windows has something like that and it feels like somewhat of a missed opportunity for the internet.
    - asveikau 2y ago
      connect(2) and these other kernel mode interfaces are definitely the wrong layer. Should be done in user mode. You also want to be able to replace the transport layer with whatever you want. I think an opaque layer that lets you poke at internals when you decide you know what you're doing is the way to go. Eg. About 10 years ago I implemented certificate pinning atop a 1990s Microsoft API... you can use the api the "dumb" way and not touch it, and then optionally you can easily switch to implementing features the API vendor never envisioned.
      - blacklion 2y ago
        Cannot be done in suer mode if you have "hardware" implementation inside your NIC. And it is only way to performant TLS.
        toast0 2y ago
        You don't really need NIC TLS unless your bitrate is rather high and you're serving data that is stored on disk / in disk cache rather than data that was just generated on the CPU. Bulk ciphering is pretty inexpensive since Intel Haswell (2014) where there was a big improvement in AES-NI, but the load and store around ciphering static content that could otherwise avoid a trip through the CPU can be a significant bottleneck at 100gbps+. I'm sure there are measurable gains from TLS offload in other situations, but it's only critical for static content at high bit rates.
jfwuasdfs 2y ago
[flagged]
- yazzku 2y ago
  [flagged]
  - dang 2y ago
    We've banned this account for repeatedly breaking the site guidelines. If you don't want to be banned, you're welcome to email hn@ycombinator.com and give us reason to believe that you'll follow the rules in the future. They're here: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html.
    - yazzku 2y ago
      [dead]
mdaniel 2y ago
I first learned of it because KeePassXC uses it https://github.com/keepassxreboot/keepassxc/blob/2.7.9/cmake/FindBotan.cmake https://github.com/keepassxreboot/keepassxc/blob/2.7.9/cmake...
- frantathefranta 2y ago
  Same for me, found out what botan was because my nix managed KeePassXC package would not compile. Had to switch to the brew cask for the time being.
  - Handprint4469 2y ago
    is Nix worth it nowadays? my past experience has been full of these little inconveniences that made me give up on it, but I'm wondering if things have improved in the last 1-2 years.
    - frantathefranta 2y ago
      It's nice in NixOS, but my experience on MacOS isn't great. It could be due to me having an x86 2017 Macbook Pro with only 8GB of RAM but I regularly have to wait for bug fixes to update my system.
sour-taste 2y ago
A long list of supported hashes/algorithms is imo an antipattern for crypto libraries. They should focus on being very obviously correct for a small set of supported algorithms. Crypto's hard and this just increases the surface area.
- mcraiha 2y ago
  It would be easier, if there would be one standard combo that would be enough (e.g. something similar to the WireGuard). Currently there are many IoT devices that mention TLS-support, but they don't specify e.g. supported ciphers and hash functions.
  - deleted 2y ago
    [deleted]
  - ekr____ 2y ago
    In the case of TLS, at least, there is a set of mandatory to implement algorithms, so in principle two conformant implementations should be able to interoperate using those. Currently, they are: - ECDSA with P-256 for signature - ECDH with P-256 for key establishment - AES_128_GCM for data encryption with SHA-256 for hashing and KDF
- capitol_ 2y ago
  I would say that this is true for protocols, tls have been significantly improved by dropping support for many different algorithms. But its not obvious that the same is true for a library. The RustCrypto project breaks each algorithm into its own crate, while botan implrments everything. Its not obvious to me that one approach is clearly superior to the other.
  - cryptonector 2y ago
    Each alg in its own crate means lower footprint when you need just a few.
    - 2y ago
mempko 2y ago
It's a great, easy to learn library. I used it for Firestr
tptacek 2y ago
If you don't know precisely why you want a library like this (and sometimes you do), you want libsodium instead.
- wslh 2y ago
  How does Libsodium compares with Crypto++[1] now? Wei Dai [2] is a highly reputable engineer. [1] https://github.com/weidai11/cryptopp https://github.com/weidai11/cryptopp [2] https://en.wikipedia.org/wiki/Wei_Dai https://en.wikipedia.org/wiki/Wei_Dai
  - awaythrow999 2y ago
    Because extending trust usually works retrospectively? Or which battle tested applications exist today using crypto+, that illustrate it's a better choice than what sofar held up under libsodium (which is a lot)?
    - wslh 2y ago
      My comment was intended to be constructive, not to spark a flamewar. If you compare Crypto++ and Libsodium, you’ll notice they were created in different decades. This reflects that, at one point, C++ developers predominantly used Crypto++, while later, Libsodium emerged as an alternative.
  - adastra22 2y ago
    I’m not casting shade on anyone, but “highly reputable engineer” is not how I would describe Wei Dai. “Early thinker in this field, respected for his opinions” might be more accurate. Especially if you are directly comparing against libsodium and Daniel Bernstein who is a widely respected engineer whose work is widely used and heavily reviewed.
    - wslh 2y ago
      Daniel Bernstein is not the creator of libsodium. Libsodium is based on his work on <https://nacl.cr.yp.to/ https://nacl.cr.yp.to/> which is not the same.
gegabega 2y ago
Is there a Rust alternative?
- wolf550e 2y ago
  https://github.com/rustls/rustls-ffi https://github.com/rustls/rustls-ffi I guess
  - tialaramex 2y ago
    That's an FFI mechanism for Rustls the popular Rust TLS implementation (commonly used in Rust where say C or C++ programmers might use OpenSSL) So that's the component you would need if you've decided you want a Rust TLS implementation but, you actually want to use it from say, C++ instead. I assume the parent is actually a Rust programmer, or at least, intend to use this from Rust, so, yeah, plain Rustls is an obvious choice. https://crates.io/crates/rustls https://crates.io/crates/rustls As Thomas Ptacek emphasised above, despite Botan saying it's "Crypto and TLS" if you think you might need some sort of "Crypto" rather than you just want to speak TLS, such libraries have way too many knobs and switches you don't understand, as does OpenSSL. The whole point of libsodium and similar libraries is to not have switches you don't need. Spell out a use case and deliver exactly what's needed for that use case, nothing else, no switches, no "optional" features. Rust has a libsodium wrapper, which is especially useful if you either trust libsodium particularly or you have experience with those APIs, and also some similar but Rust flavor approaches where they don't give you all the knobs and switches just an API that makes sense for the specific use case you chose from their list - either the library is correct or it's not, no "What kind of idiot pushes the red button?" problems.
- jedisct1 2y ago
  The "boring" crate. It nicely wraps BoringSSL, and is actively maintained. The API is the most pleaseant of all crypto APIs I've seen in Rust.
deleted 2y ago
[deleted]
thamer 2y ago
For what it's worth, I've used Botan in a personal project where I needed a few hashing algorithms to verify file integrity (SHA-1, SHA-256, even MD5), and also used Botan's base 64 decoder in the same project. I found its modern "style" pleasant to write code for, and easy to integrate with good docs. That said, I did notice the large number of algorithms as others have pointed out, and I'm not sure I'd use it for more serious purposes when libsodium is well-established. It certainly wouldn't be an obvious choice. But to quickly add support for common hash algorithms in a small project, I thought it was a good option and enjoyed its API design and simplicity.
elintknower 2y ago
Are there any demos using this to sign requests on the ESP32 or similar embedded platforms?
- jedisct1 2y ago
  On embedded platforms, libhydrogen is great. https://libhydrogen.org https://libhydrogen.org

98 points by klaussilveira 2y ago

I personally don’t like that every single cryptography scheme is included in a single library. This creates a fake sense of powerfulness, but breaks down once some more complicated things need to be done such as zero knowledge proofs or homomorphic computations when it can become awkward at best. In a sensible language one makes seperate modules for hashing, cryptographic group library, pseudorandom number generation, cryptographic signatures, various zero knowledge proofs and TLS and uses package manager to install what one needs.

volkadav 2y ago
tbh i'm just happy to see "crypto" and have it mean cryptography. sic transit gloria mundi or something. :)
deknos 2y ago
Why? It's better if it's in one place and the overall quality is maintained there, than having different libraries with different authors, quality levels and guidelines.
- JanisErdmanis 2y ago
  Small libraries are easier to get into and contribute. Also, let’s say one develops some zero knowledge crypto system with Botan and then latter finds out that their elliptic curve implementation is not that performant. Improving performance of elliptic curves is one of the dark arts that only few know to do hence he decides to wrap one that OpenSSL library provides. The essential question is whether he would be able to use OpenSSL implementation without changing internals of Botan or his own zero knowledge crypto system implementation. In modular libraries this is less of an issue as itself generally implies working with abstract groups and writing wrappers or implementations outside.
  - theamk 2y ago
    Small libraries are the biggest contributors to supply chain problems, and that is the last thing you want in your crypto libraries! If you assemble your own system out of random components found on the web, there is a good chance that one of those components will either disappear or stop being supported. A single monolithic library is much likely to survive once it gets a critical mass of developers.
    - JanisErdmanis 2y ago
      Every developer is responsible for verifying the trustworthiness of given components when bringing the dependencies in and their upgrades. If the libraries are with a small API surface that is much easier to do than verifying for a big monoliths. One can simply check the specs for inputs and outputs to remain unchanged and that already provides assurances for incorrect implementations. Regarding supply chain attacks one of the important points is to establish consensus on dependency versions and their hashes via distributed replication or transparency logs (like in go). The big monolith then does not offer any advantages in this aspect.
      - theamk 2y ago
        (1) The small API surface does not mean small complexity. A high-level package like "curl" or some SSL library might have a very small API hiding lots of complexity (2) How come "simply check the specs for inputs and outputs to remain unchanged" helps with trustworthiness or gives _any_ assurance of the incorrect implementations? (unless it's agda/coq, but we are not talking about them). The specs can say whatever, and yet the program might full of bugs. (3) How do you select a library in an area you are not familiar with? It seems you know cryptography well, so let's choose a different topic - what would you examine to find, say, good audio capture library, or a good OpenGL wrapper? For me, I'd look at popularity (by number of reverse dependencies in my repo, mentions on the web, or github stats); liveness (activity in repo and mailing list, open/closed bugs); general quality (commit history, CI logs if they are public, etc..). All of those would be _vastly_ easier with a single large repo vs tons of smaller one. (4) Think of few supply chain compromises that come to your mind. How many of those would be prevented by "distributed replication or transparency logs"? I've thought of xz compromise, left-pad pull and Marak's colors.js. _None_ of them would be fixed by "consensus on dependency versions and their hashes". All of them would be fixed if people just kept packages bigger, so that every one has actual CI, release team, and so on.
asveikau 2y ago
It's good for most use cases for it to be a black box. TLS apis that were designed in the 90s still work with the newest protocols and ciphers and bug fixes. Consumers of the library can blindly and transparently adopt 30 years of research into the topic.
- jeroenhd 2y ago
  TLS APIs with moving cryptography targets have proven quite useful. I'm only sad that more low-level cryptography never got popular. In a perfect world, you tell the OS what key/trust store to use, what domain to connect to, and you just get a plaintext socket that'll do all the cryptography for you, regardless of whether you're using TLS 1.0 or TLS 1.3. I know the layered network protocol design is flawed, but I really like the elegance of the old design where TLS/IPSec/DTLS/WireGuard is just an option you pass to connect() rather than a library you need to pull in and maintain. Windows has something like that and it feels like somewhat of a missed opportunity for the internet.
  - asveikau 2y ago
    connect(2) and these other kernel mode interfaces are definitely the wrong layer. Should be done in user mode. You also want to be able to replace the transport layer with whatever you want. I think an opaque layer that lets you poke at internals when you decide you know what you're doing is the way to go. Eg. About 10 years ago I implemented certificate pinning atop a 1990s Microsoft API... you can use the api the "dumb" way and not touch it, and then optionally you can easily switch to implementing features the API vendor never envisioned.
    - blacklion 2y ago
      Cannot be done in suer mode if you have "hardware" implementation inside your NIC. And it is only way to performant TLS.
      - toast0 2y ago
        You don't really need NIC TLS unless your bitrate is rather high and you're serving data that is stored on disk / in disk cache rather than data that was just generated on the CPU. Bulk ciphering is pretty inexpensive since Intel Haswell (2014) where there was a big improvement in AES-NI, but the load and store around ciphering static content that could otherwise avoid a trip through the CPU can be a significant bottleneck at 100gbps+. I'm sure there are measurable gains from TLS offload in other situations, but it's only critical for static content at high bit rates.

jfwuasdfs 2y ago

[flagged]

yazzku 2y ago
[flagged]
- dang 2y ago
  We've banned this account for repeatedly breaking the site guidelines. If you don't want to be banned, you're welcome to email hn@ycombinator.com and give us reason to believe that you'll follow the rules in the future. They're here: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html.
  - yazzku 2y ago
    [dead]

mdaniel 2y ago

I first learned of it because KeePassXC uses it https://github.com/keepassxreboot/keepassxc/blob/2.7.9/cmake/FindBotan.cmake https://github.com/keepassxreboot/keepassxc/blob/2.7.9/cmake...

frantathefranta 2y ago
Same for me, found out what botan was because my nix managed KeePassXC package would not compile. Had to switch to the brew cask for the time being.
- Handprint4469 2y ago
  is Nix worth it nowadays? my past experience has been full of these little inconveniences that made me give up on it, but I'm wondering if things have improved in the last 1-2 years.
  - frantathefranta 2y ago
    It's nice in NixOS, but my experience on MacOS isn't great. It could be due to me having an x86 2017 Macbook Pro with only 8GB of RAM but I regularly have to wait for bug fixes to update my system.

sour-taste 2y ago

A long list of supported hashes/algorithms is imo an antipattern for crypto libraries. They should focus on being very obviously correct for a small set of supported algorithms. Crypto's hard and this just increases the surface area.

mcraiha 2y ago
It would be easier, if there would be one standard combo that would be enough (e.g. something similar to the WireGuard). Currently there are many IoT devices that mention TLS-support, but they don't specify e.g. supported ciphers and hash functions.
- deleted 2y ago
  [deleted]
- ekr____ 2y ago
  In the case of TLS, at least, there is a set of mandatory to implement algorithms, so in principle two conformant implementations should be able to interoperate using those. Currently, they are: - ECDSA with P-256 for signature - ECDH with P-256 for key establishment - AES_128_GCM for data encryption with SHA-256 for hashing and KDF
capitol_ 2y ago
I would say that this is true for protocols, tls have been significantly improved by dropping support for many different algorithms. But its not obvious that the same is true for a library. The RustCrypto project breaks each algorithm into its own crate, while botan implrments everything. Its not obvious to me that one approach is clearly superior to the other.
- cryptonector 2y ago
  Each alg in its own crate means lower footprint when you need just a few.
  - 2y ago

mempko 2y ago

It's a great, easy to learn library. I used it for Firestr

tptacek 2y ago

If you don't know precisely why you want a library like this (and sometimes you do), you want libsodium instead.

wslh 2y ago
How does Libsodium compares with Crypto++[1] now? Wei Dai [2] is a highly reputable engineer. [1] https://github.com/weidai11/cryptopp https://github.com/weidai11/cryptopp [2] https://en.wikipedia.org/wiki/Wei_Dai https://en.wikipedia.org/wiki/Wei_Dai
- awaythrow999 2y ago
  Because extending trust usually works retrospectively? Or which battle tested applications exist today using crypto+, that illustrate it's a better choice than what sofar held up under libsodium (which is a lot)?
  - wslh 2y ago
    My comment was intended to be constructive, not to spark a flamewar. If you compare Crypto++ and Libsodium, you’ll notice they were created in different decades. This reflects that, at one point, C++ developers predominantly used Crypto++, while later, Libsodium emerged as an alternative.
- adastra22 2y ago
  I’m not casting shade on anyone, but “highly reputable engineer” is not how I would describe Wei Dai. “Early thinker in this field, respected for his opinions” might be more accurate. Especially if you are directly comparing against libsodium and Daniel Bernstein who is a widely respected engineer whose work is widely used and heavily reviewed.
  - wslh 2y ago
    Daniel Bernstein is not the creator of libsodium. Libsodium is based on his work on <https://nacl.cr.yp.to/ https://nacl.cr.yp.to/> which is not the same.

gegabega 2y ago

Is there a Rust alternative?

wolf550e 2y ago
https://github.com/rustls/rustls-ffi https://github.com/rustls/rustls-ffi I guess
- tialaramex 2y ago
  That's an FFI mechanism for Rustls the popular Rust TLS implementation (commonly used in Rust where say C or C++ programmers might use OpenSSL) So that's the component you would need if you've decided you want a Rust TLS implementation but, you actually want to use it from say, C++ instead. I assume the parent is actually a Rust programmer, or at least, intend to use this from Rust, so, yeah, plain Rustls is an obvious choice. https://crates.io/crates/rustls https://crates.io/crates/rustls As Thomas Ptacek emphasised above, despite Botan saying it's "Crypto and TLS" if you think you might need some sort of "Crypto" rather than you just want to speak TLS, such libraries have way too many knobs and switches you don't understand, as does OpenSSL. The whole point of libsodium and similar libraries is to not have switches you don't need. Spell out a use case and deliver exactly what's needed for that use case, nothing else, no switches, no "optional" features. Rust has a libsodium wrapper, which is especially useful if you either trust libsodium particularly or you have experience with those APIs, and also some similar but Rust flavor approaches where they don't give you all the knobs and switches just an API that makes sense for the specific use case you chose from their list - either the library is correct or it's not, no "What kind of idiot pushes the red button?" problems.
jedisct1 2y ago
The "boring" crate. It nicely wraps BoringSSL, and is actively maintained. The API is the most pleaseant of all crypto APIs I've seen in Rust.

deleted 2y ago

[deleted]

thamer 2y ago

For what it's worth, I've used Botan in a personal project where I needed a few hashing algorithms to verify file integrity (SHA-1, SHA-256, even MD5), and also used Botan's base 64 decoder in the same project. I found its modern "style" pleasant to write code for, and easy to integrate with good docs. That said, I did notice the large number of algorithms as others have pointed out, and I'm not sure I'd use it for more serious purposes when libsodium is well-established. It certainly wouldn't be an obvious choice. But to quickly add support for common hash algorithms in a small project, I thought it was a good option and enjoyed its API design and simplicity.

elintknower 2y ago

Are there any demos using this to sign requests on the ESP32 or similar embedded platforms?

jedisct1 2y ago
On embedded platforms, libhydrogen is great. https://libhydrogen.org https://libhydrogen.org