# Botan bindings devlog

**URL:** <https://discourse.haskell.org/t/botan-bindings-devlog/6855>\
**Category:** Uncategorized\
**Created:** [July 5, 2023, 6:17pm UTC](https://discourse.haskell.org/t/botan-bindings-devlog/6855 "2023-07-05T18:17:27Z")\
**Posts on this page:** 20\
**Page:** 8

<div class="post-metadata">

**Author:** ![ApothecaLabs](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/apothecalabs/32/3215_2.png) [@ApothecaLabs](https://discourse.haskell.org/u/ApothecaLabs)\
**Post date:** [February 13, 2024, 9:03pm UTC](https://discourse.haskell.org/t/botan-bindings-devlog/6855/141 "2024-02-13T21:03:13Z")

</div>

# Update: `botan-bindings` and `botan-low` published!

I’ve been going over everything, polishing everything I can, responding to some feedback, but I can put it off no more! It is time, and it is done. `botan-bindings` and `botan-low` have had their `0.0.1.0` published!

> **[botan-bindings](https://hackage.haskell.org/package/botan-bindings-0.0.1.0)**
>
> Raw Botan bindings

> **[botan-low](https://hackage.haskell.org/package/botan-low-0.0.1.0)**
>
> Low-level Botan bindings

There’s still things I’d like to do, a module here or there that lacks examples, and perhaps things could be sectioned / organized / ordered better - but that’s for the next version!

I’ll make a focused announcement here and on reddit in a bit; for the moment I’m a tad tired 🥳

---

<div class="post-metadata">

**Author:** ![Bodigrim](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/bodigrim/32/1457_2.png) [@Bodigrim](https://discourse.haskell.org/u/Bodigrim)\
**Post date:** [February 15, 2024, 12:21am UTC](https://discourse.haskell.org/t/botan-bindings-devlog/6855/142 "2024-02-15T00:21:59Z")

</div>

> [@ApothecaLabs](#):
>
> Edit: I missed: _distributing **precompiled** amalgamated Botan source_ can you explain in a little more detail what you have in mind?

I’m quite illiterate in the area, so I might very well talk nonsense. But why do we care about building Botan from its sources? Why could not `botan-bindings` just package `botan_all.cpp`?

---

<div class="post-metadata">

**Author:** ![arybczak](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/arybczak/32/2527_2.png) [@arybczak](https://discourse.haskell.org/u/arybczak)\
**Post date:** [February 15, 2024, 8:44pm UTC](https://discourse.haskell.org/t/botan-bindings-devlog/6855/143 "2024-02-15T20:44:10Z")

</div>

“Compressing” a multi-unit C++ project into a single file is a non-trivial task. Also, considering that botan takes a while to build, even if you managed to produce a single-file bundle, it’s not clear how much memory GCC/clang would need to compile it (my guess is a lot).

---

<div class="post-metadata">

**Author:** ![Bodigrim](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/bodigrim/32/1457_2.png) [@Bodigrim](https://discourse.haskell.org/u/Bodigrim)\
**Post date:** [February 15, 2024, 11:06pm UTC](https://discourse.haskell.org/t/botan-bindings-devlog/6855/144 "2024-02-15T23:06:52Z")

</div>

> [@arybczak](#):
>
> “Compressing” a multi-unit C++ project into a single file is a non-trivial task.

[The Amalgamation Build](https://botan.randombit.net/handbook/building.html#amalgamation)

---

<div class="post-metadata">

**Author:** ![hasufell](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/hasufell/32/1250_2.png) [@hasufell](https://discourse.haskell.org/u/hasufell)\
**Post date:** [February 16, 2024, 2:03am UTC](https://discourse.haskell.org/t/botan-bindings-devlog/6855/145 "2024-02-16T02:03:47Z")

</div>

> [@Bodigrim](#):
>
> I’m quite illiterate in the area, so I might very well talk nonsense. But why do we care about building Botan from its sources?

As an ex linux source distro maintainer, I’ve seen cases where big enough C++ files caused so much memory spikes that compilation regularly failed on end users systems.

---

<div class="post-metadata">

**Author:** ![hasufell](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/hasufell/32/1250_2.png) [@hasufell](https://discourse.haskell.org/u/hasufell)\
**Post date:** [February 16, 2024, 2:10am UTC](https://discourse.haskell.org/t/botan-bindings-devlog/6855/146 "2024-02-16T02:10:57Z")

</div>

On a more general note, I want to re-iterate that bundling any crypto source code **is considered very bad practice amongst linux distro maintainers**.

What you’re essentially doing is becoming responsible for tracking security vulnerabilities upstream (which is already done and automated in large linux distros, including tools that check for affected packages etc) and figuring out how to ship updates to end users as soon as possible.

**cabal has no support for this**. And we just got a new security response team that is still working on their processes and workflow.

If you bundle crypto libraries, please demonstrate how you’re tracking upstream vulnerabilities and inform end users.

---

<div class="post-metadata">

**Author:** ![ApothecaLabs](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/apothecalabs/32/3215_2.png) [@ApothecaLabs](https://discourse.haskell.org/u/ApothecaLabs)\
**Post date:** [February 18, 2024, 6:20pm UTC](https://discourse.haskell.org/t/botan-bindings-devlog/6855/147 "2024-02-18T18:20:20Z")

</div>

# Update: botan 0.0.1 package candidate imminent

Whew! It’s been an intense couple of days, now that `botan-bindings` and `botan-low` are [published to hackage](http://discourse.haskell.org/t/ann-botan-bindings-botan-low-0-0-1-0-released/8800). Additionally, the [round 2 funding proposal](https://github.com/haskellfoundation/tech-proposals/pull/64) has been updated to provide more details on the intended trajectory for the next several months.

Of course, now that the excitement has settled down, we are back to focusing on our next goal: getting `botan` to package candidate status, and soon after to release. Here lies the issue that I’ve been gnawing on for the last few days:

Our initial ADT-based approach to managing algorithms has turned out to be insufficient. Cryptographic typeclasses were something that was in the original proposal, but they were removed to reduce scope; however, they’ve turned out to be necessary in the long term.

It is going to take time to develop the proper solution of typeclasses and data families in order to build per-algorithm gold-standard modules, and I’d like to get `botan` live before then. Now, there’s still:

1. the problem of the insufficiency of the ADT interface, which must be dealt with before we publish a `0.0.1`, and

2. the question of whether to prune the typeclasses / data families / per-algorithm gold-standard modules from said initial release because they are still being developed, and add quite a bit of inertia - I’d rather present something comparable to `z-botan` first before\* going after higher-level targets.

> \* I’m trying to keep my prioritization straight

I do have a solution to #1, which I feel may suffice. Our issue is thus:

```haskell
-- We have some set of algorithms for a common operation
data Hash
    = CryptoHash CryptoHash
    | Checksum Checksum

-- We have nested ADTs because some functions require a specific subset of algorithms
data CryptoHash
    = SHA3 SHA3
    | ...

data Checksum
    = Adler32
    | ...

-- Algorithms may themselves variants, and so the nesting gets deeper
data SHA3
    = SHA3_512
    | ...

-- An algorithm for one operation may be a component in another operation, but this is dangerous:
data MAC
    = HMAC Hash -- Wrong!

-- The component algorithm may require a specific subset:
data MAC
    = HMAC CryptoHash -- Right!

-- This all turns out to be unwieldy in practice, and leads to ridiculous stacks of wrappers:
hmac_sha3_512 = HMAC $ CryptoHash $ SHA3 $ SHA3_512

```

Typeclasses are the obvious long-term solution, but will take time. What’s the interim solution? Let’s ask ourselves, _“What did z-botan do?”_

Well, they flattened the ADT to an enumeration, and threw an exception if an incorrect algorithm was used. I think we can do _slightly better…_

```haskell
-- Flatten the ADTs, have newtype wrappers for specific subsets!
data Hash
    = SHA3_512
    ...
    | Adler32

-- Then, it's up to each subset to define their wrapper and smart constructors
newtype CryptoHash = MkCryptoHash { unCryptoHash :: Hash }

-- We'll use smart constructors instead of just throwing exceptions like z-botan
cryptoHash :: Hash -> Maybe CryptoHash
cryptoHash SHA3_512 = Just $ MkCryptoHash SHA3_512
...
cryptoHash _ = Nothing

unsafeCryptoHash :: Hash -> CryptoHash
unsafeCryptoHash h = fromJust $ CryptoHash h

newtype Checksum = MkChecksum { unChecksum :: Hash }

checksum :: Hash -> Maybe Checksum
checksum Adler32 = Just $ MkChecksum Adler32
...
checksum _ = Nothing

unsafeChecksum :: Hash -> Checksum
unsafeChecksum h = fromJust $ Checksum h

-- Algorithm families can get the same treatment if necessary
newtype SHA3 = MkSHA3 { unSHA3 :: Hash }

-- This means that we have at most 1 wrapper, from enumeration to specific subset
hmac_sha3_512 = HMAC (unsafeCryptoHash SHA3_512)

```

It’s not perfect, but it gives us the type safety we need, without impairing the ergonomics too much while we work on the proper typeclasses. A happy medium!

There’s no update to the repo quite yet as I’m still doing some cleanup while applying this, but once that is done, the `botan 0.0.1.0` package candidate will be going up.

So then, this leaves the question of #2 - to prune or not to prune? Do we elide the in-progess abstractions to keep focus on the core modules?

---

<div class="post-metadata">

**Author:** ![arybczak](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/arybczak/32/2527_2.png) [@arybczak](https://discourse.haskell.org/u/arybczak)\
**Post date:** [February 18, 2024, 7:26pm UTC](https://discourse.haskell.org/t/botan-bindings-devlog/6855/148 "2024-02-18T19:26:30Z")

</div>

> [@ApothecaLabs](#):
>
> the question of whether to prune the typeclasses / data families

Please consider this bit carefully and try to avoid these as much as possible, even for the final interface. It looks like there’s potential to overengineer here and make it hard for clients of the library to figure out how to use the API as these abstractions can significantly obscure it.

---

<div class="post-metadata">

**Author:** ![ApothecaLabs](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/apothecalabs/32/3215_2.png) [@ApothecaLabs](https://discourse.haskell.org/u/ApothecaLabs)\
**Post date:** [February 18, 2024, 8:18pm UTC](https://discourse.haskell.org/t/botan-bindings-devlog/6855/149 "2024-02-18T20:18:23Z")

</div>

There is a long-term method to my madness; I am trying to keep the ergonomics of use in mind, but `botan` is primarily a cryptographic kitchen sink, and so it is my duty to expose the full complexity of every algorithm and primitive. `botan` is far closer to `crypton` than something like `saltine`.

However, I am planning for a user-friendly `saltine` -like interface as well, and I think your concerns align more closely there. The end goal is to expose a pure, idiomatic interface, but all of the mutable IO and machinery underneath is still necessary, and this is part of that important machinery, and not necessarily the final interface.

A few things to help address your concerns:

1. I am being sure to use data families and not type families; this significantly reduces strain on the compiler, as data families do not inhibit type inference at usage sites like type families do, and instead places the onus of effort on me to fulfill the boilerplate.

2. This was always going to be complex, no matter how I chose to express it, and having tried several ‘simpler’ routes, it turns out that while data families do have more initial overhead for development, their complexity for use grows much more slowly. In comparison, the ADT approach is easy to develop, and terrible to use.

3. I am also writing a series of high-level tutorials focusing on explaining the correct usage, which in most cases consists of using a single type application or explicit type annotation. This interface affords a great deal of flexibility and specificity, as I have been quite thorough.

The following lines are all valid and equivalent:

```haskell
sha3_512 "Fee fi fo fum!"
sha3 @512 "Fee fi fo fum!"
sha3 "Fee fi fo fum!" :: SHA3_512Digest
sha3 "Fee fi fo fum!" :: SHA3Digest 512
sha3 "Fee fi fo fum!" :: Digest (SHA3 512)
sha3 "Fee fi fo fum!" :: Digest SHA3_512
hash @(SHA3 512) "Fee fi fo fum!"
hash @SHA3_512 "Fee fi fo fum!"
hash "Fee fi fo fum!" :: SHA3_512Digest
hash "Fee fi fo fum!" :: SHA3Digest 512
hash "Fee fi fo fum!" :: Digest (SHA3 512)
hash "Fee fi fo fum!" :: Digest SHA3_512
-- 03a240a26674994a...

```

There is a great deal of freedom of choice, but from this we may expose a final, curated interface, eg by picking a particular idiom and emphasizing it in the tutorials.

1. The cryptographic typeclasses are being designed to expose a consistent, implementation-agnostic cryptographic interface and will eventually be lifted out into their own package with botan continuing to conform to it. This will eventually allow alternate backends to fulfill the required primitives, while allowing more complex implementation-agnostic concepts like merkle trees to be implemented without locking yourself to one backend library. This will also allow the final curated interfaces to be reused across backends, and is part of the long-term goal of a unified haskell cryptography ecosystem.

---

<div class="post-metadata">

**Author:** ![romes](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/romes/32/2912_2.png) [@romes](https://discourse.haskell.org/u/romes)\
**Post date:** [February 18, 2024, 9:01pm UTC](https://discourse.haskell.org/t/botan-bindings-devlog/6855/150 "2024-02-18T21:01:10Z")

</div>

> [@ApothecaLabs](#):
>
> The cryptographic typeclasses are being designed to expose a consistent, implementation-agnostic cryptographic interface and will eventually be lifted out into their own package with botan continuing to conform to it. This will eventually allow alternate backends to fulfill the required primitives, while allowing more complex implementation-agnostic concepts like merkle trees to be implemented without locking yourself to one backend library. This will also allow the final curated interfaces to be reused across backends, and is part of the long-term goal of a unified haskell cryptography ecosystem.

Honestly, I still think the best abstraction here is backpack. At least at a conceptual level, it simply feels like the right things.

I’d be happy to have a chat about it, even if just to put it on your map.

In practice, however, it may be that backpack is not a viable option due to Stack’s lack of support and HLS — on the other hand, it could be a strong motivation to implement support for it

---

<div class="post-metadata">

**Author:** ![ApothecaLabs](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/apothecalabs/32/3215_2.png) [@ApothecaLabs](https://discourse.haskell.org/u/ApothecaLabs)\
**Post date:** [February 18, 2024, 10:47pm UTC](https://discourse.haskell.org/t/botan-bindings-devlog/6855/151 "2024-02-18T22:47:01Z")

</div>

I do not at all oppose investigating the use of backpack to make swapping of implementation easier, but the ability to pull it out as an implementation-agnostic interface is merely a convenient side effect of being extremely stringent in acknowledging the unique properties of all of the various algorithms 😁

* * *

I feel as though I need to clarify something for the general audience, however, as there appears to be some wariness or misunderstanding of why the typeclasses are being developed:

The typeclass abstractions are still necessary within `botan` as a single package, in order to expose multiple algorithms for the same primitive in a type-safe manner without throwing exceptions, or pretending that algorithm variants don’t exist.

Many algorithms have unique knobs and levers, and it is only at the very end, when we process the plaintext, that they act similarly. `Digest MD5` is not the same type as `Digest (SHA3 512)`, and should not be considered equal, even if they were to contain the same bytes.

Some algorithm families are parameterized by a unique salt / identifier / tweak that is not necessarily bounded in size, and thus there may be an infinite number of instances to write manually. `Skein512 512 "foo"` takes two additional parameters compared to `MD5` - how are we to provide the additional arguments while providing a uniform interface?

Typeclasses were designed for this; the alternative is passing an algorithm witness around exactly like you might a typeclass implementation dictionary, while having to handle errors when people pass in a parameter that isn’t valid for a given algorithm / operation, which would be normally be handled by the type system via typeclass constraints.

I’d be writing the newtypes anyway for per-algorithm type-safety - take a look! The data families are effectively free and the typeclasses just codify everything that I’m doing anyway.

We have our data family and typeclass - not scary at all 🙂 :

```haskell
data family Digest hash

class (Eq (Digest hash), Ord (Digest hash)) => Hash hash where
    hash :: ByteString -> Digest hash

```

We could implement simple concrete types for our algorithm this way, without the typeclass and data families:

```haskell
newtype MD5Digest = MkMD5Digest { getMD5ByteString :: ByteString }
    deriving newtype (Eq, Ord)

md5 :: ByteString -> MD5Digest
md5 = MkMD5Digest . Botan.hash Botan.md5

```

However, conformance to the typeclasses is effectively free

```haskell
-- Free
data MD5

-- Free by replacing "MD5Digest" with "instance Digest MD5"
newtype instance Digest MD5 = MkMD5Digest { getMD5ByteString :: ByteString }
    deriving newtype (Eq, Ord)

-- Unchanged
md5 :: ByteString -> MD5Digest
md5 = MkMD5Digest . Botan.hash Botan.md5

-- Free
type MD5Digest = Digest MD5

-- Free
instance Hash MD5 where
    hash :: ByteString -> Digest MD5
    hash = md5

```

Something with a few type parameters isn’t much harder.

```haskell
data SHA3 (n :: Nat)

-- Pardon this atrocity
type SHA3Size (n :: Nat) = (KnownNat n, (n == 224 || n == 256 || n == 384 || n == 512) ~ True)

newtype instance Digest (SHA3 n) = MkSHA3Digest { getSHA3ByteString :: ByteString }
    deriving newtype (Eq, Ord)

instance (SHA3Size n) => Hash (SHA3 n) where
    hash :: ByteString -> Digest (SHA3 n)
    hash = sha3

-- The only actual work involves type literals
sha3 :: (SHA3Size n) => ByteString -> Digest (SHA3 n)
sha3 = MkSHA3Digest . Botan.hash h where
        n = fromInteger $ natVal $ Proxy @n
        h = fromJust $ Botan.sha3 

-- We still export user-friendly functions at the end
sha3_512 :: ByteString -> Digest (SHA3 512)
sha3_512 = sha3 @512

```

I want to stress that these typeclasses aren’t _replacing_ anything, they’re only _augmenting_. I hope this gives a better idea as to the reasoning behind my approach.

---

<div class="post-metadata">

**Author:** ![romes](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/romes/32/2912_2.png) [@romes](https://discourse.haskell.org/u/romes)\
**Post date:** [February 18, 2024, 11:16pm UTC](https://discourse.haskell.org/t/botan-bindings-devlog/6855/152 "2024-02-18T23:16:44Z")

</div>

Yes yes yes! That does clarify things, thank you.

That example is quite good. Looking forward to seeing more of this work

---

<div class="post-metadata">

**Author:** ![Vlix](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/vlix/32/1551_2.png) [@Vlix](https://discourse.haskell.org/u/Vlix)\
**Post date:** [February 19, 2024, 1:39am UTC](https://discourse.haskell.org/t/botan-bindings-devlog/6855/153 "2024-02-19T01:39:20Z")

</div>

I think instead of the atrocity, the following might be more helpful:

```haskell
type family IsSHA3Size n where
    IsSHA3Size 224 = ()
    IsSHA3Size 256 = ()
    IsSHA3Size 384 = ()
    IsSHA3Size 512 = ()
    IsSHA3Size _ = TypeError "Make this a custom type error that indicates what the allowed numbers are"

type SHA3Size (n :: Nat) = (KnownNat n, IsSHA3Size n)

```

This way the error message will be a lot more helpful.

---

<div class="post-metadata">

**Author:** ![ApothecaLabs](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/apothecalabs/32/3215_2.png) [@ApothecaLabs](https://discourse.haskell.org/u/ApothecaLabs)\
**Post date:** [February 19, 2024, 9:55pm UTC](https://discourse.haskell.org/t/botan-bindings-devlog/6855/154 "2024-02-19T21:55:13Z")

</div>

# Update: botan 0.0.1.0 package candidate uploaded!

As promised, it’s here:

- [botan: High-level Botan bindings](https://hackage.haskell.org/package/botan-0.0.1.0/candidate)

There’s still a good bit of work to be done before release, but I’ll be giving it the same level of love that `botan-bindings` and `botan-low` got while they were a package candidate - which was a lot.

First up, I’ve flattened the algorithm types for most operations ([see issue #1 from earlier](http://discourse.haskell.org/t/botan-bindings-devlog/6855/147)) with an overall positive result.

It is really visible in something like [Botan.Cipher](https://hackage.haskell.org/package/botan-0.0.1.0/candidate/docs/Botan-Cipher.html) where we both have specific subsets that we need to deal with (Cipher vs AEAD), while also taking specific subsets of other operations as arguments (BlockCipher vs BlockCipher128). This new method is proving to be significantly better to use, so I’ll be finishing up and applying to the remaining operation / algorithm data types as necessary.

Secondly, I’ve decided to **not** elide the cryptography typeclasses from the 0.0.1 release ([see issue #2 from earlier](http://discourse.haskell.org/t/botan-bindings-devlog/6855/147)), but will still be postponing their continued development until after the 0.0.1 release, as to stay focused on the immediate needs - priortization! 🙃

[The repo](https://github.com/apotheca/botan) has been updated

---

<div class="post-metadata">

**Author:** ![ApothecaLabs](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/apothecalabs/32/3215_2.png) [@ApothecaLabs](https://discourse.haskell.org/u/ApothecaLabs)\
**Post date:** [March 1, 2024, 6:06pm UTC](https://discourse.haskell.org/t/botan-bindings-devlog/6855/155 "2024-03-01T18:06:58Z")

</div>

# Back in Action after getting some Rest

After getting `botan-bindings` and `botan-low` to the initial `0.0.1` release and `botan` to [package candidate](https://hackage.haskell.org/package/botan-0.0.1.0/candidate) status, I found myself in need of a bit of a break - both because I needed to pull back and get a bird’s eye view of it, and because I’ve been working on this project almost non-stop for 8 months now and everyone deserves a bit of vacation now and then. 😴

Now that’s over, and it is time to get back in action! As this project transitions to the next phase of its life cycle, I’ve been writing an official Haskell Cryptography Group milestone blog post and call-for-users, taking into account feedback on the project and the round 2 funding proposal (which I am also still working on 🙂). I’ll be discussing the history of this project and how it all started, what we’ve accomplished so far, what feedback we’ve heard / users want, and what flag we’ve planted on the horizon as our goal, as well as concrete details on the specific things we wish to accomplish next.

You can expect regular updates to resume Monday next week!

* * *

Minor note: The project has now officially transferred ownership to the Haskell Cryptography Group, and as planned, the repository been moved:

> **[GitHub - haskell-cryptography/botan: Haskell bindings for the Botan cryptography...](https://github.com/haskell-cryptography/botan)**
>
> Haskell bindings for the Botan cryptography library

---

<div class="post-metadata">

**Author:** ![ApothecaLabs](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/apothecalabs/32/3215_2.png) [@ApothecaLabs](https://discourse.haskell.org/u/ApothecaLabs)\
**Post date:** [March 6, 2024, 4:36pm UTC](https://discourse.haskell.org/t/botan-bindings-devlog/6855/156 "2024-03-06T16:36:49Z")

</div>

A more sizeable update and proper First Milestone blog is coming soon 🙂 In the meantime, please enjoy this sneak peek at something I had fun implementing while on the break!

 ![Screenshot 2024-03-04 at 4.50.42 PM](https://us1.discourse-cdn.com/flex002/uploads/haskell/original/2X/a/a7b9fc0b661c5d5e21115ed876314e2b27803a06.jpeg)

_Just updating some old code to use `botan-low`…_

---

<div class="post-metadata">

**Author:** ![ApothecaLabs](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/apothecalabs/32/3215_2.png) [@ApothecaLabs](https://discourse.haskell.org/u/ApothecaLabs)\
**Post date:** [April 1, 2024, 9:05pm UTC](https://discourse.haskell.org/t/botan-bindings-devlog/6855/157 "2024-04-01T21:05:52Z")

</div>

# Returning from Absence.

I underestimated how much rest I needed, but in the words of Granny Weatherwax “I ate’nt dead”.

This last month has been half taking-a-break, half writing out the milestone blog and plans for the future, and half trying to figure out how to enable that future. For the moment, things are out of my hands, so instead, I’m going to do what I do best, which is the code, and update the devlog.

Things that have changed in the last few weeks:

- Cryptographic typeclasses have been temporarily moved to its own branch to focus on releasing `botan`
- Minor improvements to utility functions and error handling
- Botan.RNG significantly reworked and cleaned up
- Botan.KDF, PwdHash, HOTP, TOTP are now release-ready and have tutorials and explanations
- Stable implementation errors in `botan_pwdhash_timed` are now handled properly - see [[…] confusing param mapping between pwdhash and pwdhash\_timed](https://github.com/randombit/botan/issues/2144)
- A minor update to `botan-bindings` and ` botan-low` may be necessary to improve constants and organization of named elliptic curves, logarithm groups, and raw algorithm modes.

This isn’t pushed yet - I’ll let you known when it is.

---

<div class="post-metadata">

**Author:** ![Axman6](https://avatars.discourse-cdn.com/v4/letter/a/ce73a5/32.png) [@Axman6](https://discourse.haskell.org/u/Axman6)\
**Post date:** [April 8, 2024, 2:57am UTC](https://discourse.haskell.org/t/botan-bindings-devlog/6855/158 "2024-04-08T02:57:20Z")

</div>

Hey @ApothecaLabs, is there a good place to chat with you/the botan devs about development? I’m currently working through seeing how feasible it would be to swap crypton for botan in amazonka, and I’m running into a lot of issues with the design of the hashing API. I was wondering if there’s a good IRC channel or somewhere to chat - here feels like the wrong place but I can do that if needed.

Quick summary of the issues:

- There’s no pure, incremental hashing API (you probably say [my GitHub issue](https://github.com/haskell-cryptography/botan/issues/15)), which makes writing things like pure streaming sinks difficult - `Monad m => Conduit ByteString () m (Digest a)` can’t currently be written, it needs `MonadIO` instead (and with the current assumption that all hash state will be mutable updated, there could be bugs in how something that would get used, depending on `m`).  
_As an aside here, linear types would make this API both pure and quite nice to work with - it probably shouldn’t be the only interface, but it would avoid the required copying of the context that a pure API would necessitate_
- The `Digest` data family is difficult to work with generically, it’s nearly impossible to write something that works on the wrapped `ByteString`s in functions with types like `Hash a => Digest a -> ByteString`. I’d love to see a function `digestBytes :: Digest a -> ByteString` added to the `Hash` class, at the very least.
- I’ve also grown quite fond of `memory`'s `ByteArrayAccess` class and its ability to abstract types like digests soo they can easily be hashed too. I think that cryptonite got a lot write with its use of `memory`, forcing everything to be a `ByteString` limits things a lot for production code.

I’m sure I’ll run into more, but this is where I am at the moment. I’m aware that `botan` is unreleased, but wanted to at least investigate whether it’ll be usable in Amazonka. At the moment there isn’t a clear path that wouldn’t affect performance.

I should also mention that I’m happy to contribute the development of the changes I’d like to see - I should make a fork start playing around with ideas.

---

<div class="post-metadata">

**Author:** ![jackdk](https://avatars.discourse-cdn.com/v4/letter/j/9f8e36/32.png) [@jackdk](https://discourse.haskell.org/u/jackdk)\
**Post date:** [April 8, 2024, 6:14am UTC](https://discourse.haskell.org/t/botan-bindings-devlog/6855/159 "2024-04-08T06:14:02Z")

</div>

Since we’re on the topic of Amazonka, I should also say that I’d love to see `botan` become the cryptography library that it rests on, but there are a few things beyond @Axman6’s exploration that I’d also like to see happen:

1. The changes to support FFI really should make it into `botan` upstream, so that we’re depending on the same vetted code as everyone else.
2. The Haskell packages and the native library should have a good build/download story for all major platforms. I don’t want to accidentally cut off users on e.g., Windows if there’s no easy way to get them the native deps they need. (Also, AFAICT, Botan 3 is only in Debian experimental.)
3. `botan-bindings` should not have to vendor any source code. I’m leery of packages which vendor source code, especially in the cryptography and security spaces.

These sound like pretty big asks to me, so I want to get them on the table now as a starting point for discussion. Maybe I’m being too dogmatic, or maybe they’re easier than I think, but let’s talk about them at least.

---

<div class="post-metadata">

**Author:** ![hasufell](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/hasufell/32/1250_2.png) [@hasufell](https://discourse.haskell.org/u/hasufell)\
**Post date:** [April 8, 2024, 6:36am UTC](https://discourse.haskell.org/t/botan-bindings-devlog/6855/160 "2024-04-08T06:36:19Z")

</div>

> [@jackdk](#):
>
> The Haskell packages and the native library should have a good build/download story for all major platforms. I don’t want to accidentally cut off users on e.g., Windows if there’s no easy way to get them the native deps they need. (Also, AFAICT, Botan 3 is only in Debian experimental.)

As already explained elsewhere: [[Haskell Cryptography Group] Botan: The First Milestone - #14 by hasufell](http://discourse.haskell.org/t/haskell-cryptography-group-botan-the-first-milestone/9018/14)

3.3.0 is in debian experimental and oddly enough, windows is likely the least problematic platform.

I tried to create a botan-clib package, but the build system is a disaster: which source files to compile depends on platform and processor features that are detected during “configure”. You’ll have to map those things manually in the cabal file and create flags for all the cpu features, because the c source files used need to be encoded in the cabal file. And then review the build system changes on every version bump.

These are things that e.g. a gentoo or nixpkgs developer would be comfortable to do, but it isn’t at all trivial. And you lose the automagic detection of features.

Another way might be to abuse custom setup really hard, but that’s not gonna be very popular or easy either.

[Previous page](https://discourse.haskell.org/t/botan-bindings-devlog/6855.md?page=7)

[Next page](https://discourse.haskell.org/t/botan-bindings-devlog/6855.md?page=9)