Major Claim By ISARA (need to research this organization, ISARA) [re: HSS & XMSS - Ideal for Roots of Trust]

"Hierarchical Signature Scheme (HSS) and eXtended Merkle Signature Scheme (XMSS) are based on a mature area of mathematics and are well trusted to be used for digital signatures today. They are not part of the NIST PQC Standardization process but will be approved for specific use cases, like code-signing and certificate-signing. While they generally perform better than elliptic curve cryptography (ECC), they have one drawback: a large stateful private key.

By working closely with our HSM partners, we’ve solved the state management problem making these schemes ready for quantum-safe roots of trust in code and certificate signing today."

A) Developer's Guide = https://www.isara.com/toolkit/2/doc/guide/guide.html

B) API Reference = https://www.isara.com/toolkit/2/doc/library/index.html

C) README Document = https://www.isara.com/toolkit/2/README.html

D) GitHub Toolkit Samples = https://github.com/isaracorp/Toolkit-Samples

E) Documentation for Previous Versions = https://www.isara.com/isara-radiate-documentation-previous-versions/

Perhaps the Coolest Cryptography-Based Website I've Seen in a While = noiseexplorer.com

This site is an htm5 page that allows you to tinker around with the Noise Protocol (via interactive GUI ; no coding or anything necessary) by essentially structuring your packet transmission & the timing of your handshakes etc.

Super cool (we need more things like this in the world)

Lets Encrypt Moves to ECDSA Certificates

Its about time. Will be renewing the certificates on every single website that I have L.E. certs provisioned on when the opportunity allows itself.

Wondering if the popular ACME clients out there have adjusted their request policies accordingly.

Was surprised when I saw that LetsEncrypt was offering EC-384 strength certificates at that. Definitely raises the bar on what we should be expecting from vendors.

Apart from DigiCert, no other CA appears worth giving money for anything (digicert provides some exclusivity in terms of allowed extensions ; i.e., http signing servers and the like)

Anti-Daniel Bernstein Sentiment From Some

If you've ever wondered what 'hatin' on someone' looks like, then this article basically wraps up the practice succinctly: https://lwn.net/Articles/681615/

Breaking Down This Idea of 'Crypto(graphy) Monoculture'

According to Peter Guttmann, there's an inherent issue with the fact that Daniel Bernstein has arisen to such prominence in the crypto community, with his cryptographic standards gaining adoption at rapid pace (Edwards Curves, Curve25519, Poly1305, ChaCha20, et. al).

Daniel Bernstein Deserves Respect

Let's start with Daniel Bernstein going up against the United States in federal court pro se (representing himself) in the 90's and actually winning - resulting in established precedent that states that software is protected under free speech - thus, programs containing certain cryptographic schemes that fall under the U.S. munitions export law is good to go as long as its packaged within software.

From that point over the next 20+ years, Daniel Bernstein has busted his ass & reaped the rewards.

The Real Problem

The issue here isn't with Bernstein but rather that its *just Bernstein* that seems to be diligent, motivated & hard working enough to continue moving the world of cryptography forward.

Instead of complaining, the rest of the world needs to just step their shit up to reach the bar that Daniel Bernstein has set, because at this point he's on his way to becoming the greatest cryptographer of the 21st century.

Bash Script Used to Create Op_Hash160 Outputs (Bitcoin)

