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.

ring is a crypto library in Rust based on BoringSSL's crypto primitive implementations.

Particular attention is being paid to making it easy to build and integrate ring into applications and higher-level frameworks, and to ensuring that ring works optimally on microcontrollers to support Internet of Things (IoT) applications.

The name ring comes from the fact that ring started as a subset of BoringSSL, and "ring" is a substring of "BoringSSL". Almost all the code in ring comes from BoringSSL, and BoringSSL is derived from OpenSSL. In general an application that uses the subset of BoringSSL APIs that ring supports should work identically if it is recompiled and relinked with BoringSSL instead. ring tracks upstream changes to BoringSSL. Several patches that were developed for ring have already been integrated upstream in BoringSSL.

The first part of the ring Rust crate is now available.

Currently these features are supported through the Rust API:

• AEAD (authenticated encryption) using AES-GCM (more algorithms to follow)
• Cryptographic digests (SHA-256, SHA-384, SHA-512, SHA-1, and MD5)
• HMAC, HKDF, and PBKDF2-HMAC
• Ephemeral ECDH key agreement for curves P-256, P-384, and P-521
• ECDSA signature verification for curves P-256, P-384, and P-521
• RSA PKCS#1 signature verification
• Random byte generation

See the documentation at https://briansmith.org/rustdoc/ring/. Also take a look at the example program examples/checkdigest.rs.

See Building the Rust Library for instructions on how to build it.

The C API is the same as BoringSSL's, except that its SSL/TLS, X.509, ASN.1 APIs, and error stack mechanism, have been permanently removed. Currently, the C API also does not expose the EVP, HMAC, HKDF, and PBKDF2 interfaces, but only because the C wrappers around the new Rust implementations have not been implemented yet. The currently plan is to support a C interface that is the same as or similar to BoringSSL's.

See this (for Windows) and this (for other platforms) for instructions on how to build ring and incorporate it into your project.

Patches Welcome! Suggestions:

• More code elimination, especially dead code.
• Replacing more C code with Rust code.
• Implementation of SRP-6a in Rust, based on the |rust::digest| API and the C/asm optimized modular exponentiation.
• Optimizing the PBKDF2-HMAC implementation based on the ideas from fastpbkdf2.
• X25519 (ECDH with Curve25519) and Ed25519.
• Better IDE support for Windows (e.g. running the tests within the IDE) and Mac OS X (e.g. Xcode project files).
• Language bindings for safer programming languages like Haskell, OCaml, and Rust.
• Support for more platforms in the continuous integration, such as Android, Mac OS X, and ARM microcontrollers. (The current CI only covers Linux.)
• Static analysis and fuzzing in the continuous integration.

See LICENSE. The ring project happily accepts pull requests without any copyright license agreement. The portions of pull requests that modify existing files should be licensed under the same terms as the files being modified. New files in pull requests should be licensed under the ISC-style license. If your patch is useful for BoringSSL then it would be very nice of you to also submit it to them after agreeing to their copyright license agreement.

Travis CI is used for Linux and Mac OS X. Appveyor is used for Windows.

OS	Arch.	Compilers	Status
Linux	x86, x64	GCC 4.8, 4.9, 5; Clang 3.4, 3.5, 3.6
Mac OS X x64	x86, x64	Apple Clang 6.0 (based on Clang 3.5)
Windows	x86, x64	MSVC 2013 (12.0), 2015 (14.0)

Please file bugs in the issue tracker. If you think you've found a security vulnerability that affects BoringSSL and/or OpenSSL then those projects would probably appreciate it if you report the bug privately to them. The ring project is happy to take any kind of bug report as a pull request that fixes it and/or adds a test for the issue, or as an issue filed in the public issue tracker. Do NOT report any security vulnerability privately to the ring developers.