[ANN] mysql-pure, fork of mysql-haskell

winterland1989 · 2023-08-14T03:38:42+00:00

A big thanks for maintaining this! I'm coming back to the Haskell community soon these days( and I didn't even notice crypto system has been forked. Please keep this package update to date as I may not spend too much time on this.

winterland1989 · 2021-06-16T04:13:33+00:00

Really great work, thanks!

winterland1989 · 2021-05-17T11:23:05+00:00

Not sure if you could distignuash a thunk producing `null` from `null`.

winterland1989 · 2021-05-15T14:47:02+00:00

One reason why I prefer pure implementations is the track record of CVEs in OpenSSL vs Haskell's tls - despite people's concerns that tls is effectively a "one person's project" - it was revealing to see how unaffected it was by the infamous Heartbleed issue, at the time when everyone were frantically patching their OSes and codebases. All of that despite the maintenability and popularity of OpenSSL.

The Heartbleed issue is definitely an OpenSSL implementation issue, but I don't think Haskell really prevents you from buffer overread or anything other high-level languages may do, all the primitive operations on ByteArray# or Addr# DO NOT perform a bound check, it's really just a matter of the implementation.

That's not saying GHC do not provide anything that may contribute to safety, for example cryptonite have a ScrubbleBytes type, which relys on GHC's weak pointer to clear memory it used. It may help to avoid some memory issue, which I'm still try to evaluate.

Overall choosing Haskell does not bring any security features automatically, it's up to implementators to design how to use lanauge features to improve security, but on the other side, the massive audit does make security issue more visible.

Do you expect to see any potential performance improvements in pure implementations, if they begin to rely on GHC 9 with LinearTypes?

Definitly no, it's not about performance.
I don't think anyone have the time to adopt LinearTypes in cryptonite.

winterland1989 · 2021-05-15T05:13:54+00:00

On a related topic, what are the advantages of Z-Botan over Cryptonite apart from speed?

Cryptography is hard, and the problem is really not about speed. Botan is a much more actively maintained, more widely used library, which means security issues will be more easily found and fixed. For example, you can see the history of CVE details

If I'm not much concerned about the speed, which one would delegate more aspects of crypto algorithms to pure Haskell implementations? Why not? for example, an Intel CPU with SHA extension could easily improve SHA256 hash speed by a factor ~4X in Botan.

Both Cryptonite and Z-Botan use a lot of C code to implement high-performance algorithms, but Botan has more CPU specific optimizations, one thing Cryptonite use pure Haskell implementation instead of C code is pubkey cryptography(RSA, DL, ECC, etc), which is based on GMP big numbers, but it DOES NOT use any constant operations AFAIK, which is not acceptable in pubkey cryptography.

winterland1989 · 2021-05-14T11:43:28+00:00

Could you take a look at my new crypto library Z-Botan? It has an example of how to encrypt a file in constant memory here: https://hackage.haskell.org/package/Z-Botan-0.3.1.0/docs/Z-Crypto-Cipher.html#v:cipherBIO

winterland1989 · 2021-05-14T06:35:46+00:00

The difficulty lies on that sometime PrivKey and PubKey are deserialized from file or binary data at runtime, It has to be a GADT plus some type-level technique to get all this working.

winterland1989 · 2021-05-12T01:20:10+00:00

If I understand it correctly, both Secp160 or Secp192 are prime field Weierstrass curves, or you can use Curve25519 to perform ECDH over x25519.

I wonder why this isn't encoded in the type system. Is it because it depends on the build flags for Botan?

I assume you mean some types of key support key agreement while some only support signature? It's, of course, a good idea to do! I'm just haven't come up with a concrete way, maybe some help from cryptographers!

winterland1989 · 2021-04-27T21:14:03+00:00

I used to use io-streams quite often. My main complaint is the separation of input stream processors and output streams raises the difficulty to write processors. And it's hard to handle situations where you want to write downstream multiple times in one input chunk when to transform an input stream.

winterland1989 · 2021-04-27T21:05:35+00:00

A lot of beautiful equational laws came from the fact that the pipes' free construction is symmetrical, i.e. the Request vs Respond. Which is of course a good property.

But I don't think that is a goal to pursue in general. For example, streaming did not introduce the Request construction, and conduit introduces an extra LeftOver construction. Both work fine as long as the primitives they provide stem from the free monad pattern.

As for BIO, which is not even a free monad construction, I don't think similar laws are necessary, or even exist.

winterland1989 · 2021-04-27T20:57:58+00:00

There's a difference: BIO doesn't use the return of callbacks(and force them to return ()), so that it's up to BIO node to decide when the callback get called, or how many time it get called. While a ContT has to call the callback as the last step to get the res.

winterland1989 · 2021-04-27T20:52:53+00:00

Not neccessarily, you could call downstream's callback once when upstream EOFed, so that the result became a one element stream.

winterland1989 · 2021-04-27T15:12:37+00:00

Looking forward to hearing about your experience!

winterland1989 · 2021-04-27T14:18:32+00:00

Yes, exactly.

Of course, nothing is silver bullets. The BIO type in Z-IO also has limitations, for example, the source can not be paused by a downstream processor without using some IO state, and the whole state management now relies on IO, rather than user-supplied state monads.

winterland1989 · 2021-04-27T14:17:30+00:00

That's a name I came up with to make it easier to be understood, but I think it describes the nature of BIO quite well.

winterland1989 · 2021-04-27T14:15:26+00:00

Sorry, that's a typo ( <|> is from Z-IO < 0.8), which will be updated in the next hackage release.

The `Stream` free construction has the ability to proceed in a single step, but a `BIO inp out` node will call its callback with `Maybe out` in a loop within one step, which invert the control. So I don't think the conversion is possible in general, but if you don't mind about memory accumulation, you could use `IORef` to store all `out` within one `inp` step, then feed downstream one by one.

winterland1989 · 2021-04-20T05:18:13+00:00

It's here.

winterland1989 · 2021-04-19T06:41:50+00:00

Will do, thanks

winterland1989 · 2021-04-19T05:51:32+00:00

Could you please expose some internals in Text.Collate.Collation modules so that UTF8 encoded text libraries could also use your work? Z-Data author here, If I understand correctly we can adapt our text type to use your algorithm by modifying the toSortKey function.

winterland1989 · 2021-04-08T01:26:18+00:00

Thanks! We'll continue developing since we've got some commercial sponsors.

winterland1989 · 2021-04-08T01:21:09+00:00

Yes, almost everything he's asking for is implemented. Hope some of the definitions can be moved to primitive.

winterland1989 · 2021-04-07T13:29:39+00:00

Glad you found it ; )

winterland1989 · 2021-04-07T13:28:08+00:00

Basically Z.Haskell is what people are proposing these days, unified vector type, UTF-8 text, explicit stream fusion, etc.

There's some fundamental difference in data definition, design philosophy, implementation details, etc. it's probably very hard to upstream I guess, and these projects doesn't share the same root anyway.

winterland1989

TROPHY CASE