rustls
BLAKE3
Our great sponsors
rustls | BLAKE3 | |
---|---|---|
57 | 36 | |
5,375 | 4,524 | |
4.0% | 2.2% | |
9.9 | 8.1 | |
4 days ago | 9 days ago | |
Rust | Assembly | |
GNU General Public License v3.0 or later | GNU General Public License v3.0 or later |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
rustls
-
Pingora: HTTP Server and Proxy Library, in Rust, by Cloudflare, Released
Being able to use rustls as a drop-in replacement for openssl is on their roadmap: https://github.com/rustls/rustls/blob/main/ROADMAP.md#future...
So that'll certainly one option in the future.
Rustls claims to support TLS 1.2 as well (https://github.com/rustls/rustls)
- Alternative to openssl for reqwest https with client certs.
-
What are the scenarios where "Rewrite it in Rust" didn't meet your expectations or couldn't be successfully implemented?
I also studied this question on FFI several weeks ago in terms of "rewrite part of the system in Rust". Unexpected results could be semantic issues (e.g., different error handling methods) or security issues (FFI could be a soundness hole). I suggest going through the issues of libraries that have started rewriting work such as rust-openssl or rustls (This is the one trying to rewrite in whole rust rather than using FFI; however, you will not be able to find the mapping function in the C version and compare them). I hope this helps!
-
A brief guide to choosing TLS crates
Now for rust implementation of tls. Certificates can be loaded in two ways. * Finds and loads certificates using OS specific tools3 * Uses a rust implementation of webpki4 for loading with certificates5
-
Microsoft is busy rewriting core Windows library code in memory-safe Rust
> Ring is mostly C/Assembly
Crypto needs to be written in Assembly to ensure that operations take a constant time, regardless of input. Writing it in a high level language like C or Rust opens you up to the compiler "optimising" routines and making them no longer constant time.
But you already knew this. And you also knew that the security audit (https://github.com/rustls/rustls/blob/master/audit/TLS-01-re...) of ring was favourable
> No issues were found with regards to the cryptographic engineering of rustls or its underlying ring library. A recommendation is provided in TLS-01-001 to optionally supplement the already solid cryptographic library with another cryptographic provider (EverCrypt) with an added benefit of formally verified cryptographic primitives. Overall, it is very clear that the developers of rustls have an extensive knowledge on how to correctly implement the TLS stack whilst avoiding the common pitfalls that surround the TLS ecosystem. This knowledge has translated reliably into an implementation of exceptional quality.
You said
> a standard library with feature flags and editions would make rust ridiculously much more productive
What's the difference between opting into a library with a feature flag and opting in with a line in Cargo.toml? Let's say you want to use the de-facto regex library. Would it really be ridiculously productive if you said you wanted the "regex" feature flag instead of the "regex" crate?
I do agree that the standard library does need a versioning story so they can remove long deprecated functions. Where it gets complicated is if a new method is reintroduced using the same name in a later edition.
-
Is Rust really safe? How to identify functions that can potentially cause panic
I believe it is more relevant than you think: servers running in containers, web assembler tasks running in browsers, embedded devices and kernels with total control of the system, all have the ability to do something more sensible than plain out SIGABRT or similar, and in many the case is not that the complete system is falling down. For example RustTLS is looking into allowing fallible allocators and as a pretty general-purpose library that seems like a nice feature. I do wish ulimit -v worked in a sensible manner with applications.
-
MCloudTT: An asynchronous MQTT v5 Broker written in Rust
I think it is this issue. But I'll get back to you tomorrow
-
Architecture with rust
Then you also might need to use rustls , some kind of oauth crate and a persistence layer of choice (database).
BLAKE3
-
Reasons to Prefer Blake3 over Sha256
> might be easier with a public domain license instead of the current ones
There reference implementation is public domain (CC0) or at your choice Apache 2.0
-
Google abandons work to move Assistant smart speakers to Fuchsia
Fyi, blake3 was released in 2019 and should probably be used over blake2 unless you have some strong reason not to. It's basically a reimplementation of blake2 with performance tweaks.
-
Six times faster than C
Many people will argue that today's compilers are so smart/optimized that you'd be a fool to try to outsmart the compiler with asm. I'm not 1 of them, but I know some. IMO it's all a bunch of bullshit, there's a goddamn reason all the cryptocurrency mining CPU/GPU code is all hand-written asm. there's a reason blake3 is written in asm ( https://github.com/BLAKE3-team/BLAKE3/blob/master/c/blake3_sse41_x86-64_windows_msvc.asm ) - but the thing is, 99.99% of the time, life is too short to outsmart the compiler (unless you're Alexander Yee)
-
PoxHash, a bespoke denovo hashing algorithm implemented dep-free in Rust and 5 other languages. Rust compiled with rustc with -O is faster than GCC-compiled C with -O3!
You're saying the hash speed is 133 kB/s? That's extremely slow, for example BLAKE3 achieves 6.8 GB/s which is over 50000 times faster. Nobody wants to use such a slow hash function.
-
What's everyone working on this week (4/2023)?
Try this one if you want a smaller, and particularly interesting crate: https://github.com/BLAKE3-team/BLAKE3
-
New Ryzens and Chia plotters
blake3 is a cryptographic hashing function, which is used during plotting's "forward propagation" step
-
Image displays its own MD5 hash
BLAKE3 claims to be faster and more secure than both MD5 and SHA1.
-
Use Fast Data Algorithms
> However, it must be kept in mind that BLAKE3 is much faster than any other cryptographic hash only because it distributes the computation on all CPU cores.
Surprisingly, this is incorrect. The red bar chart above the fold at https://github.com/BLAKE3-team/BLAKE3 is a single-threaded measurement. What you see there is that BLAKE3 can take better advantage of SIMD parallelism than other hashes, and the C and Rust library implementations do this by default. Multithreading isn't enabled by default, but if you do use it (and you have enough input to feed it) the benefits are multiplicative.
> only 1 cryptographic hash is faster: BLAKE3
SIMD implementations of KangarooTwelve are also about as fast as BLAKE3, given enough input.
-
Linux's getrandom() Sees A 8450% Improvement With Latest Code
BLAKE3 is much faster than blake2s though.. https://github.com/BLAKE3-team/BLAKE3/blob/master/media/speed.svg
What are some alternatives?
rust-native-tls
xxHash - Extremely fast non-cryptographic hash algorithm
rust-openssl - OpenSSL bindings for Rust
mkcert - A simple zero-config tool to make locally trusted development certificates with any names you'd like.
Hashids.java - Hashids algorithm v1.0.0 implementation in Java
highwayhash - Fast strong hash functions: SipHash/HighwayHash
ring - Safe, fast, small crypto using Rust
webpki - WebPKI X.509 Certificate Validation in Rust
libsodium - A modern, portable, easy to use crypto library.
rust-crypto - A (mostly) pure-Rust implementation of various cryptographic algorithms.
RustCrypto - Authenticated Encryption with Associated Data Algorithms: high-level encryption ciphers
sodiumoxide - [DEPRECATED] Sodium Oxide: Fast cryptographic library for Rust (bindings to libsodium)