[HN Gopher] Botan: Crypto and TLS for Modern C++
___________________________________________________________________
Botan: Crypto and TLS for Modern C++
Author : klaussilveira
Score : 58 points
Date : 2024-12-19 14:58 UTC (8 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| JanisErdmanis wrote:
| 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 wrote:
| tbh i'm just happy to see "crypto" and have it mean
| cryptography.
|
| sic transit gloria mundi or something. :)
| deknos wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| asveikau wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Cannot be done in suer mode if you have "hardware"
| implementation inside your NIC.
|
| And it is only way to performant TLS.
| tialaramex wrote:
| TLS 1.0 and TLS 1.1 are both a bad idea. If the far end of
| the connection isn't on a trip out of the solar system or
| buried under the ocean it needs to be upgraded. TLS 1.0 is
| from _last century_.
| mdaniel wrote:
| I first learned of it because KeePassXC uses it
| https://github.com/keepassxreboot/keepassxc/blob/2.7.9/cmake...
| frantathefranta wrote:
| 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.
| ch33zer wrote:
| 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 wrote:
| 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.
| ekr____ wrote:
| 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_ wrote:
| 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.
| nickelpro wrote:
| This only makes sense if you're doing greenfield development.
| The second you need to support existing protocols and devices
| where those decisions were chiseled in stone years or decades
| before, you'll be happy for a long list of hashes and
| algorithms all contained inside a single package with a single
| API to learn.
| mempko wrote:
| It's a great, easy to learn library. I used it for Firestr
| tptacek wrote:
| If you don't know precisely why you want a library like this (and
| sometimes you do), you want libsodium instead.
| wslh wrote:
| How does Libsodium compares with Crypto++[1] now? Wei Dai [2]
| is a highly reputable engineer.
|
| [1] https://github.com/weidai11/cryptopp
|
| [2] https://en.wikipedia.org/wiki/Wei_Dai
| awaythrow999 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Daniel Bernstein is not the creator of libsodium. Libsodium
| is based on his work on <https://nacl.cr.yp.to/> which is
| not the same.
| wolf550e wrote:
| Frank Denis, maintainer of libsodium, is also a reputable
| engineer.
| tptacek wrote:
| The MSB on these libraries isn't the author, but rather the
| intent of the library. Libsodium is designed to get you to
| basic core cryptographic functionality with the fewest
| possible landmines. Crypto++ is designed to be an interface
| to the maximum number of constructions and primitives. Those
| are radically different goals, and _almost_ everybody is
| better served by the former.
| blacklion wrote:
| For me, libsodium has one problem... grr... not exactly
| problem, but peculiarity, which is not mentioned in docs
| anywhere.
|
| libsodium doesn't put any metadata (including library
| and/or construction "version") in any its results, like
| boxes, keys, etc. So, there is no mechanism for versioning
| and backward compatibility.
|
| So, it is so-so Ok for real time communication between two
| installations of software product (and even then two ends
| could have different versions of software and/or library
| used!), but it is not suitable for long-time storage or
| communication between different systems.
|
| You store your "boxed" backup [keys] on disk. You want to
| read it 15 years later. How could you be sure, that
| libsodium didn't change algorithms in these 15 years? You
| need exactly same version of library that created this
| "box".
|
| And even application which is aware of this problem could
| not properly solve this: it could record & check libsodium
| version and refuse to work with "old" data, but how could
| it enforce future libsodium to read product of old one, as
| there is no any provision for this in API?
|
| libsodium is too simple for many tasks.
| gegabega wrote:
| Is there a Rust alternative?
| wolf550e wrote:
| https://github.com/rustls/rustls-ffi I guess
| tialaramex wrote:
| 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
|
| 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.
| thamer wrote:
| 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.
___________________________________________________________________
(page generated 2024-12-19 23:00 UTC)