autocert
XKCP
autocert | XKCP | |
---|---|---|
10 | 8 | |
2,941 | 564 | |
0.6% | 0.7% | |
8.1 | 8.2 | |
9 days ago | 5 days ago | |
Go | C | |
BSD 3-clause "New" or "Revised" License | 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.
autocert
-
Current bcrypt is problematic I find. Made changes to core functionality. Looking for feedback
Pull request link
- GOlang ile şifreleme işlemleri için crypto paketi
- Argon2 or Argon2id still recommended over Bcrypt for Password Hashing?
-
SHA-3 Buffer Overflow
The version in the Golang stdlib is a pure-go implementation, but there's an assembler variant optimized for amd64 (https://github.com/golang/crypto/blob/master/sha3/keccakf_am...), which is apparently derived from the XKCP package.
Bad news for the (mostly-Golang) Ethereum ecosystem...
-
Web dev learning path advice
Learn crypto library and how to encrypt and hash: https://github.com/golang/crypto
-
Hashing password
In last section we have created users table in our database, but we are currently storing user's password in plain text. This is something we should never do, and instead we need to store hashed password with random salt. For that we will use golang/crypto library. First we need to expand our User structure:
- Minio Changes License to AGPL
-
SIEC elliptic curve vs other better known ones ?
So in conclusion, croc seems to be pretty secure as long as you use P-256 (or P-384). Internally, the standard golang.org/x/crypto library is used, which I can guarantee is very secure, as it is used in millions of web servers around the world, and Go is a language maintained by Google, which has many security professionals at their disposal. Ultimately, the decision is yours. While I can give you my opinion and point you to correct documents, you should trust nobody other than yourself. Not even me. But still, I recommend P-256 above everything else.
-
Crowdsourcing for healthcare tool accepting DOGE as payment feedback
I've been considering developing suck tools with Golang. Golang's crypto package golang crypto might be a great starting point if your familiar with language.
-
how does bcrypt.CompareHash function know which cost to select?
https://github.com/golang/crypto/blob/eec23a3978adcfd26c29f4153eaa3e3d9b2cc53a/bcrypt/bcrypt.go#L234-L254
XKCP
-
SHA-3 Buffer Overflow
> Just another nail in the long overdue C/C++ coffin
C, f**ing C. By the sake of god. Not C++.
https://github.com/XKCP/XKCP/commit/fdc6fef075f4e81d6b1bc383...
Something like that in modern C++ would have been done using span<> and that prevents this kind of out-of-bound access party-time.
-
SHA-3 Buffer Overflow - CVE-2022-37454
This and the commit diff itself tell the tale: https://github.com/XKCP/XKCP/issues/105
-
Linux Kernel RNG is now Blake2 instead of SHA1 and 3x faster
With parameters as specified by SHA3 it's a lot slower than BLAKE3
Keccak (SHA-3) is actually a good deal faster than BLAKE(1) in hardware. That’s the reason why they chose it: It has acceptable performance in software, and very good performance in hardware.
KangarooTwelve / MarsupilamiFourteen are Keccak variants with fewer rounds; they should smoke BLAKE2 and probably even BLAKE3 in dedicated hardware. Also, they have tree hashing modes of operation like the later BLAKE developers.
The BLAKE family is best in situations where you want the best possible software performance; indeed, there are cases where you do not want hardware to outperform software (e.g. key derivation functions) where some Salsa20/ChaCha20/BLAKE variant makes the most sense. The Keccak family is when one already has dedicated hardware instructions (e.g. ARM already has a hardware level Keccak engine; Intel is dragging their feet but it is only a matter of time) or is willing to trade software performance for more hardware performance.
Keccak code is here: https://github.com/XKCP/XKCP
- XKCP - Xoodoo and Keccak Code package
What are some alternatives?
lego - Let's Encrypt/ACME client and library written in Go
BLAKE3-specs - The BLAKE3 paper: specifications, analysis, and design rationale
bitwarden-go - A Bitwarden-compatible server written in Golang
curve9767
Themis - Easy to use cryptographic framework for data protection: secure messaging with forward secrecy and secure data storage. Has unified APIs across 14 platforms.
BLAKE3 - the official Rust and C implementations of the BLAKE3 cryptographic hash function
simple-scrypt - A convenience library for generating, comparing and inspecting password hashes using the scrypt KDF in Go 🔑
acmetool - :lock: acmetool, an automatic certificate acquisition tool for ACME (Let's Encrypt)
BadActor - BadActor.org An in-memory application driven jailer written in Go
ssh-vault - 🌰 encrypt/decrypt using ssh keys
go-htpasswd - Apache htpasswd Parser for Go.
nacl - Pure Go implementation of the NaCL set of API's