Zax

This is a pretty cool project. Apparently, they're an "NaCL-based Cryptographic Relay"

Here's their GitHub - https://github.com/vault12/zax

On their GH they state, "Zax is a NaCL-based Cryptographic Relay, easily accessed via the Glow library ('glow' is a repo under 'vault12' on GH). Zax relay nodes are asynchronous 'dead drops' for mobile communications. Relays are intended to be multiplied for reliability and form a distributed network. Individual devices send messages to a mutually deterministic subset of relays and check the same for response traffic."

Question on Crypto StackExchange about Viability of EC256 and SHA256

Hoping to get answers to this soon - https://crypto.stackexchange.com/questions/95458/nsa-removed-ec256-and-sha256-from-cnsa-recently-should-we-be-alarmed-by-this

Kind of concerned about it, but don't want to raise flags on something prematurely.

One of the experts can help sort that one out.

This astronomical question did not get sufficiently answered - which is worrisome. But we'll leave that on the side for the time being (this will be addressed in short fashion)

Post-Quantum Signature Curves = https://csrc.nist.gov/projects/post-quantum-cryptography/round-2-submissions

1. Guideline That Outlines How to Create GPG Keys With an Advanced Algorithm = https://www.gniibe.org/memo/software/gpg/keygen-25519.html

2. Covering the Types of Encryption Covered by Bitcoin = https://wiki.gnupg.org/ECC

3. Another Great Resource on Elliptic Curve Cryptography = https://arstechnica.com/security/2013/10/a-relatively-easy-to-understand-primer-on-elliptic-curve-cryptography/

4. OpenSSL Cheat Sheet (meh, could be useful) = https://www.thesslstore.com/blog/openssl-commands-cheat-sheet/

5. Agent Configuration (for GPG) = https://www.gnupg.org/documentation/manuals/gnupg/Agent-Configuration.html

6. GNU Privacy Guard (operational GPG Commands) = https://www.gnupg.org/documentation/manuals/gnupg-devel/Operational-GPG-Commands.html

7. A Ton of Useful Information RE: Using GPG Keys For Virtually All Purposes = https://wiki.archlinux.org/index.php/GnuPG#Encrypt_a_password

8. Code Signing & Verification With OpenSSL = https://eclipsesource.com/blogs/2016/09/07/tutorial-code-signing-and-verification-with-openssl/

9. Breaking Down KeyFiles on Veracrypt = https://www.veracrypt.fr/en/Keyfiles.html

10. Sign and Verify Public Keys Via the OpenSSL Command Line = https://raymii.org/s/tutorials/Sign_and_verify_text_files_to_public_keys_via_the_OpenSSL_Command_Line.html

11. Breaking Down OpenSSL Encryption Techniques = https://gist.github.com/dreikanter/c7e85598664901afae03fedff308736b

12. More Useful Information Regarding OpenSSL (specifically encryption & decryption with IV + AES) = https://security.stackexchange.com/questions/188457/how-can-i-use-openssl-to-decrypt-aes-encrypted-data-using-the-key-and-initializa

13. Veracrypt (explaining how key files are leveraged on the protocol) = https://www.veracrypt.fr/en/Keyfiles.html

Great link on Hardening One's GPG Configuration

https://www.designed-cybersecurity.com/tutorials/harden-gnupg-config/ (check that out here) ; maybe this gets crossposted into libresec / who knows!

MPFR: For precise arithmetic in the calculation of values (this is especially important when it comes to cryptographic computations; this is done at the sake of some speed, but when a precise value must be calculated, this is the library that is generally used [perhaps on a remote server first to ensure that any compromises on the host do not impact the results that are gleaned back from it]) = https://gforge.inria.fr/frs/?group_id=136&view=shownotes&release_id=10837

Desirable S-Box Properties - https://crypto.stackexchange.com/questions/1297/desirable-s-box-properties

Transcrypt (bash script!) ; its just like git-crypt except a little bit cooler than that if you really know what you're doing here) = https://github.com/elasticdog/transcrypt

Adiantum: Wide-block mode. This is not a primitive but rather a scheme of some sort (utilizes a combination of XChaCha20 + AES) <—- but where's the AEAD part that you get with the poly1305??

Ah, its in there per an explanation of the specifications.

States, "It works by first hashing almost the entire plaintext using a keyed hash based on Poly1305 and another very fast keyed hash function called NH"

NH? Never heard of that (hashed key function).

Feistel Network: Allows you to decrypt ciphertext that has been hashed right? Not sure need to check in on that

All information gleaned from above coming from Google = https://security.googleblog.com/2019/02/introducing-adiantum-encryption-for.html

HCTR: A Variable-Input Length Enciphering Mode (this sounds extremely fucking interesting)

I wonder if there's any way that the hash of a cipher text can be taken since hashes are not invertible (but encryption is).

Feels like it would be a really good idea to encrypt a hashed output (specifically ; not signatures though).

I only say what I said above because if the hash is being used to obfuscate / hide something, then the encryption will ensure that in the worst case scenario, someone will only find a hashed out / mixed version of what they're to decipher (and there's a considerable burden to be able to get to that point).

Need to Definitely Test for the AEAD Quality of This (perhaps if the hash was encrypted with XChacha20 - poly1305?)

Thinking that there's some version of this idea that ties into what I was thinking as it pertains to hash chains.

Hash Chains

I was wrong about my initial impression but also possibly on to something as it pertains to the hash tree that could be created with Blake.

Hash / Merkle Tree Concept

Rather than just creating an appended list (sort of like blockchain) and then adding an additional operation that merely hashes the last input, it feels like it would be prudent to have all of the values hashed together in some capacity.

So that means:

1) H = x

2) H(x)

3) H(H(X))

4) H(H(H(X)))

There's something that's missing in this construction.

Only way that this could work is if the generator of the hash chain kept at least a few values secret.

But it is impossible for this to be done in a way where all of those values are kept secret and this be seen as externally valid.

The only other way is to ensure that all of the values are public. But if you must do that then you need to devise another method that will require people to remain honest bc you've trapped off their avenues for "cheating".

This is why the write-up on the way that time is calculated on the blockchain is extremely fucking important - it is an objective source of randomness that keeps everyone honest if it can be adhered to.

The idea that I had about the UNIX time tracking was interesting, but ultimately one critical underpinning here (hmm...)