<div dir="auto">There isn't one problem. Different situations require different things. Wrapping makes fromInteger a ring homomorphism, which makes a lot of basic arithmetic intuition "just work". But fromIntegral is a strange and lawless beast, as well as a nasty potential optimization pitfall.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Aug 9, 2020, 11:44 PM Carter Schonwald <<a href="mailto:carter.schonwald@gmail.com">carter.schonwald@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div dir="auto">The real issue here isn’t fromintrgral, but that everything defaults to wrapping semantics </div></div><div dir="auto"><br></div><div dir="auto">Adding variants that do signaling/exceptions  and clipping Variants Of finite word/Int data types rather than just wrapping is the right path forward. </div><div dir="auto"><br></div><div dir="auto"><br></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Aug 8, 2020 at 2:20 AM Herbert Valerio Riedel <<a href="mailto:hvriedel@gmail.com" target="_blank" rel="noreferrer">hvriedel@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Btw, subtle correctness issues hiding throughout the vast monolithic<br>
codebase like these were part of the reason (other reasons are<br>
explained in <a href="https://old.reddit.com/r/haskell/comments/5lxv75/psa_please_use_unique_module_names_when_uploading/dbzegx3/" rel="noreferrer noreferrer" target="_blank">https://old.reddit.com/r/haskell/comments/5lxv75/psa_please_use_unique_module_names_when_uploading/dbzegx3/</a>)<br>
why cryptohash/cryptonite/foundation has been banned from our<br>
codebases not the least because it's hopeless to get something like<br>
cryptonite through formal certification for security critical<br>
applications. At the time the author made it clear he didn't welcome<br>
my bug reports (later I learned the author was merely peculiar as to<br>
what they consider an actual bug worth reporting). And whenever I<br>
mentioned this in the past on reddit as a PSA, I got defensive<br>
reactions and disbelief from certain people who were already invested<br>
in the cryptonite ecosystem and I was accused of spreading unfounded<br>
FUD... and so I stopped bringing up this kind of "heresy" publicly.<br>
<br>
However, as you can see in<br>
<br>
<a href="https://hackage.haskell.org/package/cryptohash-sha256/changelog" rel="noreferrer noreferrer" target="_blank">https://hackage.haskell.org/package/cryptohash-sha256/changelog</a><br>
<br>
this particular 32-bit overflow issue was one of the critical bugfixes<br>
I ran into and repaired in the very first release right after the<br>
initial-fork-release back in 2016. It's astonishing it took over 4<br>
years for this bug to keep lingering in cryptonite/cryptohash before<br>
it was detected. You'd expect this to have been detected in code<br>
audits performed by Haskell companies that actively promote the use of<br>
cryptonite early on.<br>
<br>
On Sat, Aug 8, 2020 at 5:09 AM Niklas Hambüchen via Libraries<br>
<<a href="mailto:libraries@haskell.org" target="_blank" rel="noreferrer">libraries@haskell.org</a>> wrote:<br>
><br>
> Today I found another big bug caused by `fromIntegral`:<br>
><br>
>     <a href="https://github.com/haskell-crypto/cryptonite/issues/330" rel="noreferrer noreferrer" target="_blank">https://github.com/haskell-crypto/cryptonite/issues/330</a><br>
><br>
> Incorrect hashes for all hash algorithms beyond 4 GiB of input. SHA hash collisions in my productions system.<br>
><br>
> Restating what I said there:<br>
><br>
> * Until we deprecate fromIntegral, Haskell code will always be subtly wrong and never be secure.<br>
> * 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.<br>
> * 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.<br>
><br>
> The wrong code,<br>
><br>
>     hashInternalUpdate ctx d (fromIntegral $ B.length b)<br>
><br>
> exists because it simply does not look like wrong code. In contrast,<br>
><br>
>     hashInternalUpdate ctx d (fromIntegralWrapping $ B.length b)<br>
><br>
> does look like wrong code and would make anyone scrolling by suspicious.<br>
><br>
> We can look away while continuing to claim that Haskell is a high-correctness language, or fix stuff like this and make it one.<br>
> _______________________________________________<br>
> Libraries mailing list<br>
> <a href="mailto:Libraries@haskell.org" target="_blank" rel="noreferrer">Libraries@haskell.org</a><br>
> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank" rel="noreferrer">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div></div>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank" rel="noreferrer">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div>