This is the coding style
https://github.com/irungentoo/toxcore/commit/84c28337d248bad...
this is openssl all over again
https://github.com/irungentoo/toxcore/commit/1d6c3934736c369...
> memcpy(packet + 1, &con->ping_request_id, sizeof(uint64_t));
Copying multi-byte values into a network packet is a typical error made by novice developers - this will bite you hard as soon as somebody compiles the code on a Big Endian machine. Even if you might get away with this on opaque elements like a ping ID, the general approach should not be followed.
In all cases where it does matter, the values are converted.
Tox has been confirmed working on big endian machines by many people.
I'm not sure what you're trying to point out with those links. How is this related to openssl?
Read the code. Dig through the commit logs. This is the wrong choice on about every level. The best encryption won't save you when you have code like this.
What did we not learn about OpenSSL?
Writing secure network code in an non-safe language is something that shouldn't be taken lightly. Given the nature of the commits it is hard to comprehend that this product will ever achieve its stated aims.
It is secure by side effect, not proof.
I have extensive C experience, and I have looked through the code. While there have been plenty of bug fixes in the commit log - as is to be expected for a project of this scope in its pre-alpha/alpha stages - I have not seen anything that resembles a security threat, much less something as serious as the heartbleed bug that you keep bringing up for some reason.
At this point I have to conclude that you're either a troll with too much time on your hands, or being paid to spread FUD.
It's quite readable and has yet to tangle itself in the ifdef mess that is openssl.
They should have made the protocol, vetted the protocol and made a PoC implementation in a safe language.
Cryptographers and secure protocol designers can't help out if they are noodling along banging out the implementation while designing it.