"NOBUS" ('nobody but us')

This concept refers to a specific exploit / vulnerability that has been brought to the attention of the NSA that it decides to leave unpatched (or instructs the relevant vendor [i.e., Microsoft or Intel, for example, to leave unpatched]) in cases where the agency believes that they are the only ones with the knowledge, sophistication and resource to actually leverage a compromising attack against the software that utilizes the specific vulnerability / exploit that has been brought to their attention.

According to a statement from NSA Director Michael Hayden:

"You look at a vulnerability through a different lens if even with the vulnerability it requires substantial computational power or substantial other attributes and you have to make the judgment who else can do this? If there's a vulnerability here that weakens encryption but you still need four acres of Cray computers in the basement in order to work it you kind of think "NOBUS" and that's a vulnerability we are not ethically or legally compelled to try to patch – it's one that ethically and legally we could try to exploit in order to keep Americans safe from others."

The obvious stupidity in this policy is:

1. The idea that the NSA possesses such an inherent (and permanent) advantage vs. all others on planet earth that there could exist vulnerabilities / exploits that only it could exploit (and nobody else; American hubris at its finest possibly)

2. The idea that there are no 'double agents', 'spies' (etc.) that are embedded within the relevant intelligence agencies dealing with these secrets.

3. The failure to put a 'cap' or timestamped limit for when the vulnerability will be patched. For example, perhaps they find a vulnerability that they consider to be NOBUS in 2011, and decide to leave that exploit unpatched - when does it become patched? Surely, the NSA cannot have believed that they stumbled across exploits that nobody would ever be able to exploit at any point in time - either then or in the future, right?

4. The NSA has frequently made purchases of certain exploits on the 'grey market' from various vendors. To leave those exploits unpatched exhibits stupidity in its rawest form because, by virtue of the fact that there exists a 3rd-party vendor with the ability to find certain zero-day vulnerabilities in software (among other things), means that the assumption should be that there exists 3rd-parties (in general), with the capability to find the same bugs / exploits and leverage them by passing that information on to their respective intelligence unit(s).

This policy of 'NOBUS' has resulted in tens of millions of Americans becoming the victim of various data breaches, hacks, ransomware etc.

State Cannot Be Trusted With Decryption Powers

These powers continue to be abused at a level that breaches criminality.

Therefore, strong encryption is recommended at any and all costs.

The argument against child abuse is a valid one, even if used disingenuously by various agencies seeking to deprive citizens of their right to privacy. However, the gov't needs to find other ways to stop & prevent human trafficking and other sex crimes.

If they're decrypting communications after-the-fact, then they're already too late.

The goal should not be just to apprehend criminals, but rather find ways to prevent the crime itself from happening. Even if only pedophiles had their data accessed via an encryption backdoor (solely) and the gov't / law enforcement used that information to arrest said pedophile, the child whom the pedophile has harmed is still harmed.

The goal must be to prevent that child from being harmed in the first place. Settling for apprehending the offenders after-the-fact is a half-assed consolation prize that betrays the fact that the gov't (or whatever law enforcement making such arguments) may not really give a fuck about this issue.

Libsodium Documentation (great) = https://libsodium.gitbook.io/doc/memory_management

^^^ Memory management. Making sure that your keys / secrets aren't exfiltrated - this is important.

FSCrypt (should be putting this in the @librecryptography channel as well)

Think that this is a great file-level encryption tool for those that are looking for one (hell of a lot better than encryptFS where the author of that tool didn't want to get off of their ass to ensure that it was equipped with the latest & greatest as it pertains to standardized cryptographic algorithms - specifically KDFs [dumbass insisted on leaving Scrypt - which is vulnerable to side channel / timing attacks] - https://opensourcelibs.com/lib/fscrypt

FSCrypt uses Argon2i for its KDF (believe that it also leverages XChaCha20-Poly1305 for encryption as well (could be wrong on that - but check the encryption to see if this is something that I'm wrong about)

Testing 'webhook' briefly (disregard this message)

Was looking for something else related to Ethereum, but saw this Reddit comment & felt compelled to respond.

1. Ethereum's version of keccak is different than the SHA3 standard because they decided to move ahead before the authors of the algorithm sent in their final submissions (to the NIST competition; 'Blake' was another finalist here).

2. The "NSA" did not force the authors to tweak their algorithm. The U.S. agency responsible for holding the competition, liaising w teams, publishing information & ultimately adjudicating the competition was the NIST.

Apologies, I stated above that the NSA did not 'force' the researchers to make changes but looking closer here it appears the user actually stated that, "NSA modified some parts from Keccak256 and released it as the current SHA-3 after ethereum release, that's the reason ethereum uses keccak256 and not sha-3."

This is unequivocally false. And we know that its false because there were no changes made to the actual cryptographic algorithm.

Here's an excerpt from Wikipedia that explains this well (Wikipedia does an excellent job of breaking down tech & math-related concepts; just don't consult that site for anything that falls outside of that topic).

"The hash function competition called for hash functions at least as secure as the SHA-2 instances. It means that a d-bit output should have d/2-bit resistance to collision attacks and d-bit resistance to preimage attacks, the maximum achievable for d bits of output. Keccak's security proof allows an adjustable level of security based on a "capacity" c, providing c/2-bit resistance to both collision and preimage attacks. To meet the original competition rules, Keccak's authors proposed c=2d. The announced change was to accept the same d/2-bit security for all forms of attack and standardize c=d. This would have sped up Keccak by allowing an additional d bits of input to be hashed each iteration. However, the hash functions would not have been drop-in replacements with the same preimage resistance as SHA-2 anymore; it would have been cut in half, making it vulnerable to advances in quantum computing, which effectively would cut it in half once more."

Article mentions that Schneier went out on a limb here to say that the NSA had forced the authors to make change to the algorithm but this is simply not true...and he walked that statement back in an apology (source: *https://www.schneier.com/blog/archives/2013/10/will_keccak_sha-3.html*) <— note that Schneier had a competitor in this competition (Skein; this is a very cool hash algo).

Last two sentences up here are worth reading (remember this whole thing happened post-Snowden [as in Snowden just happened only slightly prior], so there was a lot of scrutiny on them as well as the selected winners).

End Result

"In response to the controversy, in November 2013 John Kelsey of NIST proposed to go back to the original c = 2d proposal for all SHA-2 drop-in replacement isntances. The reversion was confirmed [in] subsequent drafts and the final release."

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 noscript!) ; 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