boringssl
Tink
Our great sponsors
boringssl | Tink | |
---|---|---|
10 | 19 | |
1,719 | 13,457 | |
3.4% | - | |
6.5 | 9.9 | |
5 days ago | 11 days ago | |
C | Java | |
GNU General Public License v3.0 or later | Apache License 2.0 |
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.
boringssl
-
New vulnerabilities (CVE-2022-3602 and CVE-2022-3786) in OpenSSL, how they affect IoT and RTOS Devices.
I have nothing constructive to add except that OpenSSL has a long history of producing vulnerabilities so much so that Google has created their own fork publicly available here: https://boringssl.googlesource.com/boringssl/ (used in chromium, chrome, and android).
-
OpenSSL added new C parser code [...] without doing any basic security testing
> Large web companies like Google implement their own encryption stack anyway.
Google uses BoringSSL[1], which is another OpenSSL fork. I believe AWS uses a mix of OpenSSL and Boring SSL (someone can correct me!).
So it's "their own encryption stack," but that stack is at least originally comprised of OpenSSL's code. They've probably done an admirable job of refactoring it, but API and ABI constraints still apply (it's very hard to change the massive body of existing code that assumes OpenSSL's APIs).
[1]: https://boringssl.googlesource.com/boringssl/
-
CVE-2022-3786 and CVE-2022-3602: X.509 Email Address Buffer Overflows
OpenSSL gets plenty of funding but we need to put more funding into TLS implementations that have a bigger focus on security and stability like boringssl, nss, go's tls, and rustls. It's 2022 and we have both languages better suited for this and tools to make existing languages safer and more robust, it's incredible to me that we aren't even more anxious over the current state of openssl.
-
BearSSL: A smaller SSL/TLS library
It was not built for chromium AFAIK
To quote: https://boringssl.googlesource.com/boringssl/
BoringSSL arose because Google used OpenSSL for many years in various ways and, over time, built up a large number of patches that were maintained while tracking upstream OpenSSL. As Google's product portfolio became more complex, more copies of OpenSSL sprung up and the effort involved in maintaining all these patches in multiple places was growing steadily.
Currently BoringSSL is the SSL library in Chrome/Chromium, Android (but it's not part of the NDK) and a number of other apps/programs.
- OpenSSL Security Advisory for CVE-2022-0778
-
I think a major issue with the rust ecosystem is that it's full of unexpected design decisions
Use Google's fork of OpenSSL which exists because Google likes to do it's own weird things sometimes. This doesn't say anything about "OpenSSL is considered dangerous", it says "This allows us to mostly avoid compromises in the name of compatibility. It works for us, but it may not work for you."
- Information and learning resources for cryptography newcomers
-
OpenSSL Security Advisory (14 December 2021)
And this is why projects like https://boringssl.googlesource.com/boringssl/ exist
-
U.S. Telecoms Are Going to Start Physically Removing Huawei Gear
The immediate effect of Heartbleed was the OpenBSD folk [1] and Google [2] forking OpenSSL.
There's a talk from Bob Beck of OpenBSD on pruning OpenSSL, it's pretty hilarious [3].
In that case open source was at least able to react appropriately, even if it didn't act preemptively.
[1]: https://www.libressl.org
[2]: https://boringssl.googlesource.com/boringssl/
[3]: https://www.youtube.com/watch?v=GnBbhXBDmwU
-
Cloudflare: Warp for Linux and Proxy Mode
I doubt the reference to Musk's brand is intentional. It's more likely that it's a reference/homage to BoringSSL (https://github.com/google/boringssl) and "boring tech" in general that is purposefully designed to be minimalist, simple to use, and narrow in scope.
Tink
-
“Please do not make it public” (Tencent’s Sogou Input Method)
> I wonder what people say when they find a bug despite you using standard crypto?
Not using TLS doesn't automatically mean you need to "roll your own crypto". They could have used a well documentend library such as Google Tink[1] instead of doing their own crypto.
[1] https://github.com/google/tink
-
What are you rewriting in rust?
I sort of rewrote google's tink project in rust. There is already a rust version by project oak but it didn't exactly jive.
-
PassManager
PassManager uses the Tink library for encryption, which provides state-of-the-art** security for your passwords. Tink uses industry-standard encryption algorithms like AES to ensure that your passwords are kept safe from prying eyes.
- Cryptographic Best Practices
-
Using Google Tink to sign JWTs with ECDSA
Note that in the example jwt refers to the Tink jwt package.
- What do you guys use for password hashing?
-
What's new in Jetpack Security Crypto Version 1.1.0-alpha04
What I can't tell is if the new version had any fixes related to the bug being discussed here
-
How do you handle encryption?
Even the slightest hiccup could leave me vulnerable. I don't want to roll my own encryption. I want to use something like tink (a secure crypto library by Google) but unfortunately they don't support node or Javascript (there's a library that was published 2 years ago).
-
Some help with cryptography?
I dont have an answer for you, but 2 resources that are worth checking out: https://developer.android.com/guide/topics/security/cryptography and https://developers.google.com/tink
-
Ask HN: Is there a portable encryption file format?
> Do C (or something where the mapping to C is known), and lots of languages have FFI libs where wrapping that is fairly trivial
That is an interesting idea, yet still a lot of work, sadly. I was hoping somebody had done the legwork already. I looked at Tink [1] and age [2] based on my co-worker's recommendation, but they all seem to have limited implementations in other languages.
[1] https://github.com/google/tink
[2] https://github.com/FiloSottile/age
What are some alternatives?
OpenSSL - TLS/SSL and crypto library
Jwks RSA
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!
Kalium - Java binding to the Networking and Cryptography (NaCl) library with the awesomeness of libsodium
libsodium - A modern, portable, easy to use crypto library.
SSLContext-Kickstart - 🔐 A lightweight high level library for configuring a http client or server based on SSLContext or other properties such as TrustManager, KeyManager or Trusted Certificates to communicate over SSL TLS for one way authentication or two way authentication provided by the SSLFactory. Support for Java, Scala and Kotlin based clients with examples. Available client examples are: Apache HttpClient, OkHttp, Spring RestTemplate, Spring WebFlux WebClient Jetty and Netty, the old and the new JDK HttpClient, the old and the new Jersey Client, Google HttpClient, Unirest, Retrofit, Feign, Methanol, Vertx, Scala client Finagle, Featherbed, Dispatch Reboot, AsyncHttpClient, Sttp, Akka, Requests Scala, Http4s Blaze, Kotlin client Fuel, http4k Kohttp and Ktor. Also gRPC, WebSocket and ElasticSearch examples are included
webpki - WebPKI X.509 Certificate Validation in Rust
password4j - Java cryptographic library that supports Argon2, bcrypt, scrypt and PBKDF2 aimed to protect passwords in databases. Easy to use by design, highly customizable, secure and portable. All the implementations follow the standards and have been reviewed to perform better in the JVM.
istlsfastyet.com - Is TLS fast yet? Yes, yes it is.
SecurityBuilder - Fluent builders with typesafe API for the JCA
wgcf - 🚤 Cross-platform, unofficial CLI for Cloudflare Warp