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

libsodium-signcryption

Signcryption using libsodium.

Security & Privacy
Explore on GitHubRead Hacker News discussions
2Distinct people
6Mentions
0Explicit recommenders
73GitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Signcryption using libsodium.

GitHub

Where it is used

No documented product use has been verified yet.

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 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 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 month6 dated mentions

Observed mentions: 2021-12-22 17:00:11 UTC to 2024-01-31 16:05:14 UTC.

0122021-12-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 commentsDec 20212022-01-01 00:00:00 UTC to 2022-02-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2022-02-01 00:00:00 UTC to 2022-03-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-03-01 00:00:00 UTC to 2022-04-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-04-01 00:00:00 UTC to 2022-05-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-05-01 00:00:00 UTC to 2022-06-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-06-01 00:00:00 UTC to 2022-07-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-07-01 00:00:00 UTC to 2022-08-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-08-01 00:00:00 UTC to 2022-09-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-09-01 00:00:00 UTC to 2022-10-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-10-01 00:00:00 UTC to 2022-11-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2022-11-01 00:00:00 UTC to 2022-12-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-12-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 commentsDec 20222023-01-01 00:00:00 UTC to 2023-02-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-02-01 00:00:00 UTC to 2023-03-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-03-01 00:00:00 UTC to 2023-04-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-04-01 00:00:00 UTC to 2023-05-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-05-01 00:00:00 UTC to 2023-06-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-06-01 00:00:00 UTC to 2023-07-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-07-01 00:00:00 UTC to 2023-08-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-08-01 00:00:00 UTC to 2023-09-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-09-01 00:00:00 UTC to 2023-10-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-10-01 00:00:00 UTC to 2023-11-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-11-01 00:00:00 UTC to 2023-12-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-12-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-01-01 00:00:00 UTC to 2024-02-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 commentsJan 2024

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
Dec 20212021-12-01 00:00:00 UTC2022-01-01 00:00:00 UTC110
Jan 20222022-01-01 00:00:00 UTC2022-02-01 00:00:00 UTC202
Feb 20222022-02-01 00:00:00 UTC2022-03-01 00:00:00 UTC000
Mar 20222022-03-01 00:00:00 UTC2022-04-01 00:00:00 UTC000
Apr 20222022-04-01 00:00:00 UTC2022-05-01 00:00:00 UTC000
May 20222022-05-01 00:00:00 UTC2022-06-01 00:00:00 UTC000
Jun 20222022-06-01 00:00:00 UTC2022-07-01 00:00:00 UTC000
Jul 20222022-07-01 00:00:00 UTC2022-08-01 00:00:00 UTC000
Aug 20222022-08-01 00:00:00 UTC2022-09-01 00:00:00 UTC000
Sep 20222022-09-01 00:00:00 UTC2022-10-01 00:00:00 UTC000
Oct 20222022-10-01 00:00:00 UTC2022-11-01 00:00:00 UTC101
Nov 20222022-11-01 00:00:00 UTC2022-12-01 00:00:00 UTC000
Dec 20222022-12-01 00:00:00 UTC2023-01-01 00:00:00 UTC101
Jan 20232023-01-01 00:00:00 UTC2023-02-01 00:00:00 UTC000
Feb 20232023-02-01 00:00:00 UTC2023-03-01 00:00:00 UTC000
Mar 20232023-03-01 00:00:00 UTC2023-04-01 00:00:00 UTC000
Apr 20232023-04-01 00:00:00 UTC2023-05-01 00:00:00 UTC000
May 20232023-05-01 00:00:00 UTC2023-06-01 00:00:00 UTC000
Jun 20232023-06-01 00:00:00 UTC2023-07-01 00:00:00 UTC000
Jul 20232023-07-01 00:00:00 UTC2023-08-01 00:00:00 UTC000
Aug 20232023-08-01 00:00:00 UTC2023-09-01 00:00:00 UTC000
Sep 20232023-09-01 00:00:00 UTC2023-10-01 00:00:00 UTC000
Oct 20232023-10-01 00:00:00 UTC2023-11-01 00:00:00 UTC000
Nov 20232023-11-01 00:00:00 UTC2023-12-01 00:00:00 UTC000
Dec 20232023-12-01 00:00:00 UTC2024-01-01 00:00:00 UTC000
Jan 20242024-01-01 00:00:00 UTC2024-02-01 00:00:00 UTC101

What Hacker News says

