An Energy-Efficient Configurable Lattice Cryptography Processor for the Quantum-Secure Internet of Things = https://cloud.libreha.sh/wl/?id=zPDi9G2UMsPEeuA37fmVpJYobGhnLKnr

This research report is being posted in here because it *cracks the door open* on the possibility that a more *energy-efficient* means of hashing out results could be deployable on the Bitcoin protocol at some point.

This, of course, requires a lot of assumptions and the logistics of such a 'swap' is not even remotely discussed in this paper (it has nothing to do with blockchain).

But if we extrapolate the study itself, the observations it makes and the potential implications of what this report tells us, it at least provides itself as useful fodder for conversation / musing.

Perhaps we'll throw this on the forums (launching soon) underneath the 'cryptography' section for discussion if anyone is interested in the near future.

BCrypt = http://bcrypt.sourceforge.net/ ("A cross platform file encryption utility. Encrypted files are portable across all supported operating systems and processors.")

BeeCrypt = http://beecrypt.sourceforge.net/ (A portable and fast cryptography library)

Botan = http://botan.randombit.net/ (A crypto library for C++)

Crypto++ = https://github.com/weidai11/cryptopp (A free C++ class library of cryptographic schemes)

digestpp = https://github.com/kerukuro/digestpp (C++11 header-only message digest (hash) library)

Note: The digest library is experimental

According to the GitHub it, "Derived from cppcrypto in an attempt to devise a more modern yet flexible and universal C++ API for cryptographic hash functions."

—-

Quick FAQ:

'What is a Message Digest Library?'

"Message digests are secure one-way hash functions that take arbitrary-sized data and output a fixed-length hash value." ; (source: https://docs.oracle.com/javase/7/docs/api/java/security/MessageDigest.html)

——

The GitHub gives a few hypothetical examples of how this would work in practice using some well-known hash functions.

Example #1 ; related to the 'digestpp' that we were discussing

'Hasher Class'

Quick Recommendation: Mute This Channel Today

There are going to be a slew of updates in here today. The messages will be “muted” on our end, but you’ll still receive a silent notification / pop-up on your phone if you don’t have us muted.

We’ll try our best to be tactful with how we post in this channel, but there’s a ton of information that’s really worth distributing that’s been vetted out already (we’re not just forwarding you any random links about cryptography).

We’ll compensate for it by creating a website / blog of some sort to hold some of this content.

If you’re worried about forgetting about this channel, we will probably send out a “reminder” message that we’re here w updates every day or so.

Multiple Public-Key Algorithm X.509 Certificates (Draft ; IETF) | link = https://tools.ietf.org/html/draft-truskovsky-lamps-pq-hybrid-x509-01

We stumbled upon this link when looking for a way to create an enhanced VPN solution where we could verifiably prove no logs (i.e., allowing individuals to SSH in to spun up servers that were all load shared w one another via Kubernetes or some sort of similar type of container software) <—- if that were to happen, we could just have individuals visit the IP address on the surface of the Docker container.

Walking Through the Potential Homegrown PQ-VPN Solution

At a default, we don't need to be cryptographic experts in order to create a solution like this.

We just need to make sure that we are using audited + transparent (open source at least), well-maintained software that has been appraised by numerous individuals of repute that have something to lose if they were to put their names behind something that fails to meet the sniff test.

Of course, it helps that there are already established libraries, so there isn't really guesswork in terms of where the sources are being pulled (if we were to start combing through the code to assess the veracity of what certain providers are saying).

First, the client needs to be selected.

There are a couple of options but most know that you're going to be forced to choose between:

A) Wireguard

or

B) OpenVPN

The latter is much more popular than the former (OpenVPN > Wireguard), but both solutions are more than serviceable.

Turns out that Microsoft recently released a PQ-VPN client (open source) for users to download.

Yes, yes, it is Microsoft and they of course own GitHub...

But if you do not trust their code specifically (this is impossible for a lay person to seriously audit w effectiveness), then users can always grab the liboqs library and swap out the cryptographic standards (use the PQVPN as a template)

Sources:

1. https://www.microsoft.com/en-us/research/project/post-quantum-crypto-vpn/

2. https://github.com/Microsoft/PQCrypto-VPN

They actually have the binaries for the PQ-VPN client if people would like to use it.

Works in pretty much the same exact fashion as the prior non-PQ versions of OpenVPN would've worked .

GUI and all. Deploy OpenVPN on a server somewhere and encrypt your connection.

Source: https://github.com/Microsoft/PQCrypto-VPN/releases

That message about the third-party notices and deploys is...interesting ; but there is a former version of the project available on that same repo that one must assume does not have whatever Microsoft felt needed to be added on after the fact.

Wireguard

Ridiculously serviceable. Interface & means of operation are both very intuitive.

Doesn't work off of certificates of any sort but rather via PKI + handshakes

They call it 'Cryptokey Routing'

https://www.wireguard.com/#cryptokey-routing

So Potential Solution

1. Wireguard (speed will be key here in this setup because there are going to be a lot of additional moving parts that could bog down the connection a bit)

— Specifically, the setup that Mullvad deployed is useful because it gives us a concrete template/roadmap for swapping out some of the already strong algorithms embedded in Wireguard for even stronger ones.

The relevant link can be found here = https://github.com/mullvad/oqs-rs/pull/3/files

Doesn't get too much more straightforward than what you see above in this diff file.

Component #2 - PiHole

Let's assume that the backbone (Linux ; Ubuntu for the Kernel) of this setup is a given.

On top of deploying Wireguard, we want to also deploy PiHole with it as well so that we not only encrypt our connection but re-establish peace of mind and greater web security as well.

PiHole explanation + documentation can be found here = https://docs.pi-hole.net/

Specifically, it is defined as a "DNS Sinkhole" [their words; but it is also accurate]

Guide on Installing PiHole on a Server With Wireguard = https://www.sethenoka.com/build-your-own-wireguard-vpn-server-with-pi-hole-for-dns-level-ad-blocking/

This guide above is amazing for those that are looking to research more about how to add PiHole to their server setup (Wireguard custom).

Btw, this is how easy it is to install Wireguard on Linux ; don't want anyone to think that we're doing something super high level yet at this point.

If you're able to copy & paste those two commands into a terminal - congratulations, you now have a Wireguard server (we won't get into the config files & other stuff ; but if you're willing to read closely + follow instructions, you'll be ok)

Next Download: Unbound

What is Unbound, you ask?

Great question.

Per NLnetlabs, Unbound is:

"A validating, recursive, caching DNS resolver. IUt is designed to be fast and lean and incorporates modern features based on open standards."

Source: https://nlnetlabs.nl/projects/unbound/about/

You all can read so there's no reason to break down anything more than that that's on the page - but to put all of what was said above in laymen's terms —- Unbound is what will help you ensure that your DNS requests are going to the right place and that you're getting the right response.

Fortunately, it appears that the statement made above is now validated with an independent, 3rd-party audit as well (golden standard in the world of online software these days) = https://ostif.org/our-audit-of-unbound-dns-by-x41-d-sec-full-results/