Only Hardware Wallet For Blockchain That's Probably Worth Considering = https://www.thalesgroup.com/en/markets/digital-identity-and-security/press-release/gemalto-and-ledger-join-forces-to-provide--security-infrastructure-for-cryptocurrency-based-activities-

Reasons

1. Produced / Manufactured by Thales ; a company with a far-reaching reputation in the cyber security and cryptography space (you're getting top of the line when you're dealing with these guys)

2. They don't tip toe around the concept of an HSM in hopes that unsophisticated customers will merely look at the raw dollar value of funds that need to be protected without delving deeper into the world of cryptographic key protection (which is really what this is ; and there is a thriving ecosystem in the corporate / enterprise environment for HSM software + devices that can be leveraged by competent dev teams to ensure that funds aren't being raided by 17 year old hackers a la Twitter)

Overall, this is still probably overkill in the grand scheme though. I think that a sufficient means of securing one's keys (hence, their crypto funds) can be derived from resources that are available online.

Fortunately, we at Librehash have taken it upon ourselves to derive such a solution for this very in-demand task (which is needed in all honesty ; especially when considering that the so-called hardware wallet companies are failing to remain secure)

Quick test to ensure that we are indeed integrated w the RSS feed.

Stumbled upon this post from the LibreSwan team detailing that IPSec is essentially impossible on Amazon's Web Servers (regardless of how they are tweaked or configured).

More concerning though is the fact that general tests to check connectivity provided a false positive

https://libreswan.org/wiki/Interoperability

End-to-end Encryption Guide by Matrix = https://matrix.org/docs/guides/end-to-end-encryption-implementation-guide

Library that they use = 'libolm'

Specs for Megolm Encryption Ratchet = https://matrix.org/docs/spec/client_server/r0.4.0#m-megolm-v1-aes-sha2

Specs for Olm Encryption Ratchet = https://matrix.org/docs/spec/client_server/r0.4.0#m-olm-v1-curve25519-aes-sha2

Few More Informative Links About Various Topics in Cryptography

1. https://hcis-journal.springeropen.com/articles/10.1186/s13673-019-0193-6 (research paper detailing PKE ; an alternative to the McEliece + other code-based / lattice cryptographic signatures)

2. Phenomenal Presentation That Explains Picnic (PQ Algo) = https://asiacrypt.iacr.org/2018/files/SLIDES/TUESDAY/Z411/post%20quantum%20signatures%20-%20asiacrypt18v2.pdf

3. Efficient FPGA Implementations of LowMC and Picnic = https://eprint.iacr.org/2019/1368.pdf

4. Performance Evlauation of Round 2 Submission for the NIST Post-Quantum Cryptography Project = https://digitalcommons.wpi.edu/cgi/viewcontent.cgi?article=8471&context=mqp-all

5. "server.passdb.ovpn" (from the post-quantum forked OpenVPN Repo) = https://github.com/microsoft/PQCrypto-VPN/blob/master/openvpn/config/server-passdb.ovpn

6.

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 noscript 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 noscript 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 noscript 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 noscript 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 noscript 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.