SaaSHub helps you find the best software and product alternatives Learn more →
Top 23 C Encryption Projects
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
wolfssl
The wolfSSL library is a small, fast, portable implementation of TLS/SSL for embedded devices to the cloud. wolfSSL supports up to TLS 1.3!
-
-
magma
The magma server daemon, is an encrypted email system with support for SMTP, POP, IMAP, HTTP and MOLTEN,. Additional support for DMTP and DMAP is currently in active development. (by lavabit)
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
-
Themis
Easy to use cryptographic framework for data protection: secure messaging with forward secrecy and secure data storage. Has unified APIs across 14 platforms.
-
LibTomCrypt
LibTomCrypt is a fairly comprehensive, modular and portable cryptographic toolkit that provides developers with a vast array of well known published block ciphers, one-way hash functions, chaining modes, pseudo-random number generators, public key cryptography and a plethora of other routines.
-
-
Cronos
PoC for a sleep obfuscation technique leveraging waitable timers to evade memory scanners. (by Idov31)
-
-
-
disco-c
A tiny C cryptographic library to encrypt sessions, authenticate messages, sign, hash, etc. based only on SHA-3 and Curve25519
-
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
If you're going to use a custom local domain name, you might as well use a self-signed SSL certificate. I'll use OpenSSL for this:
Project mention: VeraCrypt: Free, open source, disk encryption for Windows, Mac OS X, Linux | news.ycombinator.com | 2023-10-01[1] - https://github.com/veracrypt/VeraCrypt
Project mention: S2n-TLS – A C99 implementation of the TLS/SSL protocol | /r/programming | 2023-12-05
> but at the very least I think Bluesky could start with generating a private key on each client device, and then using a simple box algorithm to encrypt messages towards the user they want to talk to.
Furry cryptography nerd here.
No. This is inadequate.
> I don't think https://tweetnacl.cr.yp.to/ is hard to mess up.
Yes it is! If you're doing to encrypt some things in a constrained use-case, sure, NaCl is better than hand-rolling it yourself. But it's not sufficient for end-to-end encryption. Here's a few things that TweetNaCl (and other NaCl variants) is, without further protocol design, inadequate to protect against:
1. Invisible Salamanders. NaCl uses xsalsa20poly1305, which is not key-committing.
2. Key Compromise Impersonation. See also, Toxcore, which built atop NaCl: https://github.com/TokTok/c-toxcore/issues/426
3. How do you do group messaging? If you do it as just pairwise, do you use the same public key as your p2p messaging? If so, how do you make sure you don't have a nonce reuse condition between both interactions. Oops.
There is a damn reason end-to-end encryption involves authenticated key exchanges and forward-secure double ratchets.
I like the "solve the now" perspective here, and having code examples is very helpful to understand some of the rational behind the approach. Having read your previous "tedious survey"[0] post on various token formats, I generally agree with a lot of your conclusions. Curious though about your thought process wrt macaroons vs biscuits.
To me the one major downside of macaroons has always been the single shared root symmetric key. Many use cases are addressed by third party attenuation, but then there are the problems like key rotation, having to do online verification, no built in encryption, no peer-to-peer support through an "untrusted" fly.io, and no third party token verification without decryption like in signcryption[1] schemes. Of course this is traded off by having to do PK issuance and management so I can see the simplicity of it.
Is fly.io scoping this pretty hard to just auth tokens with third party attenuation, or do you see further development and maybe moving to other token systems like biscuit when/if the need arises to address those known issues?
fwiw I've done a bit of research work myself on a token format using signcryption [2] where I explored addressing some of these ideas (but not the attenuation side of it yet, which I get is a big deal here).
[0] https://fly.io/blog/api-tokens-a-tedious-survey/
[1] https://github.com/jedisct1/libsodium-signcryption
[2] https://github.com/michelp/pgsodium/blob/feat/signcryption-t...
I like the "solve the now" perspective here, and having code examples is very helpful to understand some of the rational behind the approach. Having read your previous "tedious survey"[0] post on various token formats, I generally agree with a lot of your conclusions. Curious though about your thought process wrt macaroons vs biscuits.
To me the one major downside of macaroons has always been the single shared root symmetric key. Many use cases are addressed by third party attenuation, but then there are the problems like key rotation, having to do online verification, no built in encryption, no peer-to-peer support through an "untrusted" fly.io, and no third party token verification without decryption like in signcryption[1] schemes. Of course this is traded off by having to do PK issuance and management so I can see the simplicity of it.
Is fly.io scoping this pretty hard to just auth tokens with third party attenuation, or do you see further development and maybe moving to other token systems like biscuit when/if the need arises to address those known issues?
fwiw I've done a bit of research work myself on a token format using signcryption [2] where I explored addressing some of these ideas (but not the attenuation side of it yet, which I get is a big deal here).
[0] https://fly.io/blog/api-tokens-a-tedious-survey/
[1] https://github.com/jedisct1/libsodium-signcryption
[2] https://github.com/michelp/pgsodium/blob/feat/signcryption-t...
NOTE:
The open source projects on this list are ordered by number of github stars.
The number of mentions indicates repo mentiontions in the last 12 Months or
since we started tracking (Dec 2020).
C Encryption related posts
-
How to Resolve Node.js ERR_OSSL_EVP_UNSUPPORTED Error
-
Heartbleed and XZ Backdoor Learnings: Open Source Infrastructure Can Be Improved Efficiently With Moderate Funding
-
Ask HN: Open-source Windows 11 backup solutions
-
Ask HN: How does the xz backdoor replace RSA_public_decrypt?
-
Tox Core is one of the nicest-to-read C codebases
-
Macaroons Escalated Quickly
-
Use of HTTPS Resource Records
-
A note from our sponsor - SaaSHub
www.saashub.com | 1 Jun 2024
Index
What are some of the best open-source Encryption projects in C? This list will help you:
| Project | Stars | |
|---|---|---|
| 1 | OpenSSL | 24,449 |
| 2 | VeraCrypt | 6,352 |
| 3 | GmSSL | 4,832 |
| 4 | s2n | 4,452 |
| 5 | wolfssl | 2,200 |
| 6 | c-toxcore | 2,177 |
| 7 | magma | 1,823 |
| 8 | Themis | 1,816 |
| 9 | LibTomCrypt | 1,491 |
| 10 | Minizip-ng | 1,173 |
| 11 | enchive | 621 |
| 12 | Cronos | 539 |
| 13 | pgsodium | 515 |
| 14 | libdime | 415 |
| 15 | sqleet | 372 |
| 16 | lurch | 281 |
| 17 | VeraCrypt-DCS | 129 |
| 18 | mkinitcpio-ykfde | 106 |
| 19 | CatCrypto | 68 |
| 20 | disco-c | 62 |
| 21 | libsodium-signcryption | 57 |
| 22 | libcrux | 46 |
| 23 | rvault | 33 |
Sponsored
SaaSHub - Software Alternatives and Reviews
SaaSHub helps you find the best software and product alternatives
www.saashub.com