HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
briansmith
ring
Assembly2015–2025
briansmith / ring

ring

An experiment.

Security & Privacy
Explore on GitHubRead Hacker News discussions
31Distinct people
39Mentions
2Explicit recommenders
4.1KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

An experiment.

GitHub

Where it is used

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

What people are saying

Note that the readme is outdated. With the upcoming 0.17 release, which is in the making for almost a year already, you can link multiple versions of ring in one executable:…

est31 used a recommendation phrase. 2 indexed comments match. This is a phrase match, not a verdict.

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, 1:49:46 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 year39 dated mentions

Observed mentions: 2015-09-23 00:31:02 UTC to 2025-02-08 05:21:05 UTC.

024682015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 3 mentions; 1 submissions, 2 comments20152016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 8 mentions; 1 submissions, 7 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 4 mentions; 1 submissions, 3 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments20202021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 6 mentions; 0 submissions, 6 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 7 mentions; 0 submissions, 7 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2025

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
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC312
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC817
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC413
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC303
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC202
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC303
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC606
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC707
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC101
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC101
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC101

From the project README

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

Read the project’s introduction
THE SOFTWARE IS PROVIDED "AS IS" AND BRIAN SMITH AND THE AUTHORS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL BRIAN SMITH OR THE AUTHORS BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. Most of the C and assembly language code in ring comes from BoringSSL. BoringSSL is a fork of OpenSSL. This quote from the BoringSSL README.md discouraging you from using it applies to this project: BoringSSL is a fork of OpenSSL that is designed to meet Google's needs. Although BoringSSL is an open source project, it is not intended for general use, as OpenSSL is. We don't recommend that third parties depend upon it. This project was originally shared on GitHub in 2015 as an experiment. It was put on crates.io shortly to help other people with their experiments. It is an experiment. Side Channels See SIDE-CHANNELS.md for important information regarding the limitations of the side channel mitigations in this project. Toolchains & Targets Be especially wary about using toolchains (C compilers, etc.) or targets that aren't supported by other projects, especially BoringSSL. The further you are from using the same version of Clang that Chrome uses, the more wary you should be. Bug Reporting For security vulnerabilities, see https://github.com/briansmith/ring/security/policy. Please report bugs that aren't security vulnerabilities either as pull requests or as issues in the issue tracker. Release Notes It is recommended that you review every commit in this project. Some particularly noteworthy changes are noted in the RELEASES.md. We could use some help in making this better.
Read the full README on GitHub

What Hacker News says

39 sources
conradludgate·Sep 15, 2023
Libsodium is a great library, but as I'm in the Rust ecosystem and since we all must Rewrite it in Rust I am very interested in the RustCrypto project[0]. I previously used sodiumoxide[1] libsodium bindings in my projects but they are in maintenance only mode and wouldn't accept patches to build on other platforms (we had raspberry pi users complaining they couldn't build our software because of sodiumoxide). Maintaining cross platform C libraries which use assembly primitives is pretty tricky. The ring[2] library - which is used by rustls (a better tls library for rust) - is notoriously annoying to cross compile because of its use of C and assembly. [0]: https://github.com/rustcrypto [1]: https://github.com/sodiumoxide/sodiumoxide [2]: https://github.com/briansmith/ring
In Libsodium: A modern, portable, easy to use crypto library
tialaramex·Jul 6, 2022
Beyond the simple matter of Rust being much newer than OpenSSL, one concern for some cryptographic primitives is the timing side-channel. https://en.wikipedia.org/wiki/Timing_attack In high level languages like Rust, the compiler does not prioritise trying to emit machine code which executes in constant time for all inputs. OpenSSL has implementations for some primitives which are known to be constant time, which can be important. One option if you're working with Rust anyway would be use something like Ring: https://github.com/briansmith/ring Ring's primitives are just taken from BoringSSL which is Google's fork of OpenSSL, they're a mix of C and assembly language, it's possible (though fraught) to write some constant time algorithms in C if you know which compiler will be used, and of course it's possible (if you read the performance ma
Read the rest
nuals carefully) to write constant time assembly in many cases. In the C / assembly language code of course you do not have any safety benefits. It can certainly make sense to do this very tricky primitive stuff in dangerous C or assembly, but then write all the higher level stuff in Rust, and that's the sort of thing Ring is intended for. BoringSSL for example includes code to do X.509 parsing and signature validation in C, but those things aren't sensitive, a timing attack on my X.509 parsing tells you nothing of value, and it's complicated to do correctly so Rust could make sense.
In OpenSSL Security Advisory
woodruffw·Jul 5, 2022
The modes of operation aren't the main reason people use OpenSSL; it's the support for all the gnarly (and less gnarly) protocols and wire formats that show up when doing applied cryptography. Progress is being made on replacing OpenSSL in a lot of contexts (specifically, the RustCrypto[1] folks are doing excellent work and so is cryptography[2]), but there are still plenty of areas where OpenSSL is needed to compose the mostly algebraic cryptography with the right wire format. Edit: I forgot to mention rustls[3], which uses ring[4] under the hood. [1]: https://github.com/RustCrypto [2]: https://github.com/pyca/cryptography [3]: https://github.com/rustls/rustls [4]: https://github.com/briansmith/ring
In OpenSSL Security Advisory
marcus_cemes·Apr 2, 2022
I'm not familiar with NaCl, websites that don't seem to have been updated in 7 years (version states 2016?) make me a little suspicious about the future viability of said projects. Perhaps it's not something that needs to be updated very frequently, but my knee-jerk reaction is that it looks abandoned, especially considering that they have an "upcomming features" section. What made you choose it? Could PGP/GPG with ed25519 keys not have been sufficient? What makes NaCL "fun to work with"? For me, fun to work with would be Age [1] or Ring [2] with a elegant and well designed API. I'm also aware that the older something is, the more likely it has undergone peer review and security audits, unlike new Rust crypto libraries. [1]: https://github.com/FiloSottile/age [2]: https://github.com/briansmith/ring
In Seriously, Stop Using RSA (2019)
est31·Dec 2, 2021Recommendation phrase
Note that the readme is outdated. With the upcoming 0.17 release, which is in the making for almost a year already, you can link multiple versions of ring in one executable: https://github.com/briansmith/ring/issues/1268 Similarly, while the policy is still that ring only supports the newest rust compiler version, due to the fact that there has been no update for months already, you can use it with older compiler versions. Last, the author used to yank old versions of its library, which caused tons of downstream pains (basically, if you are a library and are using ring, I recommend you have a Cargo.lock checked into git). This yanking has stopped since 3 years already, too. Don't think this was mentioned in the readme, but I feel it's an important improvements for users. So a great deal of things has improved, although I'd say only the fi
Read the rest
rst bullet point is a permanent improvement, while the second two might be regressed upon. idk.
In This shouldn't have happened: A vulnerability postmortem

Showing the 15 most recent of 39 sources. Enable JavaScript to search and browse every indexed mention.

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.