Deprecating fromIntegral

[Herbert Valerio Riedel]

Btw, subtle correctness issues hiding throughout the vast monolithic
codebase like these were part of the reason (other reasons are
explained in https://old.reddit.com/r/haskell/comments/5lxv75/psa_please_use_unique_module_names_when_uploading/dbzegx3/)
why cryptohash/cryptonite/foundation has been banned from our
codebases not the least because it's hopeless to get something like
cryptonite through formal certification for security critical
applications. At the time the author made it clear he didn't welcome
my bug reports (later I learned the author was merely peculiar as to
what they consider an actual bug worth reporting). And whenever I
mentioned this in the past on reddit as a PSA, I got defensive
reactions and disbelief from certain people who were already invested
in the cryptonite ecosystem and I was accused of spreading unfounded
FUD... and so I stopped bringing up this kind of "heresy" publicly.

However, as you can see in

https://hackage.haskell.org/package/cryptohash-sha256/changelog

this particular 32-bit overflow issue was one of the critical bugfixes
I ran into and repaired in the very first release right after the
initial-fork-release back in 2016. It's astonishing it took over 4
years for this bug to keep lingering in cryptonite/cryptohash before
it was detected. You'd expect this to have been detected in code
audits performed by Haskell companies that actively promote the use of
cryptonite early on.

On Sat, Aug 8, 2020 at 5:09 AM Niklas Hambüchen via Libraries
<libraries at haskell.org> wrote:
>
> Today I found another big bug caused by `fromIntegral`:
>
>     https://github.com/haskell-crypto/cryptonite/issues/330
>
> Incorrect hashes for all hash algorithms beyond 4 GiB of input. SHA hash collisions in my productions system.
>
> Restating what I said there:
>
> * Until we deprecate fromIntegral, Haskell code will always be subtly wrong and never be secure.
> * If we don't fix this, people will shy away from using Haskell for serious work (or learn it the hard way). Rust and C both do this better.
> * If the authors of key crypto libraries fall for these traps (no blame on them), who can get it right? We should remove the traps.
>
> The wrong code,
>
>     hashInternalUpdate ctx d (fromIntegral $ B.length b)
>
> exists because it simply does not look like wrong code. In contrast,
>
>     hashInternalUpdate ctx d (fromIntegralWrapping $ B.length b)
>
> does look like wrong code and would make anyone scrolling by suspicious.
>
> We can look away while continuing to claim that Haskell is a high-correctness language, or fix stuff like this and make it one.
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries