HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
jedisct1
libsodium
C2013–2023
jedisct1 / libsodium

libsodium

A modern, portable, easy to use crypto library.

51Distinct people
59Mentions
0Explicit recommenders
14.1KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

A modern, portable, easy to use crypto library.

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 12:45:45 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year59 dated mentions

Observed mentions: 2013-03-07 09:31:27 UTC to 2023-09-15 09:52:20 UTC.

0510152013-01-01 00:00:00 UTC to 2014-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments20132014-01-01 00:00:00 UTC to 2015-01-01 00:00:00 UTC (exclusive): 13 mentions; 4 submissions, 9 comments2015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 7 mentions; 0 submissions, 7 comments2016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 5 mentions; 0 submissions, 5 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 6 mentions; 1 submissions, 5 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 2 mentions; 1 submissions, 1 comments20182019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 6 mentions; 1 submissions, 5 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 7 mentions; 1 submissions, 6 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 5 mentions; 2 submissions, 3 comments2023

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20132013-01-01 00:00:00 UTC2014-01-01 00:00:00 UTC303
20142014-01-01 00:00:00 UTC2015-01-01 00:00:00 UTC1349
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC707
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC505
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC615
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC211
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC615
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC716
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC404
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC101
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC523

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
Sodium is an easy-to-use software library that provides a wide range of cryptographic operations including encryption, decryption, digital signatures, and secure password hashing. It is a portable, cross-compilable, installable, and packageable fork of NaCl. While maintaining API compatibility, libsodium extends functionality to improve usability and simplify the development of secure applications. Key Features Encryption & Decryption: Securely encrypt and decrypt data with modern algorithms. Digital Signatures: Create and verify signatures to ensure data authenticity. Cross-Platform Compatibility: Supported on Windows (MinGW and Visual Studio, x86, x64 and arm64), iOS, Android, JavaScript, and WebAssembly. User-Friendly API: Designed to provide all core cryptographic operations while remaining easy to integrate into your projects. Documentation Installation Quickstart Full Documentation Releases Integrity Checking Versioning libsodium uses a two-tier release system: Point releases (e.g., 1.0.19, 1.0.20, 1.0.21) are tagged when new features are added or significant changes are made. Stable releases are frequent maintenance updates between point releases. They fix minor issues while remaining fully compatible with their parent point release. No new features, no breaking changes. If your application depends on a specific point release, stable updates are safe to apply. Security fixes go to the stable branch immediately, with a new point release tagged shortly after. Contributors Code Contributors This project thrives thanks to the valuable contributions from our community. View all the contributors: Financial Contributors Your financial support helps us sustain and further develop libsodium. Become a Financial Contributor Individuals Organizations Support libsodium with your organization and gain visibility through your logo and website link. Support with Your Organization License This project is distributed under the ISC license.
Read the full README on GitHub

What Hacker News says

13 sources
Is nacl deprecated in favor of the libsodium fork? Or are both projects strong and continuing in parallel? [libsodium] is a portable, cross-compilable, installable, packageable fork of NaCl, with a compatible API, and an extended API to improve usability even further. Source: https://github.com/jedisct1/libsodium/blob/master/README.mar... I see DJB (original nacl creator http://nacl.cr.yp.to/) appears to contribute to libsodium: https://github.com/jedisct1/libsodium/blob/master/AUTHORS The website for nacl seems to be a bit outdated (many dates seem to refer to 2013), although there is still this tantalizing bit about features in the 'next' nacl release: Major features in the next release of NaCl: full PIC support, for easy integration into other languages; Ed25519 signatures (currently available in SUPERCOP); NEON optimi
Read the rest
zations. Thanks for any help clarifying this.
In Some gripes about nacl
It's quite interesting to study why crypto_(secret)box requires zero padding. It's not to avoid memory allocation, as tedu suggests, but to make the implementation stupidly simple. For every invocation of crypto_secretbox, NaCl needs to generate a single-use 32 byte key for the Poly1305 MAC. Since the first 32 bytes of the message are zero, NaCl can simply encrypt the entire message with Salsa20, and the first 32 bytes of the resulting ciphertext conveniently become a suitable key for Poly1305. (So when the documentation says the padding has to actually be zero, it's not kidding.) By making the implementation more complex (some memcpys and special casing of short messages), as libsodium has done for its crypto_secretbox_easy[1], you can avoid the need for this padding. Personally, I think djb should have avoided exposing this implement
Read the rest
ation detail in the interface. To simplify the implementation, he could have used the first output block (stream position 0) of Salsa20 only for the Poly1305 key, and then encrypted the message starting with stream position 1, instead of trying to use the first output block for both the Poly1305 key and the message. The implementation would have been only marginally more complex (not as complex as the libsodium implementation, as you wouldn't need special casing). Unfortunately this can't be changed now without breaking interoperability with messages encrypted with the current version of crypto_secretbox. [1] https://github.com/jedisct1/libsodium/blob/17932c782e5900ac8...
In Some gripes about nacl
After a little bit of digging seems to be the best way to currently wipe out sensitive data is to implement something like in libsodium https://github.com/jedisct1/libsodium/blob/master/src/libsod... 1- Try to use SecureZeroMemory() on Windows 2- Use memcpy_s() if available, which from its manpage is guaranteed not to be optimized away by compilers 3- Use a loop to manually zero-out the buffer after having casted to a volatile pointer, again to prevent compiler optimizations
In TrueCrypt Security Assessment [pdf]
Reading about djbs primitive making its way in to TLS, and all the hacks being made to TLS, reminded me of CurveCP[0] and makes me wonder whether its an idea worth revisiting. For those interested in playing with Salsa20 & poly1305 authenticated encryption outside of TLS there's Sodium[1] which has trivial C and C++ APIs and is based on djbs Nacl[2] I'd also refer people to Matt Greens post 'How to chose an Authenticated Encryption mode'[3]. There are some interesting alternatives out there like OCB (0.7 - 0.8 cycles/byte, free for FOSS despite patents, and more understandable for mortals). [0] http://curvecp.org/ [1] https://github.com/jedisct1/libsodium [2] http://nacl.cace-project.eu/box.html [3] http://blog.cryptographyengineering.com/2012/05/how-to-choos...
In TLS Symmetric Crypto

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.