Next Download : FTLDNS

Complements Unbound (not competing) + introduced to the world by the same makers of PiHole.

Check out their write-up on it here: https://pi-hole.net/2018/02/22/coming-soon-ftldns-pi-holes-own-dns-dhcp-server/

Next step: Encrypted DNS (Strong Encryption)

This is where we top it all off.

This setup was written in Rust, but its very well-documented.

Open Source [BSD License as well? ; check].

Here's the link = https://lib.rs/crates/encrypted-dns

Super easy setup, which is always a win.

Here's the link to the cryptography embedded this thing in the source code = https://github.com/jedisct1/encrypted-dns-server/blob/master/src/crypto.rs

Possible to swap out w liboqs to enhance / elevate the cryptography in this? Why not.

Additional protocols supported by this setup:

A) DnsCrypt v2

B) Anonymized DNSCrypt

C) DNS-over-HTTP (DoH)

Link (again) = https://lib.rs/crates/encrypted-dns

Cryptography Underpinning XMPP

1. 'Off-the-Record Messaging' = https://otr.cypherpunks.ca/

2. 'OMEMO' = https://conversations.im/omemo/

Read through the specifications ; OTR is what helps make XMPP extremely secure in terms of sending messages back and forth from one party to the next.

Advanced Cryptographic Ratcheting = https://signal.org/blog/advanced-ratcheting/