Just created a snippet containing a bash script to transform an input into 'op_hash160' (plus another iteration of sha256 may be included, not sure ; if so, I'll clean it up regardless).

All necessary notes are here along with the script itself = https://gitlab.librehash.com/-/snippets/1

Gave links to a couple sites that provide free no-login execution environments for Ubuntu if you don't want to run a bash script from the internet on your primary machine (which I would never recomend in any universe unless you trust where the repo is coming from + its signed) .

Petitioning the Maintainer of 'Gocryptfs' to Import Argon2id Hashing Alongside Scrypt (or as a drop-in replacement)

Follow along with the issue here: https://github.com/rfjakob/gocryptfs/issues/520

Why you should care

Because I wrote up a mean script for this that allows for the creation of super secure gpg keys, w a private key encryption passfile that's ephemerally generated in 'RAM' in a stateless manner using a generic password (of your choosing) as the 'input'

I am going to abstract this onto a GUI that users can navigate using Jupyter Lab for a teaching experience / demo, then I'll make it a shiny, clean app.

Modern commercial (+ open source) password managers, vaults, cloud storage, etc., is woefully lacking when it comes to security parameters, and I hate that. I want to use the best cryptographic schemes available and utilize the libraries, code, & published cryptographic schemes available to us to their fullest extent - why not?

Closed Down the Previous Issue on 'Gocryptfs' and Opened Up Another One Declaring the Use of 'Scrypt' in Gocryptfs is a Vulnerability

Full stop.

This didn't need to be covertly relayed to the maintainer of that project because there is more than enough public information re: the shortcomings of Scrypt and there have been others that have brought up the inclusion of Argon2 as either an alternatives or an outright replacement for Scrypt.

The issue can be found here: https://github.com/rfjakob/gocryptfs/issues/522

Subsequent Measures

1. Will open up another issue that briefly breaks down the benefits / properties of Argon2 as a KDF (specifically the many that Scrypt fails to provide). In addition, the fact that there are three instantiations of this KDF that, in itself, serves as an adjustable parameter means that not only are users receiving superior security (comparative to Scrypt), more informed users are given the opportunity to tweak the algorithm in a way that flexibly addresses their unique threat environment / perceived adversary

2. Currently collaborating with the maintainer of gocryptfs on this (hopefully; the step-by-step breakdown of how to swap out Scrypt was done when this was first brought up to the lead maintainer as everyone can see above)

Pull Request Will Be Made Before the End of the Week

In my opinion, this should be considered a time sensitive issue because the successful implementation of a cache timing attack on someone using Scrypt means that they have put themselves in a position to viably extract the original password...and since this password is what gets piped into 'gocryptfs' to mount containers, the solution itself (file system encryption overlay) is equally as vulnerable since the password serves as the encryption / decryption key.

Katacoda Deployment Coming Soon

For those not familiar, Katacoda is most well-known (for me at least), for their hosting & always available 'Ubuntu Playgrounds'.

A 'playground' is essentially an "environment" that's containerized, sandboxed and ephemeral.

To simplify that, Katacoda provides access to a terminal that's running an OS like Ubuntu. The purpose of doing this is to allow users to practice running different commands or even spin up a project you came across on GitHub that you don't want to clone onto your personal computer / expose a localhost port to the internet.

These playgrounds come with full-blown, regularly featured Ubuntu instances. Obviously not without resource constraints imposed since this is free, but they give you a very, very generous & workable leash on it.

I've personally never had my connection to one of Katacoda's terminal throttled, and I've pulled in a few dozen GBs before in a session (don't be a dick & abuse this, these folks are providing a free service that helps folks out - they don't deserve to be punished for that)

Warning Users Against the Use of Gocryptfs

So the individual behind the 'gocryptfs' fs encryption tool for UNIX systems (that means Linux / BSD here), refuses to replace Scrypt with Argon2id.

Already opened up two issues about this on their GitHub (not going to open up another one). Published a study outlining the issues with Scrypt in a nutshell.

Issues

1. Scrypt is a memory-hard hash algorithm. You use it to hash passwords typically. Its purpose is to make brute forcing passwords more costly for the attacker by forcing them to utilize a bunch of memory / time for each password guess attempt.

2. Scrypt is vulnerable to cache timing attacks. This is not a theoretical attack as it has been pulled off in the wild with success.

3. Argon2id is designed to address all of those issues

4. Considering how Scrypt is used in the grand scheme of things for 'gocryptfs', this struck me as an imperative change that needed to be made imminently given the various means of compromise that would involve an attacker being able nestle deep enough within a Unix system to disturb the cache during a Scrypt operation, allowing for the subsequent extraction of information (the PBKDF2 secret).

Original Developer Refuses to Fix it

He closed the issue. So in my opinion, gocryptfs should be considered vulnerable until otherwise patched.

If there is a known attack against an implementation that can be exploited, then that's what it is - period. If you as a developer refuse to incorporate a drop-in replacement that's demonstrably better in all facets that mitigates the entire problem then.. we have to question the intentions of the original developer.

Petitioning the Maintainer of 'Gocryptfs' to Import Argon2id Hashing Alongside Scrypt (or as a drop-in replacement)

Follow along with the issue here: https://github.com/rfjakob/gocryptfs/issues/520

Why you should care

Because I wrote up a mean script for this that allows for the creation of super secure gpg keys, w a private key encryption passfile that's ephemerally generated in 'RAM' in a stateless manner using a generic password (of your choosing) as the 'input'

I am going to abstract this onto a GUI that users can navigate using Jupyter Lab for a teaching experience / demo, then I'll make it a shiny, clean app.

Modern commercial (+ open source) password managers, vaults, cloud storage, etc., is woefully lacking when it comes to security parameters, and I hate that. I want to use the best cryptographic schemes available and utilize the libraries, code, & published cryptographic schemes available to us to their fullest extent - why not?

Closed Down the Previous Issue on 'Gocryptfs' and Opened Up Another One Declaring the Use of 'Scrypt' in Gocryptfs is a Vulnerability

Full stop.

This didn't need to be covertly relayed to the maintainer of that project because there is more than enough public information re: the shortcomings of Scrypt and there have been others that have brought up the inclusion of Argon2 as either an alternatives or an outright replacement for Scrypt.

The issue can be found here: https://github.com/rfjakob/gocryptfs/issues/522

Subsequent Measures

1. Will open up another issue that briefly breaks down the benefits / properties of Argon2 as a KDF (specifically the many that Scrypt fails to provide). In addition, the fact that there are three instantiations of this KDF that, in itself, serves as an adjustable parameter means that not only are users receiving superior security (comparative to Scrypt), more informed users are given the opportunity to tweak the algorithm in a way that flexibly addresses their unique threat environment / perceived adversary

2. Currently collaborating with the maintainer of gocryptfs on this (hopefully; the step-by-step breakdown of how to swap out Scrypt was done when this was first brought up to the lead maintainer as everyone can see above)

Pull Request Will Be Made Before the End of the Week

In my opinion, this should be considered a time sensitive issue because the successful implementation of a cache timing attack on someone using Scrypt means that they have put themselves in a position to viably extract the original password...and since this password is what gets piped into 'gocryptfs' to mount containers, the solution itself (file system encryption overlay) is equally as vulnerable since the password serves as the encryption / decryption key.

Dropped a Lot of Gold on a Scott Helme Blogpost

Shoutout to Scoot Helme, he has the best compendium of articles on the internet when it comes to strengthening the provisioning of your website via TLS, CA issuance, hooks, cert pinning, etc.

In particular, there was this one article here where Scott mentions a 'backup CA' (ZeroSSL; personally thought that they were 'out of business' or just leaving things up to LetsEncrypt).

See here: https://scotthelme.co.uk/introducing-another-free-ca-as-an-alternative-to-lets-encrypt/

Scott is correct about this, but I did follow up to ask him if he could double check on the cryptographic strength of the cert being issued because LetsEncrypt has stepped their game way the hell up this year.

Additional Onion Cert Validation

There was also someone that erroneously commented on the post, stating that there was no constructive purpose to having a TLS cert on an .onion domain.

This could not be further from the truth and there are CAs that do offer them. None of the free CAs do however because this requires Extended Validation (i.e., 'EV Cert'). Those are the certs that light up green in your browser and have the organization's name directly in the 'omnibox' (search bar) as well.

Benefits of an .onion Cert

1. Users visiting your .onion will be assured that they are visiting your organization's .onion. Since .onion domains are merely composed of random alphanumeric strings (via ed25519 for v3 ; just like Bitcoin addresses), there are no other external validators that can be used to prove which .onion address is truly yours or not. However, with a .onion capable certification, you're able to list your .onion as an alternate domain on your main cert, which would allow individuals to cross reference the .onion address they're visiting with the information on the cert on your main website.

2. This will enable users Tor browsers to connect to your website using the .onion network over TLS 1.3 as well (yes, the security benefits do stack; this is why the Browser forum approved this measure in the first place). I was able to 'hack' up a setup for the Librehash App portal to allow proxy forwarding via .onion to the clearnet website. The issue with that in most setups is that they're configured incorrectly by the admin, which leads to the leakage of packet information (even as users are connecting via an .onion domain). However, by proxy forwarding the .onion domain connection over port 80 after having an Apache server listening on that same port (within a container) to forward those connections back through over https (443), I was able to sufficiently provide .onion + TLS strength protection for those .onion websites (visitors can double check on this by downloading Wireshark and inspecting their packets as they visit any one of those apps via their .onion domains)

^^^ A guide will be published on this relatively soon if anyone else is looking to do this.

AES Has Been Shown to be of Questionable Security in a Number of Different Cryptanalysis Studies Dating Back to 1999 (when it was first released)

This may be presumptuous, but based on a second look at literature, it may be prudent for the cryptography community to begin distancing itself form AES (sooner than later).

Cryptanalysis attacks against AES include:

1. DA (differential analysis); this is analyzing the actual computations being done by the hardware machine as the cipher operation is taking place. (https://eprint.iacr.org/2003/010.pdf)

2. Side-channel attacks (extremely effective on full round AES-256) [https://cr.yp.to/antiforgery/cachetiming-20050414.pdf]

3. 'Algebraic Attacks' (https://www.cosic.esat.kuleuven.be/ecrypt/AESday/slides/AES-Day-CarlosCid.pdf)

AES128 is deprecated by the NIST.

Hmm. (it appeared to be 256 from what the author is saying here, I'll follow up)

AES EME mode (two layers of 'lightweight mixing' in between) ; some different modes we don't really get to talk about a lot when it comes to AES encryption.

This specific 'mode' of AES comes with a security proof.

http://seclab.cs.ucdavis.edu/papers/eme.pdf

There's going to be a lot that gets flooded in here over the next hour or so. So, notifications (alerts) will be turned off as they are.

Follow it in live time or come back & read later. Enjoy.