how intrusive would be to limit the use of crypto API to that of TweetNaCl?

[x368]

Compatibility with TweetNaCl would make the core both more portable and more compact (resulting in either a smaller dependency or fewer dependencies, the crypto code could be included at a very small cost).

If really desired for performance, which I doubt, the packager could always replace tweetnacl with libnacl or libsodium which means no new constraints would be introduced.

What I notice in toxcore is its reliance on sha256. This is incompatible with TweetNaCl which only supports sha512. Would it be possible to "move forward" with tox to sha512? This would be nice as a future-safety measure too. Or as a last resort truncate the extra data if you believe sha512 is too long?

Besides portability the important gain would be the increase of the auditability of the crypto library.

[irungentoo]

I could replace the sha256 with using only the first 256 bits of sha512 but tweetNaCl is too slow to be of any use (I built toxcore with it once to test something).

[x368]

Your result sounds quite unexpected. Even Elliptic Curves are relatively lightweight nowadays (especially if the machine is supposed to cope with video coding). Are you sure this was tweetnacl fault, not some other circumstance?

What I read at different places about tweetnacl is that it is quite fast. I expect it to be on par with nacl-without-assembler.

I have been testing and using tox with nacl specially compiled to the most generic x?86 code from reference C files only - without any excessive delays whatsoever, on any hardware where I tested. The only bottleneck I ever observed was not crypto-related but video coding on low end machines.

In the end, targeting tweetnacl does not in any way preclude substituting it by fully optimized libnacl/sodium when necessary, which is impossible the other way around.

Of course sha512 is more expensive than sha256 but I would be surprised if this creates noticeable delays, unless you apply it in lots of iterations and all the time (?)

I would be happy to build and test a client with tweetnacl on various (Intel) hardware, including <1GHz. Would such a build be interoperable with the existing clients (does the protocol allow changing the hash being used?)? Otherwise I can test between two modified clients and report. What is worth to check / measure?

It would be best if you have a corresponding patch or otherwise if you can direct me to the source files and functions which are to be affected by such a change.

[GrayHatter]

closing as stale soon unless this get's some updates