(From Signal's Website) ; discusses 'Forward Secrecy' and how Open Whisper Systems operates on a similar principle in order to strengthen the secrecy and security of the messages being shared from one user to the next.

Encryption Fears

Lately, there has been a lot of news regarding statements made by the current presidential administration (Trump) for the United States re: cryptography + encryption.

The reality of the situation is that, as of right now, there is access to very strong cryptography as well as a wealth of documentation available for those that search.

However, the permanence of such information is in question.

Thus, while we can, we're going to continue to aggregate as many resources / repositories / etc., and do our best to continually elevate + upgrade our means of storing said information by adding as many means for viable storage as possible.

Reality:

It sucks that a technological (and largely, mathematical) innovation is, in itself, being branded as a 'threat'.

The argument against encryption could essentially be made against the internet or any other technological innovation that has been leveraged for evil.

The idea behind weakening encryption or making some levels of encryption illegal to be deployed in production use is that it prevents the government from being able to pierce through the veil of secrecy that some nebulous hypothetical terrorist organization may or may not use in order to prevent a catastrophic terrorist event.

To date, this hasn't happened and more than likely won't happen.

As stated in the first post of this channel, society's focus must be on figuring out, "Where did this desire for violence/harming children come from? How did it grow to this point? What are we doing to even foster such an element?" <— Because if we're at the point where the gov't cannot trust anyone to hold cryptographic tools of a certain strength out of fear that well-formed alliances will plot mass murder / destruction, then society has reached a level of depravity that mandates higher concern and attention be placed on the underlying reasons for why rather than simply focusing on preventing its consequences.

Conclusion

This channel will continue as normal, without stop.

We find it hard to acquiesce to any demands / laws / restrictions against posting academic information meant to inform individuals - especially in a world where hacks / malware / identity theft / exploits are rampant and the largest tech conglomerates in the Western world (i.e., Microsoft / Google / Amazon), seem to be able to operate with impunity, regardless of what shortcomings they may have.

If the government cannot protect its citizens, then it must not fault those same citizens for taking the responsibility for protection into their own hands.

Outlining Our First Steps Toward a Post-Quantum VPN

For those that do not know, we're working on a fork of Mullvad's post-quantum VPN deployment (using Wireguard).

There is public code posted in their repository for it (linking to Rust crates) , but unfortunately - the repository hasn't been updated since 2017.

However, that's not really an issue because the only serious update needed is to the liboqs signatures.

There have been various different implementations / redactions / changes made among the NIST post-quantum crypto competition finalists (in addition to the announcement of an entirely new round in Jan. 2019) since Mullvad originally published the code for their Rust-based fork of Wireguard.

More information can be found in our first installment here: https://libre.fail/post-quantum-vpn-setup-part-one-scratch-work

Interesting statements from status.im regarding their plans to allegedly “fork” ‘Whisper’ [appears they’re referring to a co-opted version of double ratchet encryption / OTR]

Passwords / Storage / End User Security (for sysadmins ; re: latest add to this header)

1. Solid resource that details good information about secure password hashing methods = http://crackstation.net/hashing-security.htm

2. This is a really old Stackexchange answer, but it doesn't address the OP by breaking down cryptographic primitives, but rather using *sound logic* that will probably remain true until the end of time = https://security.stackexchange.com/questions/211/how-to-securely-hash-passwords/31846#31846

*Potential Issues With SHA256 Hashing*

1. Bitcoin uses SHA256, which has created an inherent problem in using SHA256 for password hashing because there is now a thriving ecosystem (worth billions of dollars) of organizations that have developed advanced silicon chips and "ASIC" miners that are designed with the sole intention hashing SHA256 as quickly & efficiently as possible

a. proof #1 (link from Bloomberg detailing how Bitmain's valuation was north of $15 billion at one point in time = https://www.bloomberg.com/news/articles/2019-06-21/bitmain-is-said-to-revive-ipo-plan-as-bitcoin-hits-one-year-high ; Bitmain is a Bitcoin mining company)

b. proof #2 (link from Bloomberg detailing Canaan's $90 million IPO last year = https://www.bloomberg.com/news/articles/2019-11-21/bitcoin-mining-company-canaan-raises-90-million-in-u-s-ipo ; they are yet another Bitcoin mining firm)

c. live video showing an actual Bitcoin mining facility (one of many) = https://www.youtube.com/watch?v=Ri5djo3EOGI

2. SHA256 can be compromised via length extension attacks / malleability issues / side channel timing attacks
a. reference #1 ; (research paper detailing side channel attacks against SHA256 = https://ieeexplore.ieee.org/document/8210596 )
b. reference #2 ; (detailed answer exploring the issue of malleability in sha256 = https://crypto.stackexchange.com/questions/1801/what-type-of-hash-functions-provides-non-malleability-of-hash-digests )
c. reference #3 ; (detailed report explaining how length extension attacks are carried out against sha256 = https://blog.skullsecurity.org/2012/everything-you-need-to-know-about-hash-length-extension-attacks)

3. The NSA created SHA256

4. The NSA then moved away from using SHA256

openssl genpkey -algorithm x448 -out cert.pem

openssl pkey -in key.pem -pubout (public key portion of the pairing)

—

OpenSSL 1.1.1 recognizes ed448 certificates

End to End User Credential Protection (details can be found at this URL here): https://scotch.io/@liesware/end-to-end-user-credentials-protection

Specifically, using the Coherence server in order to leverage argon2id + SHA3_HMAC for password storage (which would be the safest & smartest option by a fucking mile)

EVP_PKEYs = https://wiki.openssl.org/index.php/EVP

Part of what makes SCRAM SHA 512 plus possible (for Cyrus SASL with OpenLDAP as our authentication mechanism)

^^^ Still curious on how to have {CRYPT} render argon2 hashing by default (is this a scripting issue?)

We do need to make sure that it is consistent on the platform that we're running as well as the platform that we're doing this off of.

The best way to do this would be if we were going to pull from the same API.

Either that, or we could just mask the hashes of the password & simply have an authentication process (for a 'lookup db')

OpenSSL LDAP 2.4.49 = https://www.openldap.org/software/release/changes.html

Solid guide here =https://crackstation.net/hashing-security.htm

Minio May Be the Way to Go for Cloud Storage

1. Distributed (this is critical, because we really need to make sure that the storage is not all in one location or we're fucked) [documentation = https://docs.min.io/docs/distributed-minio-quickstart-guide.html]

2. Extraordinary Amount of Security Here for the Minio Servers = https://docs.min.io/docs/minio-kms-quickstart-guide.html

(could get really greedy here and opt for a post-quantum compiled OpenSSL in order to create exponentially stronger keys that can be used to move from location to location)

^^ This is how a true cloud solution should be deployed if you want to ensure that your users are actually kept safe [which none of these mother fuckers hold a fidelity to].

Vault Project (could be used for integration as a backend storage for the LDAP server ; in order to ensure that we aren't keeping everything on the LDAP server)

1. https://www.vaultproject.io/docs/auth/ldap

2. Enforces access to 'secrets' (can stand in as a "mid-point" of enforcement for protecting user credentials)

(more information about how we will be storing user credentials can be found here = https://medium.com/@harwoeck/password-and-credential-management-in-2018-56f43669d588)

Perfect fucking flow that shows the passage of how we're looking to store these secrets

[some of the logic used in other parts of this article are questionable though - so we'll leave that where it is]