6 sources
michelpp·Jan 31, 2024
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 o
Read the rest
f 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...
In Macaroons Escalated Quickly
michelpp·Dec 16, 2022
You've hit the nail right on the head with this question on how hard group encryption is, and we don't have all the answers yet as we are still working the use cases around it. We are hoping to reach a level of security that you mention in your SE question using something similar to the excellent accepted answer, distributed private key sharing among trusted participants. The basis we are exploring is using an algorithm called Signcryption (https://github.com/jedisct1/libsodium-signcryption) that is already included in pgsodium. This doesn't solve any of the shared private key issues you mention above, but it is a useful foundation for distributing encrypted messages that separate out sender and receiver identifiers from their keys, a sort of lower level foundation on top of which distributed key sharing can occur. I also think signcryp
Read the rest
tion is a great foundation for a better token format than JWT or PASETO, as it covers all of their use cases without algorithm confusion attacks (despite PASETO's insistence on "Algorithm Lucidity") and supports more features such as third party verification and streaming shared key generation from any token without having to exchange the key, we hope to use these tokens so that end-to-end peers can exchange tokens, derive streaming shared keys, and then do direct point-to-point message exchange using libsodium crypto_secretstream API which supports key ratcheting for forward secrecy. Would love to discuss more about your research with you and include it with attribution into our future work, send me an intro at michel@supabase.io when any other ideas or resources you'd like us to see!
In Supabase Vault is now in Beta
michelpp·Oct 13, 2022
Another signcryption scheme as described in the article is also implemented by the libsodium author as an extension: https://github.com/jedisct1/libsodium-signcryption It's unclear from the article if this is the same implementation age uses. Signcryption schemes are also a good candidate algorithm for replacing JWTs and PASETO as they suffer from no algorithm confusion, and don't need what PASETO calls "Algorithm Lucidity" and serve both plaintext authentication, authenticated encryption, sender receiver verification, and shared key generation that can be used for unlimited encrypted streaming, for example with libsodium's crypto_secretstream API. https://doc.libsodium.org/secret-key_cryptography/secretstre... https://github.com/paseto-standard/paseto-spec/blob/master/d...
In Age and Authenticated Encryption
michelpp·Jan 10, 2022
Hey HN, I shared an earlier prototype version of pgsodium but I just released 2.0 and felt this could be a good opportunity to share some updates! [pgsodium](https://github.com/michelp/pgsodium) 2.0.0 is a postgres extension that uses the [libsodium](https://doc.libsodium.org/) library to provide high-performance, modern cryptography support for PostgreSQL 10+. 2.0.0 includes a ton of new feature and a few bug-fixes: * Support for [XChaCha20-SIV](https://github.com/jedisct1/libsodium-xchacha20-siv) deterministic nonce-free encryption, this is useful for one-time workflows sacrificing a bit of speed and larger key size without worrying about nonce-handling issues. * Support for [SignCryption](https://github.com/jedisct1/libsodium-signcryption) Sign & Encrypt identity verification. Signcryption goes beyond public key verification to provid
Read the rest
e identity verification, and negotiating a shared-secret key between two parties to use fast streaming encryption of the payload. * Key id support for HMACSHA 512/256, generichash, and shorthash. This extends support for pgsodium's key management feature to these useful hash functions. * Support for low level [XChaCha20 streaming](https://libsodium.gitbook.io/doc/advanced/stream_ciphers/xch...). This is if you want to support your own low level algorithms on top of XChaCha20 for example, PASETO. * More tests, docs, and small bug fixes in argument parsing * In-memory key now protected with [sodium\_malloc](https://libsodium.gitbook.io/doc/memory_management), now the key has additional protection from over/underflow memory attack. Check it out at: [https://github.com/michelp/pgsodium](https://github.com/mich... Please feel free to submit any issues you may have and as usual pull requests are greatly appreciated!
In Show HN: Pgsodium – A Crytographic PostgreSQL Extension
kiwicopple·Jan 10, 2022
From Mike's comments on Reddit[0] pgsodium 2.0.0 is a postgres extension that uses the libsodium library to provide high-performance, modern cryptography support for PostgreSQL 10+. 2.0.0 includes a ton of new feature and a few bug-fixes: * Support for XChaCha20-SIV[2] deterministic nonce-free encryption * Support for SignCryption[3] Sign & Encrypt identity verification * Key id support for HMACSHA 512/256, generichash, and shorthash * Support for low level XChaCha20 streaming[4] * More tests, docs, and small bug fixes in argument parsing * In-memory key now protected with sodium_malloc[5] [0] https://www.reddit.com/r/PostgreSQL/comments/s0b6o2/pgsodium... [1] https://doc.libsodium.org/ [2] https://github.com/jedisct1/libsodium-xchacha20-siv [3] https://github.com/jedisct1/libsodium-signcryption [4] https://libsodium.gitbook.io/doc/advanc
Read the rest
ed/stream_ciphers/xch... [5] https://libsodium.gitbook.io/doc/memory_management
In Pgsodium 2.0.0: Modern cryptography for PostgreSQL

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.