# Status of cryptonite

**URL:** <https://discourse.haskell.org/t/status-of-cryptonite/7675>\
**Category:** Uncategorized\
**Created:** [September 25, 2023, 11:10am UTC](https://discourse.haskell.org/t/status-of-cryptonite/7675 "2023-09-25T11:10:00Z")\
**Posts on this page:** 12\
**Page:** 1

<div class="post-metadata">

**Author:** ![dxo](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/dxo/32/3683_2.png) [@dxo](https://discourse.haskell.org/u/dxo)\
**Post date:** [September 25, 2023, 11:10am UTC](https://discourse.haskell.org/t/status-of-cryptonite/7675/1 "2023-09-25T11:10:00Z")

</div>

I see that [`cryptonite`](https://github.com/haskell-crypto/cryptonite) has bee archived and set as read only on github. I don’t see anything on the readme discussing it’s development status.

Has the project been abandoned? Are there replacement libraries available? Is [GitHub - apotheca/botan: Low-level bindings for Botan](https://github.com/apotheca/botan) stable enough for production use yet?

---

<div class="post-metadata">

**Author:** ![tomjaguarpaw](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/tomjaguarpaw/32/1230_2.png) [@tomjaguarpaw](https://discourse.haskell.org/u/tomjaguarpaw)\
**Post date:** [September 25, 2023, 11:33am UTC](https://discourse.haskell.org/t/status-of-cryptonite/7675/2 "2023-09-25T11:33:17Z")

</div>

~~I’m surprised that there doesn’t seem to have been a change to the README before archiving, which explains the status, nor a public announcement about it. I’m sure there are very good reasons for archiving but it will probably leave a lot of people puzzled without further information!~~

EDIT: Never mind, I misunderstood what this repo was.

---

<div class="post-metadata">

**Author:** ![jaror](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/jaror/32/3271_2.png) [@jaror](https://discourse.haskell.org/u/jaror)\
**Post date:** [September 25, 2023, 11:45am UTC](https://discourse.haskell.org/t/status-of-cryptonite/7675/3 "2023-09-25T11:45:01Z")

</div>

The author has quit Haskell and archived all his repositories: [Ld. Vincent Hanquez 牛角包 (@vincenthz): "I have archived all my #haskell repositories (about 100 of packages/repos). time to let go." | nitter](https://nitter.net/vincenthz/status/1704395906374889934)

---

<div class="post-metadata">

**Author:** ![arianvp](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/arianvp/32/2077_2.png) [@arianvp](https://discourse.haskell.org/u/arianvp)\
**Post date:** [September 25, 2023, 11:46am UTC](https://discourse.haskell.org/t/status-of-cryptonite/7675/4 "2023-09-25T11:46:15Z")

</div>

Maintained fork is at [GitHub - kazu-yamamoto/crypton: lowlevel set of cryptographic primitives for haskell](https://github.com/kazu-yamamoto/crypton)

---

<div class="post-metadata">

**Author:** ![tomjaguarpaw](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/tomjaguarpaw/32/1230_2.png) [@tomjaguarpaw](https://discourse.haskell.org/u/tomjaguarpaw)\
**Post date:** [September 25, 2023, 11:55am UTC](https://discourse.haskell.org/t/status-of-cryptonite/7675/5 "2023-09-25T11:55:10Z")

</div>

Oh whoops, thanks. I misunderstood the organization name `haskell-crypto` to be [`haskell-cryptography`](https://github.com/haskell-cryptography). The latter _is_ an ongoing project, led by Hecate and others

---

<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:** [September 25, 2023, 1:13pm UTC](https://discourse.haskell.org/t/status-of-cryptonite/7675/6 "2023-09-25T13:13:57Z")

</div>

In addition to the `crypton` fork, there is also [another haskell-cryptography project](http://discourse.haskell.org/t/botan-bindings-devlog/6855/) to develop bindings to Botan (an audited third-party open-source cryptography library), that I started as a potential replacement / backend for `crypton/ite`'s handwritten C. It is not ready for deployment yet, though, so use of `crypton` is still suggested.

---

<div class="post-metadata">

**Author:** ![taylor](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/taylor/32/3147_2.png) [@taylor](https://discourse.haskell.org/u/taylor)\
**Post date:** [September 25, 2023, 4:14pm UTC](https://discourse.haskell.org/t/status-of-cryptonite/7675/7 "2023-09-25T16:14:19Z")

</div>

I was able to use the cryptonite library for aes-256-cbc symmetric encryption. There is a lot of knowledge and useful stuff in there. Think perhaps the scope is pushing up against the kitchen sink approach. In my opinion the type safety of crypto in pure haskell has huge payoff compared to bindings to other languages.

---

<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:** [September 25, 2023, 5:17pm UTC](https://discourse.haskell.org/t/status-of-cryptonite/7675/8 "2023-09-25T17:17:19Z")

</div>

> [@taylor](#):
>
> In my opinion the type safety of crypto in pure haskell has huge payoff compared to bindings to other languages.

I think the type safety of Haskell is a big payoff even for bindings to other languages, especially to an audited library. I suspect that `crypton/ite`’s lack of provenance contributes to the dearth of significant Haskell cryptography applications; simply put, it would not pass the necessary muster of security and regulatory requirements for many real-world use cases, even if it does return the correct values. Cryptographic provenance is not unlike functional purity in many ways, and I feel its value here cannot be understated.

This is not to dissuade anyone from pure Haskell crypto\* - rather, one of the reasons I am heavily interested in cryptographic typeclasses is to first make it irrelevant whether the backend is in pure haskell or bindings to another language, which would in turn also make it easier to audit.

\* _For one, I am interested in it too - I have this notion of cryptographic combinators which I think would work really well for pure haskell crypto, but I haven’t really developed it yet._

---

<div class="post-metadata">

**Author:** ![taylor](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/taylor/32/3147_2.png) [@taylor](https://discourse.haskell.org/u/taylor)\
**Post date:** [September 25, 2023, 5:39pm UTC](https://discourse.haskell.org/t/status-of-cryptonite/7675/9 "2023-09-25T17:39:26Z")

</div>

I think the aspiration of libraries that wrap FFI correctly is valid but it seems that a whole category of uncertainty is brought in by that choice. This opinion is enforced by my current frustration:

I’m currently trying to work with FFI bindings (to [secp256k1](https://github.com/bitcoin-core/secp256k1/blob/b314cf28334a91db2fe144d04f86077e2bfd7a25/include/secp256k1.h#L578)) and getting non-deterministic behavior that is breaking my brain. How can cryptographic functions work part of the time? And how can a pointer of one size/format work in one place and not another!

```haskell
verify :: Text -> Hex64 -> Hex32 -> IO Bool 
verify t sig pub = do 
    (hash32, 32) <- getPtr . un32 . hasht $ t
    (p64, 64) <- parsePub pub >>= getPtr . un64
    (sig64, 64) <- getPtr . un64 $ sig
    (== 1) <$> ecdsaVerify ctx sig64 hash32 p64

verify32 :: Text -> Hex64 -> Hex32 -> IO Bool 
verify32 t sig pub = do 
    (hash32, 32) <- getPtr . un32 . hasht $ t
    (p32, 32) <- getPtr . un32 $ pub
    (sig64, 64) <- getPtr . un64 $ sig
    (== 1) <$> ecdsaVerify ctx sig64 hash32 p32

```

[from here](https://github.com/AutonomousOrganization/futr2/blob/master/src/Nostr/Keys.hs) - These functions only differ in the key size and format. One works to validate the signature coming from my lightning node and the other works for signature from my own code and both only work part of the time. I’m feeling out of my depth.

---

<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:** [September 25, 2023, 6:22pm UTC](https://discourse.haskell.org/t/status-of-cryptonite/7675/10 "2023-09-25T18:22:19Z")

</div>

Oh boy do I empathize with you here. The FFI layer can definitely get in the way and make it difficult to determine whether a flaw is present in the FFI or the bound library, and I have experienced this with Botan.

However, in this case, your current frustration (at least, the non-determinism) ~~isn’t~~ maybe isn’t FFI-related, because (EC)DSA is not (necessarily) a deterministic algorithm 😬

You see, many cryptographic operations are non-deterministic, and require a random nonce that must never be reused (because it is a **n** _umber_ **o** _nly_ _used_ _o_ **nce** ).Ideally, this value should be exposed as an input, and the resulting function would be pure and deterministic. However, nonce mismanagement has caused _many_ security lapses, and so some libraries remove user nonce handling in one of two ways:

1. they make a variant that generates the nonce _non-deterministically_ and attaches it to the cryptext output, thus obviating user handling but also resulting in a different output each time

2. they make a variant that derives the nonce _deterministically_ based on the key and plaintext (eg, using HMAC) and attaches it to the cryptext output, resulting in the same output each time

> Note that attaching the nonce makes the cryptext longer, which may also be one of the issues you are experiencing.

This is all and well, except that sometimes the library doesn’t bother calling it something different, and so it can be hard to tell exactly which variant you are using - and this is on top of the fact that many algorithms already have _families_ that must be distinguished. This is one of the reason why test vectors are so important - it helps you know exactly which variant you are using.

[This stackexchange post](https://bitcoin.stackexchange.com/questions/83784/tiny-secp256k1-and-ecdsa-signing-determinism) may be relevant to your issues.

---

<div class="post-metadata">

**Author:** ![taylor](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/taylor/32/3147_2.png) [@taylor](https://discourse.haskell.org/u/taylor)\
**Post date:** [September 25, 2023, 6:33pm UTC](https://discourse.haskell.org/t/status-of-cryptonite/7675/11 "2023-09-25T18:33:52Z")

</div>

hmmm thanks for considering. libsecp256k1 should have deterministic signatures and regardless this is the verification which must be deterministic to be correct. I don’t want to hijack this thread anymore, I’ll just stare at my impossible test results and adjust my opinion about whether or not this is all just a stupid simulation anyway . . .

---

<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:** [September 25, 2023, 6:56pm UTC](https://discourse.haskell.org/t/status-of-cryptonite/7675/12 "2023-09-25T18:56:31Z")

</div>

Oof yeah that does sound wrong - best of luck figuring it out.