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.

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.

Indistinguishability Obfuscation

This is a difficult concept to wrap one's head around, so maybe ask a real cryptographer at cryptography.stakcexchange.com , because they would be able to give you a more granular breakdown of it than this channel will.

New paper was published on this a few days ago: https://cryptome.org/2020/11/Indistinguishability-Obfuscation.pdf (peer-reviewed; IACR)

https://eprint.iacr.org/2020/1003.pdf

Here's the best way that this can be broken down:

1. This is sort of like homomorphic encryption (where an entity is able to maneuver and operate on top of encrypted data without decrypting the data or having knowledge of the underlying data being managed). The reason this comparison to homomorphic encryption is being drawn is because this is essentially a property that this cryptographic scheme must possess.

2. The goal of this cryptographic scheme is to allow for programs / packages to execute given commands & schemes without the instructions for said program being decipherable (i.e., the distinguishable part).

3. This would involve you feeding the program in question some sort of encrypted information that it could iterate upon to produce the desired result w/o ever needing to decrypt your input or the 'instructions' given to the machine

If this sounds like its impossible to you, then you're not the only that's held this belief. There are plenty of others that have been incredulous about the efficacy of this proposed cryptographic scheme for years (there are no working models yet, this is all purely theoretical)

OPAQUE: PAKE Protocol

This is another nod to one of those key protocols where you don't have to actually share the password with the server (that's always the best setup, right?).

The way that this works is a bit convoluted though.

Here's an article that puts it in laymen's terms: https://blog.cryptographyengineering.com/2018/10/19/lets-talk-about-pake/

Stumbled across this because it was close to a solution that we're seeking currently that would require clients in a high-threat environment (i.e., Tor Network) to complete some form of 'Proof of Work' before even being able to contact the server itself.

(Also, a round robin rotation for exit nodes possibly as well, with said nodes evaluating the request and its accuracy; this is incomplete, there's no incentive - but I guess there never was an incentive right?)

..Digression

Pay attentoin to #4 here (and #5)

How OPAQUE works:

A) Both the server and the client hold information necessary for client authentication, but neither one of them has enough for validation / authentication (at the onset)

B) Client has password / server has the salt ; server then sends the salt over to the client for a joint computation. This is referred to as the oblivious PRF.

With just that exchange of information, the client is able to authenticate. If you want to know the sorcery behind why this is the case, then visit the link that was published above and also make sure to go ahead and visit the first whitepaper published detailing the idea: https://eprint.iacr.org/2018/163.pdf

Claims to be 'aPAKE' security.

Authors state:

"We formalize this notion in the Universally Composable (UC) settings and present two modular constructions using an Oblivious PRF as a main tool..."

Converting ed25519 into Curve25519

It has been suggested around the world of cryptography (as well as the IETF), that public ed25519 keys can also serve as encryption keys as well (Montgomery Curves).

Here's a nodejs library for those looking to do so (novelty here) - https://www.npmjs.com/package/ed2curve

You can drop the keys right into the 'NaCL Box'

Speaking of the NaCL Box

Here's a 'Go' implementation of it: https://godoc.org/golang.org/x/crypto/nacl/box

(what is 'NaCL'?) - conventionally, its "salt" if we're going by the periodic table, but in this context, we're referring to the cryptographic library (and you use 'salt' in cryptography, get it?)

This library has extremely strong cryptography. The hyperlinked text above leads to Daniel Bernstein's site - we don't need to speak on how legitimate his algorithms tend to be (despite the weird wave of hate they've been getting from other jealous cryptographers that haven't been able to achieve the same level of notoriety that Daniel Bernstein).

Getting into the Actual Box Itself

Specifications (breakdown) of the box can be found on the nacl subdomain of the cr.yp.to site here = https://nacl.cr.yp.to/box.html

Essentially this 'box' provides an API-friendly, callable authenticated public key encryption tool for communications.

The entire scheme is setup with repudiation to provide plausible deniability (i.e., deniable authentication [dPAKE]).

A really good breakdown can be found here = https://crypto.stackexchange.com/questions/78071/what-does-crypto-box-actually-mean-in-libsodium-and-nacl

Crypto Stackexchange

Usually when it comes to any online message board, question & answer platform (like Quora / Yahoo! Answers back in the day), or general social media - you're rarely going to get the best of the bunch in terms of responses.

But StackExchange is clearly the exception.

The answers that the people on there give are mind-blowingly above & beyond what is expected on the internet. Anywhere. At any point.

In fact, the answers on StackExchange are so reliable, that many consider it to be a legitimate citation whenever facts are given with a direct reference behind it linking to the site.

Many Professionals on the Network

Individuals such as the creators of the Skein hash function, Blake2 / Blake3 among others (Zooko was one of the contributors to Blake3).

Implicit Certificates (specification by the secg ; same organization that published info on various ecdsa curves)

Here's the link = https://www.secg.org/sec4-1.0.pdf

'ECQV' is its abbreviation. Make sure that you remember that if you want to check up on it for yourself at any point in the near future.

Blake3 Hash Function

Purports to be quicker than all other hash functions (yes, even SHA1) by orders of magnitude.

Yes, these are the same folk that built blake2 (almost selected as the official keccak implementation; did not lose due to inferior security but rather due to 'speed reasons')

Here's the GitHub for any that wish to try it out = https://github.com/BLAKE3-team/BLAKE3

Its built in Rust. If you want it on the command line you're going to need to build up 'b3sum' (that's the ultimate binary that you're going to be calling in the terminal).

There are also binaries available in the releases though.

1. blake3 rust crate = https://crates.io/crates/blake3

2. b3sum rust crate = https://crates.io/crates/b3sum

3. Blake3 Paper (explaining the specifications, design rationale, caveats & features) = https://github.com/BLAKE3-team/BLAKE3-specs/blob/master/blake3.pdf