The idea is this:

1. Beginning with a classic user management situation (for some service / access controlled resources)

2. Using LDAP for user management. More specifically, OpenLDAP.

3. Argon2ID as the password mechanism (stick with me - I’m aware of what the RFCs say about SCRAM - we’re not going to go out of standard here)

If you’re not familiar with SCRAM authentication, then you should look here: https://en.m.wikipedia.org/wiki/Salted_Challenge_Response_Authentication_Mechanism

Semantic cryptography = https://euske.github.io/nlcrypt/index.html

Skein

1. More than likely the most secure hash function on planet earth.

2. Skein-1024 is integrated with 'Threefish' (with a threefish bit strength that matches that of the Skein implementation) ; 1024 = 1024 (ratio perfect)

2a. Addressing the concerns regarding Threefish and the alleged attacks that were found on several of its rounds (response from one of the co-authors of Threefish [as well as Skein] = https://crypto.stackexchange.com/questions/11725/has-threefish-successfully-been-attacked-practically-or-theoretically/11727

2b. Attack in question was mentioned in this paper (published by the team ) = http://www.skein-hash.info/sites/default/files/skein1.3.pdf

^^^ SHA-3 finalist (but Keccak was the hash function that won out ; Ethereum is using Keccak as we ll, but not the same iteration as w hat was submitted to the NIST)

3. Threefish McOE Mode = https://eprint.iacr.org/2011/644.pdf [exponentially more secure than the original Threefish - seems that there are *very few individuals out there right now that even know that this exists*] <— that's interesting, going to have to do more homework on this

—-

Is it possible to draw from an implementation of Skein-1024 that utilizes Threefish (1024) McOE mode?

Link that attests to the fact that SKein-1024 is the equivalent of 2^452

'8gWifi': Site with Some Good Cryptography Tools on it

Here's the link = https://8gwifi.org/docs/ ; nothing mind blowing, but seems to be pretty useful if you need a reference point for some functions or ... whatever else you may be using these operations for.

'8gWifi': Site with Some Good Cryptography Tools on it

Here's the link = https://8gwifi.org/docs/ ; nothing mind blowing, but seems to be pretty useful if you need a reference point for some functions or ... whatever else you may be using these operations for.

Anti-Cryptography Bill = https://www.judiciary.senate.gov/press/rep/releases/graham-cotton-blackburn-introduce-balanced-solution-to-bolster-national-security-end-use-of-warrant-proof-encryption-that-shields-criminal-activity

Perhaps one of the most nonsensical bills that I've seen in a long, long time.

Produced by three senators that don't appear to understand the concept of encryption on any meaningful (and that's being said with all due respect).

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.