mbedTLS VS libsodium

It's work in progress: https://github.com/Mbed-TLS/mbedtls/blob/development/docs/ar...

Newer version have okay-ish support, I'd guess the next OpenWRT release will have it again.

It's related to this Mbed-TLS issue

i've used the entropy generator from MbedTLS which uses multiple sources of randomness, and seeding it additionally with the chip's mac address and the free heap size at time of creation. it would take a lot to recreate all that "noise" consistently, but i'm open to suggestions on how to make it more secure

However on the github page and assuming I found the right source - and this is a HUGE ASSUMPTION - there is a section on porting the library to other platforms.

Rebean is a single executable written in ANSI C that embeds Lua 5.4, MbedTLS and SQLite. The crazy thing about this is that it is a C binary that runs on six operating systems without any cross compiling thanks to leveraging Justine Tunney's cosmopolitan.

it looks like the commands are all built under https://github.com/Mbed-TLS/mbedtls/tree/development/programs and the arch mbedtls package does some extra work to rename them and copy them into /usr/local/bin: https://github.com/archlinux/svntogit-community/blob/packages/mbedtls/trunk/PKGBUILD#L55

If you want to see a real implemention of arbitrary sized integer math, mbedTLS is a great example:

https://github.com/ARMmbed/mbedtls/blob/development/library/...

All of the ECC code in that library relies on this code, which can be accelerated by dedicated hardware.

mbed TLS - Another crypto implementation. Apache-2.0

Definitely, FreeRTOS + LwIP + Mbed TLS is a fairly common combo these days, and Mbed TLS has hardware acceleration where possible.

Libsodium has been around for a while, so probably the reason it was posted is that version 1.0.19 was just released: https://github.com/jedisct1/libsodium/releases/tag/1.0.19-RE...

Updated NuGet and Swift packages are going to be uploaded soon.

AEGIS-128X and 256X are not there yet, but if you need them, they are available in libaegis: https://github.com/jedisct1/libaegis

All the code from libaegis will eventually be merged into libsodium, including the incremental update API which is especially useful for TLS.

To version the dependency you can check the current stable tree in git and save the date and git hash.

To address both of these vulnerabilities, you should instead use a library that handles these sharp edges for you. A well received library in the security and cryptography communities is libsodium. It has high level functions that handle password hashing and data encryption for you, reducing the risk that you introduce vulnerabilities in your code, such as you have here.

In general, cryptography is really hard. So for example, an attacker could construct a message that if you signed would leak information, ie it reduces the space of possible keys such that it can be brute forced. I’m not entirely sure if you could do that with a transfer function. But it’s certainly possible. That said, there are a ton of smart devs trying to prevent that as well so I’m not assuming anything here. But prudent practices are likely good to follow. Be very careful calling anything from your cold wallet etc. Use disposable keys for anything a bit risky. I took a sec to google an example and this is the closest I could find. https://github.com/jedisct1/libsodium/issues/170

Hi everyone! I'm learning Rust while on a break between jobs, and as I'm particularly interested in interfacing Rust with C and in cryptography, I've decided to write a wrapper around libsodium (https://github.com/jedisct1/libsodium) in Rust. This is purely a hobby project and I probably won't ever release it as there are already some open-source Rust bindings available for the library.

Can anyone recommend between Librandombytes and libsodium ramdombytes?

https://github.com/jedisct1/libsodium/tree/master/src/libsod...