Forem: librehash

Deploying Firecracker VMs

librehash — Wed, 05 Oct 2022 23:47:41 +0000

GitHub URL for the project - https://github.com/firecracker-microvm/firecracker

Description - "Secure and fast microVMs for serverless computing."

Also - "Firecracker is an open source virtualization technology that is purpose-built for creating and managing secure, multi-tenant container and function-based services that provide serverless operational models. Firecracker runs workloads in lightweight virtual machines, called microVMs, which combine the security and isolation properties provided by hardware virtualization technology with the speed and flexibility of containers."

More on the Project

Written in Rust (that's a delectable plus). Looks like this was actually created by Amazon, I believe (still open source ; relax Pedro).

Yup, confirmed within the Git repo - "Firecracker was developed at Amazon Web Services to accelerate the speed and efficiency of services like AWS Lambda and AWS Fargate. Firecracker is open sourced under Apache version 2.0."

The VM operates with a VMM (virtual machine monitor), which leverages the KVM (Linux) to create & run 'microVMs'.

The virtualized environments are designed to be secure by default (according to the project specs); this is done by "[excluding] unnecessary devices and guest-facing functionality to reduce the memory footprint and attack surface area of each microVM".
Firecracker can be integrated with other container runtimes like 'Kata Containers' (this is another project that we're going to get to in a second) + 'Weaveworks Ignite' (fuck them)

More information on the project can be found here - https://firecracker-microvm.github.io/

More Helpful Info About the Project

Supports all modern processor types pretty much ; Intel / AMD / ARM (last one is a present surprise as well)
Is built w security in mind in its design (via the minimalism of the VM creation); also, its meant to isolate VM instances entirely from the actual OS / root system in a manner that plugs up leaks pretty comprehensively.

More on the Inner Workings of 'FireCracker'

Below is a picture from the main site that the project claims illustrates an "example host running Firecracker microVMs".

Claim that the VMs use so little resources that one could plausibly "run thousands of microVMs onto the same machine"
"This means that every function, container, or container group can be encapsulated with a virtual machine barrier, enabling workloads from different customers to run on the same machine, without any tradeoffs to security or efficiency" (okay! this is a pretty big claim, but I like it ; would like to see the 3rd-party evaluations of how much this project adheres to that promise in practice)
"Each Firecracker microVM is further isoalted with common Linux user-space security barriers by a companion p rogram called 'jailer'"; 'the jailer provides a second line of defense in case the virtualization barrier is ever compromised' (so they're really gun-ho on the idea that the VMs constructed with this tool are of a caliber capable of preventing any and all 'escapes' / 'leaks' from the VMs [people will always try to find a way though]
"The Firecracker VMM is built to be processor agnostic. Intel processors are supported for production workloads" (that last statement implies that this project is only built for Intel in any practical sense) ; especially with the follow-up that, "Support for AMd and ARM processors is in 'developer preview'" (what's that?)
The virtualization software that they most closely compare this tool to is 'QEMU' (which is fucking amazing, I will accept zero slander on QEMU ever or on the developer - Fabian - that created QEMU virtualization because he's a fucking genius when you look at what he's managed to do)

There are a 'gaggle' of projects that are also able to run 'Firecracker'. Those are (from the website):

'Appfleet'
'firecracker-containerd'
'fly.io'
'koyeb'
'kata containers'
'OpenNebula' (used this a couple of times; wasn't a huge fan of it although it was easy to setup at the time)
'Qovery'
'UniK'
'Weave FireKube' + 'Ignite'

How to Actually Deploy Firecracker

Wasn't even going to get this fire down the rabbit hole, but these folks tempted me - so here goes nothing.

**"You can build Firecracker on any Unix/Linux system that has Docker running and 'bash' installed" (using the following code):

git clone https://github.com/firecracker-microvm/firecracker
cd firecracker
tools/devtool build
toolchain="$(uname -m)-unknown-linux-musl"

Additionally, "The Firecracker binary will be placed at build/cargo_target/${toolchain}/debug/firecracker. For more information on building, testing, and running Firecracker, go to the quickstart guide."

Quick Start Guide - https://github.com/firecracker-microvm/firecracker/blob/main/docs/getting-started.md

Quick Start Guide & Instructions Once the Initial Build + Installation Code Has Been Run

Firecracker uses KVM and needs read/write access that can be granted as shown below

sudo setfacl -m u:${USER}:rw /dev/kvm

Also need to ensure that the user running the VMs has "read write access to '/dev/kvm'"

Directions on How to Set Up Read/Write Access to /dev/kvm - https://github.com/firecracker-microvm/firecracker/blob/main/docs/getting-started.md#appendix-a-setting-up-kvm-access

"Firecracker is linked statically against musl, having no library dependencies. You can just download the latest binary from our release page, and run it on your x86_64 or aarch64 Linux machine."

(Once the firecracker binary has been downloaded [instructions above], we just need to ensure that we've moved the binary into /usr/bin so that we can use it liberally in CLI)

Additionally, here's a 'building from the source section - https://github.com/firecracker-microvm/firecracker/blob/main/docs/getting-started.md#building-from-source

Running Firecracker

"In production, Firecracker is designed to be run securely, inside an execution jail, carefully set up by the jailer binary. This is how our integration test suite does it. However, if you just want to see Firecracker booting up a guest Linux machine, you can do that as well."

We need to first obtain an "uncompressed Linux kernel binary, and an ext4 file system image (to use as rootfs)" ; great, these are two things that we need to seek out before we move forward in our 'adventure' (this really feels like a "quest" of some sort, like the ones that they forced you to play on Runescape back in the days)

How to Decompress Linux Kernel (explicit instructions to be honest here) - https://0xax.gitbooks.io/linux-insides/content/Booting/linux-bootstrap-5.html

Linux-Hardened Kernel - https://github.com/anthraxx/linux-hardened (this is something that they're all still actively working on at this very point in time)

They also say that we need an 'ext4 file system image' (where do we obtain this from?) - found it

Full Guide on How to Create an EXT4 filesystem image here -https://fabianlee.org/2020/01/13/linux-mounting-a-loopback-ext4-xfs-filesystem-to-isolate-or-enforce-storage-limits/

Assuming that the above has been handled, the directions insist that we create two separate shell prompts, (one to run Firecracker, and another one to control it [by writing to the API socket]; both shells have to run "in the same directory where the firecracker binary was placed")

^^ What?

This is a pain in the ass because this is something that they should've mentioned earlier (obv. everyone is going to move a binary where the rest of their binaries go ; and you're not going to just load up some random project to be used in that manner)
Not even sure what the end goal of opening up an API socket here would really be

But fuck it, let's just assume that we play ball and we adhere to all of these (additional) steps that we're being put through (just for the setup up this virtualization tool!).

Following Through on the Next Steps

Ensuring that Firecracker can create its own API: rm -f /tmp/firecracker.socket
Then start Firecracker: ./firecracker --api-sock /tmp/firecracker.socket

^^ That's just for the "first CLI window" ; for the second one, we must do the following.

"Set the guest kernel (assuming you are in the same directory as the above script was run)"; they're saying this because they provided code for folks that don't have the necessary kernel image to be running this out of the gate - but we will be picking up a kernel from elsewhere. Either way, the following code should be copasthetic

arch=`uname -m`
kernel_path=$(pwd)"/hello-vmlinux.bin"

if [ ${arch} = "x86_64" ]; then
    curl --unix-socket /tmp/firecracker.socket -i \
      -X PUT 'http://localhost/boot-source'   \
      -H 'Accept: application/json'           \
      -H 'Content-Type: application/json'     \
      -d "{
            \"kernel_image_path\": \"${kernel_path}\",
            \"boot_args\": \"console=ttyS0 reboot=k panic=1 pci=off\"
       }"
elif [ ${arch} = "aarch64" ]; then
    curl --unix-socket /tmp/firecracker.socket -i \
      -X PUT 'http://localhost/boot-source'   \
      -H 'Accept: application/json'           \
      -H 'Content-Type: application/json'     \
      -d "{
            \"kernel_image_path\": \"${kernel_path}\",
            \"boot_args\": \"keep_bootcon console=ttyS0 reboot=k panic=1 pci=off\"
       }"
else
    echo "Cannot run firecracker on $arch architecture!"
    exit 1
fi

"Set the guest rootfs"

rootfs_path=$(pwd)"/hello-rootfs.ext4"
curl --unix-socket /tmp/firecracker.socket -i \
  -X PUT 'http://localhost/drives/rootfs' \
  -H 'Accept: application/json'           \
  -H 'Content-Type: application/json'     \
  -d "{
        \"drive_id\": \"rootfs\",
        \"path_on_host\": \"${rootfs_path}\",
        \"is_root_device\": true,
        \"is_read_only\": false
   }"

"Start the guest machine"

curl --unix-socket /tmp/firecracker.socket -i \
  -X PUT 'http://localhost/actions'       \
  -H  'Accept: application/json'          \
  -H  'Content-Type: application/json'    \
  -d '{
      "action_type": "InstanceStart"
   }'

side note: seeing 'curl' here reminded me that that's something that needs to be downloaded & instantiated on our default Docker images (Rust version specifically)

From here, they state, "Going back to your first shell, you should now see a serial TTY prompting you to log into the guest machine" (guessing that this will be the case for us too - basic Ubuntu image should be more than necessary)

Also, "When you're done, issuing a reboot command inside the guest will actually shutdown Firecracker gracefully. This is due to the fact that Firecracker doesn't implement guest power management."

They also include this one note: "The default microVM will have 1 vCPU and 128 MiB RAM." ; this obviously isn't enough for what we want to do - but that's no problem as this can be configured w relative ease.

They state, "If you wish to customize that (say, 2 vCPUs and 1024MiB RAM), you can do so before issuing the InstanceStart call, via this API command" (that's annoying that we need to use API commands here for that, but that's cool):

curl --unix-socket /tmp/firecracker.socket -i  \
  -X PUT 'http://localhost/machine-config' \
  -H 'Accept: application/json'            \
  -H 'Content-Type: application/json'      \
  -d '{
      "vcpu_count": 2,
      "mem_size_mib": 1024,
      "ht_enabled": false
  }'

Configuring the microVM Without Sending API Requests

they must have read my mind!

"If you'd like to boot up a guest machine without using the API socket, you can do that by passing the parameter --config-file to the Firecracker process. The command for starting Firecracker with this option will look like this:" ./firecracker --api-sock /tmp/firecracker.socket --config-file <path_to_the_configuration_file>

They claim that the path_to_configuration_file, "should represent the path to a file that contains a JSON which stores the entire configuration for all of the microVM's resources" (okay this is fair enough).

Also, they stipulate, "The JSON must contain the configuration for the guest kernel and rootfs, as these are mandatory, but all of the other resources are optional, so it's your choice if you want to configure them or not. Because using this configuration method will also start the microVM, you need to specify all desired pre-boot configurable resources in that JSON."

File Names for the Pre-Boot Resources (included within the greater repo here):

firecracker.yaml - Names of resources are contained here ; 'file and the names of their fields are the same that are used in API requests' (cool)
tests/framework/vm_config.json (boilerplate config file to guide us - great)

From here: "After the machine is booted, you can still use the socket to send API requests for post-boot operations."

Conclusion

Somewhat of a pain in the ass (just looking through the directions); the fact that we'd have to go grab a uncompressed kernel image + file system image (`) is kind of a fucking hassle / burden.

Was hoping for a solution more akin to Docker where it can just be spun up real quick & then deployed. But they claim that this 'jailer' feature (that they keep hyping) will ensure (I guess?) that whatever is done within the container will remain within the container (and not escape).

I haven't seen anything that sticks out about this project that leads me to believe that it possesses that capability, but I definitely don't want to rule it out.

Extra Documentation + Information

OSv Running on 'Firecracker' (yay more work though) - http://blog.osv.io/blog/2019/04/19/making-OSv-run-on-firecraker/
Building OSv Images Using Docker - http://blog.osv.io/blog/2015/04/27/docker/
firecracker containerd (this is something that's probably important for the overall mission of what we want to accomplish here) - https://github.com/firecracker-microvm/firecracker-containerd

Firecracker Containerd

Description - "firecracker-containerd enables containerd to manage containers as Firecracker microVMs*"

"This repository enables the use of a container runtime, containerd, to manage Firecracker microVMs. Like traditional containers, Firecracker microVMs offer fast start-up and shut-down and minimal overhead. Unlike traditional containers, however, they can provide an additional layer of isolation via the KVM hypervisor."

They Also Identify Potential Use-Cases in the Repo Such as

"Sandbox a partially or fully untrusted third party container in its own microVM. This would reduce the likelihood of leaking secrets via the third party container, for example."
"Bin-pack disparate container workloads on the same host, while maintaining a high level of isolation between containers. Because the overhead of Firecracker is low, the achievable container density per host should be comparable to running containers using kernel-based container runtimes, without the isolation compromise of such solutions. Multi-tenant hosts would particularly benefit from this use case."

Really interesting feature of this repo here is: "A root file filesystem image builder that constructs a firecracker microVM root filesystem containing runc and the firecracker-containerd agent." (that could save a lot of time on that whole filesystem image thing that they were mentioning prior)

Additional Links of Importance

Getting Started Guide - https://github.com/firecracker-microvm/firecracker-containerd/blob/main/docs/getting-started.md
Quickstart Guide - https://github.com/firecracker-microvm/firecracker-containerd/blob/main/docs/quickstart.md
A Root Filesystem Image Builder - https://github.com/firecracker-microvm/firecracker-containerd/blob/main/tools/image-builder
Runtime Linking Containerd - https://github.com/firecracker-microvm/firecracker-containerd/blob/main/runtime

Documentation All Located Here - https://github.com/firecracker-microvm/firecracker-containerd/tree/main/docs (definitely fucking needed because there's a lot here to wrap one's head around)

Design Approaches Doc - https://github.com/firecracker-microvm/firecracker-containerd/blob/main/docs/design-approaches.md
Shim Architecture - https://github.com/firecracker-microvm/firecracker-containerd/blob/main/docs/shim-design.md
Launching 4k VMs Using Firecracker - https://github.com/firecracker-microvm/firecracker-demo
firectl (CLI options for manipulating this tool from terminal ; this is important as well) - https://github.com/firecracker-microvm/firectl [damn, there's a lot that came with this here!]

Monero Wallet Backdoor Attempt

librehash — Wed, 05 Oct 2022 23:33:54 +0000

This was originally composed and published circa April/May 2021 on the Librehash blog and shared widely across several social media platforms; this piece served as the seminal entry point to a series of deep-dives and research into the Monero protocol and its shortcomings as a privacy coin (specifically, 'shortcomings' refer to vectors of compromise and in this context 'compromise' refers to transaction traceability)

URL of the Git Repo in question that got torn to pieces in this write-up = https://github.com/tevador/monero-seed

Before I go into the reasons for why I strongly believe that this is a backdoor, I'm going to start off by just pointing out a few thing wrong with this wallet implementation.

I'm doing this to establish that I did not arrive at this conclusion about this user's potentially nefarious intentions after misreading their potential incompetence, lack of qualifications for the project that they're attempting to undertake.

Also, since we're here, we might as well point out all of the facets of the wallet implementation that are inexcusably insecure

"Embedded wallet birthday to optimize restoring from the seed" (this makes the wallet markedly more insecure then it needs to be by including unnecessary information that essentially leaks more info that should've otherwise been left private)
advanced checksum based on Reed-Solomon linear code <-- this is another baffling break from convention here that's inferior to the standard used (CRC32) [this is the modern standard currently] / "Some file formats, particularly archive formats, include a checksum (most often CRC32) to detect corruption and truncation and can employ redundancy or parity files to recover portions of corrupted data." /// Not to mention that CRC32 is typically used for "digital networks and storage devices to detect accidental changes to raw data" ; this is the most likely vector of compromise for users in this context [attacker gains nothing by corrupting the underlying data]

Unexplained Departure From BIP32/39 Convention

The URL for the BIP39 construction: https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki

The link above has the original specification for BIP39 (mnemonics, which is what is the construction that this individual claims to be adhering to BIP39); evidence of this claim below from the user's repo:

Incorrect Mnemonic Word Count Selection

I'm not sure if this individual thought the mnemonic phrase word count was an arbitrary choice, but it isn't.

Entropy is used to generate a binary strong of 128 -bits (depending on the user's specific implementation). After appending the checksum (4-bits additional), the words are generated from the binary string - with strict mappings to the BIP39 dictionary.

This is mandated by the BIP39 specification (as seen below):

They use 14 mnemonic words (which deviates entirely from the normal convention).

They state that the phrase contains "154 bits of data", which are used for "future use", "wallet birthday', "128-bits for the private key seed", and "11 bits for checksum".

This is extraordinarily incorrect. Normally a BIP32/39 key is derived by:

Generating 128 bits of entropy (for example)
Hashing the entire 128 bits of entropy (with the chain's hash algo); then extracting the first 4-bits and appending that to the end of the 132 bits of entropy (that's the checksum; this person didn't even specify how they were going to derive the checksum)
Those 132 bits is supposed to be divided by 11 equal parts (resulting in 12 different "words"). Every 3 words = 32-bits of entropy; there are 4 groups of 32, which calculates back up to 128 (can't forget the additional 4 bits for the checksum).

Explanations For Decisions Make Zero Sense

Not only has this individual deviated significantly from the standard (which I had qualms with as is, but that's aside from the point).

Under the "reserved bits" section, they make statements that diverge from any logical cryptographic sense entirely.

I'm not sure why they're under the impression that bits can be "reserved" for some other purpose (what the fuck does that mean?). This entropy is part of the normal BIP39 construction that generates the entropy for the purpose of having users pipe the UTF-8 NKFD result into the PBKDF-HMAC-512 construction to derive a key.

There is no such thing as "reserving bits". Either bits are being used or they aren't.

Statements Made About the 'Bits' Reflect a Fundamental Failure to Understand EDDSA

The subheading for this section may seem a bit harsh, but its honestly an understatement at this point in time.

Also, what is meant by a "flag to differentiate betwen normal and 'short' address format"?

The public Monero address is a concatenation of the public spend key + public view key. They're both derived as two different valid points on the Edwards' Curve.

The publication, 'Zero to Monero' corroborates this as well:

There are two different sets of coordinates used because ed25519 keys can be used for both encryption and signing (unlike ecdsa / secp256k1). Monero takes advantage of this fact and does this by essentially granting individuals a public key that individuals can encrypt to (public view key) ; the public spend key is how they derive a subaddress based on what they know (the mission-critical nature of these addresses can't be understated since this all ties into the construction that Monero uses to protect against double spend attempts)

So I'm puzzled at why this user proposed having the "view key equal to the spend key"; not only does this make zero fucking sense, it also would make Monero exponentially less secure by orders of magnitude.

In fact, at a glance, this would entirely erode nearly all of the privacy on the protocol.

Where This User's Actions Make Me Believe They Are Setting Up a Backdoor

If you scroll down that GitHub page link that I provided, you'll see a header that says, 'Private key seed'.

This is the first spot where I observed that this user had reduced the security of the key derivation function (for no apparent reason).

See below:

Specifically they state:

"The private key is derived from the 128-bit seed using PBKDF2-HMAC-SHA256 using 4096 iterations. The wallet birthday and the 5 reserved/feature bits are used as a salt. 128-bit seed provides the same level of security as the elliptic curve used by Monero"

Ah! No! All of this is wrong & almost maliciously so.

Let's start from the top though.

This User Weakened the Key Stretching Function From BIP39

There is no conceivable reason for them taking this action (and this is actually something that would unique compromise users on the chain and I'll explain how).

First, let me establish that this individual did indeed weaken the strength of this key stretching function (PBKDF2-HMAC construction).

Below is a specification from BIP39 (Bitcoin):

Going further, if we look at the key length / bit / strength information provided by a matrix table from Wikipedia (these values were cross-referenced with the NIST specifications; this can be done independently by anyone reading along as well):

Please keep in mind that security in the sense of cryptography refers to the strength in 'n' bits (hence the security against collision attacks).

Therefore, the difference between 256-bit strength and 128-bit strength is a hell of a lot more than 2x; the difference is probably several hundred million times (and that's more than likely me low-balling it hard as fuck; i.e., 2¹²⁸ vs. 2²⁵⁶)

Weird Nuance in the HMAC Convention Would Cause Collisions With Their Proposal

Since they elected to go with PBKDF2 - HMAC256 (vs. 512 variant), we need to take care to consider the length of the input being piped into this hash function.

Specifically, according to RFC2104:

"Keys longer B bytes are first hashed using H" [source = https://tools.ietf.org/html/rfc2104]

This, notably creates a seeming collision, where the sha256 of the input is the same as its HMAC (in essence); this essentially nulls the purpose of the HMAC in the first place.

This is detailed in this post here = https://mathiasbynens.be/notes/pbkdf2-hmac (the individual provided NodeJS + Python code for the reader to attempt to simulate on their own machines if they wanted to - very benign article)

It Appears That This User Neutered the HMAC Portion Entirely

This is a real problem at this point. And the omission of HMAC in this scheme the user is designing cannot be chucked up to ignorance or "not knowing".

Again, as shown above in the prior section, this user's reference to BIP39 shows that they have had exposure to the specification.

So there's no conceivable reason for removing the HMAC (key stretching) function from this scheme they're crafting.

Individual's Claim About the Strength of the Entropy vs. Strength of Curve Are 100% False

Under the same section as the dubious private key entry, the user states:

"128-bit seed provides the same level of security as the elliptic curve used by Monero."

Monero doesn't use elliptic curves
No it fucking doesn't

Entropy is not "security", nor is it ever factored into the bit-strength of the "elliptic curve" or the 'Edwards Curve' in this case.

These curves are geometric functions that depend on the assumed hardness of the discrete logarithm problem as their security assurance.

This is well known information...

Downgrading of Argon2 to PBKDF2

This one is inexcusable in any universe.

The commit was made on June 14th, 2020:

https://github.com/tevador/monero-seed/commit/f1c7829f043322849c0323f58aa0a46352de4e02

Visiting the commit directly, we can see this individual adding PBKDF2 to the project while simultaneously removing Argon2.

Nevermind the fact that this is oddly coded in 'C', which is a curious language choice for a simple library (there are many, much lighter weight and easier ways to implement this).

One particular qualm about 'C' is that its not memory safe ; which means that we aren't afforded protection from the program overflowing (which is more than realistic and, perhaps plausible, considering the input block length)

Explaining Why the Argon2 Swap Was Ludicrous

If you were to ask any security professional on planet earth what their opinion was on the best hash algorithm (for ensuring your information remains behind an impenetrable fortress.

For those familiar with mining, you may remember that hash algorithm - after all, its used in Monero.

Password Hashing Competition

Recently, there was an international competition that sought to find the latest and greatest in the world as it pertains to KDFs (key-derivation functions).

While said competition may seem a bit preposterous, it did indeed exist. And it was hosted, followed and adjudicated

source: https://www.password-hashing.net/

No Conceivable Reason For the Replacement of Argon2

Argon2 is exponentially stronger than PBKDF2.

Multiple experts in the field of cryptography and elsewhere have vouched for it as being the strongest password-hashing algorithm out there.

And we just so happen to find ourselves in a situation where we're deriving a key that we need to keep secret.

Which means that there would be no better KDF to use.

Example of How to Derive a Monero Address From an Argon2 KDF

There's live (open source) code on the internet that can be audited and/or compiled to test the veracity of this construction.

Any reader visiting the link will be taken to a cool module built from the WarpWallet principle utilized by Keybase.

Here's the URL = https://patcito.github.io/mindwallet

Address generation process is deterministic (just like ed25519), so that's good for this scheme. The entire code runs client side and is available for users to download at their leisure to deploy Golang / Python as your preferred language to interact with

Reed-Solomons Code Weakens the Mnemonic Selection

See below:

This should be wholly impossible if the key is constructed properly.

Ian Coleman's Library

Ian is one of the most prolific PoC composers this space will ever know.

And lucky for us - he has one for BIP39 as well, which should allow us to get a general gist of the security of this assumption

Below is a screen of the site:

source: https://iancoleman.io/bip39/

Notably, Ian's specifications for the mnemonic word options mirror the actual implementation too:

If we utilize the 'BIP39 Split Mnemonic' feature, that's when we'll see a concise estimate of how long it would take to break to crack a wallet where the user has submitted in some of their too much for a second ("cards")

Brief (Really) Breakdown on Reflection Token Smart Contracts

librehash — Wed, 05 Oct 2022 23:13:45 +0000

this was originally written and published back last November (2021); obviously, we've learned a decent amount about such smart contracts in the time since - so keep this in mind when reading

this was the write-up that got crushed when my computer froze ; 16GB of RAM on her, but with nearly 2-years under her belt, its time to put her out to pasture soon enough -- not today, though! So let's fucking get to it without wasting any more time

This was mentioned before in the Discord, but some individuals from Binance(?) under the guise of 'Huh Token' reached out to give me a few tasks.

I'm going to take some time briefly to summarize those tasks to:

Give readers a better sense of the expertise of the one proposing this project idea
A better understanding of the concept of 'reflection tokens', overall
An intuitive understanding of just how difficult it is to instantiate such a project (for those that may be wondering, 'If this is such a good idea, how come everyone is not doing it?')
A sense of the general smart contract auditing pipeline for those that are unfamiliar with it.

Starting with the Certik Audit

This encounter was actually the first time I had ever come face-to-face with a smart contract that had been audited by Certik.

As we all know, Certik has caught a ton of flack over the last year or so after several projects they reportedly audited ended up having their smart contracts exploited / plundered (for one reason or another). Reviewing their audit was an activity I found to be enlightening because it ended up shifting my opinion on Certik from them being an incompetent auditing firm to them being a firm that has received unnecessary flack.

If that statement is surprising, then you should continue reading into the next section.

Spotting Simple Errors in the Smart Contract

Before taking a look at the Certik audit, I decided to delve into the smart contract code directly myself.

Specifically, I wanted to take a look at the 'HuhFlattenToken.sol' contract they had under the git repo (forked / branched over to my account).

You can find that here: https://github.com/Librechain/HuhToken/blob/main/contracts/HuhTokenFlatten.sol

You'll notice the errors begin around line 532 (we'll start from the BEP20 interface)

function distributeDividend(address shareholder) private {
    if (shares[shareholder].amount == 0)
        return; 

    uint256 amount = getUnpaidEarnings(shareholder);
    if (amount > 0) {
        totalDistributed = totalDistributed.add(amount);
        (bool success,) = payable(shareholder).call{value: amount, gas: 30000}("");
        require(success, "distributeDividend: Could not transfer funds!");

        shareholderClaims[shareholder] = block.timestamp;
        shares[shareholder].totalRealised = shares[shareholder].totalRealised.add(amount);
        shares[shareholder].totalExcluded = getCumulativeDividends(shares[shareholder].amount);
    }
}

Let's check out some of the comments that were made in that Certik Audit.

As we can see, the same code was identified & Certik is indeed correct here in stating that there is a major flaw here in the smart contract code that could lead to the draining of the smart contract.

Toward the beginning of the audit, a summary of the details uncovered can be found. Within that summary, we can see that the team had done little to nothing to rectify all of the issues published by Certik at the time (likely this is still the case since they do not have the expertise on hand to rectify all of the problem issues they identified).

From the image above, we can see that the vast majority of issues (of all severities) that were identified by the Certik team were not addressed (even though the project owners told me they were planning on launching at any moment).

This is indicative of how lazy + sloppy many smart contracts are 'in the wild' of blockchain (esp. as it pertains to BSC projects).

To be clear, the contract that I was looking at had:

Various 'reentrancy' flaws
No sanitized inputs for the contract
No implementation of 'SafeMath' (safemath.sol) to prevent buffer overflows on the reads (which would lead to memory corruption)

Main issue (from the Certik audit) was their failure to make sure that they 'zero out' the intermediate address balance of whomever has been granted permission to make a call on the contract (doing this is also necessary to make sure that the smart contract cannot be drained).

Addressing the Remaining Tasks Assigned for the Smart Contract

They threw me this very complex smart contract where they were looking to provide a "referral" for buyers of the token in the form of $BNB.

Referrers get 10% of the purchase amount from the contract. They also need to have their addresses whitelisted (+ referrer code; they insisted). Additionally, there is a tax applied to sellers to incentivize folks not selling any of this .

Normal seller tax = 15%; but if someone is a whistelisted seller, then the tax reduces itself down to 10% (in $BNB).

That tax then gets redistributed to those that are "providing liquidity". Some portion goes to those that are whitelisted referrers, then another portion goes to those that are "holders" of the
token.

And this all needed to be mounted up on a DEX (PancakeSwap specifically).

Specific Requests / Tasks to be Completed

Set things up so that this all would occur automatically (assuming someone possesses the requisite 'referral code' pointing back to th e referee).

I guess as an added twist, they failed to give me the actual smart contract code for the token / contract they were looking to launch.

They also didn't tell me who was responsible for creating the code that they already had in place at the time they asked me if I could do this. So there was nobody I was able to speak to about the situation to "catch up" and see where they were at with things.

So had to find the contract & then start out from scratch.

This wasn't all though.

Once I did find the actual code for the smart contracts (on GitHub), I had to walk through the smart contracts to get a sense for what it was doing / not doing (never seen one like this before).

There were some new functions in the code that I had never seen before (this is for Binance Smart Chain; not Ethereum).

Essentially they said their problem is that when a user made a call on the contract, there would be no automated transactions (this is impossible w blockchain anyway); but then they said whenever they made a subsequent transaction (initiated as the contract owner), that's when they would see the referral fees get paid out (but only during this event).

Identifying the Contract's Critical Function

When they said that, I knew I needed to look specifically at the part of the code that defined a regular, garden-variety transfer.

That's when I noticed the functions I had never seen before.

_rOwned & _tOwned ; never seen that construction in my fucking life in a smart contract. So that's when I went a-hunting.

Turns out that this concept derives from some project launched this year called 'reflect finance' ; https://reflect.finance/

Hardly any information on their website detailing what these functions are supposed to be doing in the code. Its important for me to figure this out because these "r"-prefixed balances were all over the place in the code.

Other Developers Stumped on these 'rToken' Values as Well

When I attempted to search online to glean more information about these variables in the code, I was surprised to find that there were others in the same boat as I seeking the same information.

One potent example can be found here - https://forum.openzeppelin.com/t/reflect-finance-variables/6888

The first response that this user received, however (from a 'Top Contributor'), was a bit disheartening.

Worst yet, it appeared that not even the modertors for the token had a firm understanding of what these variables mean/meant.

Reading through more replies, it became immediately apparent that there were few that truly understood the code at all (since there are no 'code notes' & the documentation for 'RFI' is non-existent at the time of writing, which is highly unusual).

Finding the 'Holy Grail'

Fortunately for us, there is one user out there that decided to take the intiative of dissecting the functions in their entirety via a whitepaper.

That post on OpenZeppelin can be found here - https://forum.openzeppelin.com/t/a-technical-whitepaper-for-reflect-contracts/14297

Of course, this resource has long since been saved since it will serve infinitely useful in the mid-to-long-term as we parse out more information from here for inclusion into the whitepaper itself.

The URL for this whitepaper can be found here - https://reflect-contract-doc.netlify.app/

Defining Reflect Tokens

The paper starts off by providing the following helpful introduction to these token balance types: "Before diving into the contract, a new concept must be introduced: t-space and r-space values, along with tTotal and rTotal. tTotal, which belongs to t-space, represents tokens in circulation or total supply of a token. On the other hand, rTotal, which belongs to r-space, is a reflected value of tTotal. The term “reflected” cannot be easily explained in words but one interpretation of rTotal is token supply in reserve. Furthermore, values in t-space can easily be converted to r-space form, and vice versa using formula"

As well as: "Stakers are users who earn passive income by holding native token. In contrast, non-stakers do not earn rewards. Router contracts, pair contracts, dev wallets are usually excluding from staking in order to fully reward users."

This results in the following graph (showing the 'workflow' for these types of tokens).

Which is powered by the following deflationary mechanism:

Creating a Secure, Sandboxed Docker Container

librehash — Wed, 05 Oct 2022 23:04:48 +0000

All of the information on how one would go about doing this can be found here: https://gvisor.dev/docs/user_guide/quick_start/docker/

Quick Breakdown on What This is

We're installing the gVisor here so that it can be run alongside any Docker container that is launched. There is significant reason for why this should be done (as it appears that Docker has been getting fried over the past year or so and we have the entire app portal running through the Docker at the time of writing ; therefore, we need to consider using this as a means of mitigating any potential vulnerabilities that could arise as a result of system calls being made outside of the sandbox + I'm not going to trust these mother fuckers up at Cloudron to be my last line of defense for this because I'm not entirely sure that they know what they're doing when it comes to ensuring security for Docker containers and we need to make sure that we are ultimately responsible for the security of our instance in a way that can't be covered by another 3rd-party configuration)

A guide on the actual architecture of this container can be found here = https://gvisor.dev/docs/architecture_guide/security/ (this is a meaningful read so that we can brief ourselves on how we're able to securitize against a number of potential vulnerabilities by using this tool)

Discussing Some of the Mitigations Afforded by the gVisor

On a personal PC level, we need to watch out for L1TF vulnerabilities (which come with older processors, hence the need for us to ensure that we're utilizing the latest generation ones; would prefer that it be AMD vs. Intel because it appears that they are more resistant to Spectre attacks overall, but this is still up for alteration contingent on what further information / research is uncovered to support / contradict this decision.

We will always go in the direction of empirical research.

Specifically, the project states:

"gVisor was created in order to provide additional defense against the exploitation of kernel bugs by untrusted userspace code."

Additionally enlightens us to the fact that bugs within the System API happen to be the most exploitable of all the bugs that are found within the kernel at a given point in time.

Mentions the incidence of hardware side channels, which we've already provided numerous mitigations for (on the home system; not entirely certain about what can be done for the 'away system' or the server setup itself -- this will come down, in part, to the hardware that the server is being ran on as long as we have it on a hosted server like Linode or something else)

Its a shame that the servers that we have running can't be ported over to OpenBSD, but that's also a fact of life created by OpenBSD since they're incompatible with virtualization (to a large extent; there is bhyve, but have never really explored that as something that can be viably used for anything meaningful -- perhaps this is a mistake of sorts, but there is nothing to my knowledge that this can be leveraged for ... perhaps this is worth looking into though /// will make sure to open a portion of the notes that are dedicated to address whether this should be the case or not)

First Step: Actually Installing Docker and Configure it Appropriately (takes two seconds max)

Download docker.io: sudo apt-get install docker.io whalebuilder subuser sen skopeo sen rootlesskit rkt docker-clean docker-compose docker-doc docker-registry
Once step one is complete, that's when a user must then run the following commands to ensure that Docker is setup and ready to go (added a few extra commands that are just useful to have in general): sudo systemctl enable docker then sudo systemctl start docker (one can add their user to the docker group, then 'cd' to the root [running cd /], and then run the command exec bash & that should refresh the terminal, allowing them to run commands via docker as a regular user instead of having to use 'sudo' all the time - cool)

Installing gVisor

This is actually the next step in the list that needs to be followed first (in order to get the runsc configuration setup)

Page can be found here: https://gvisor.dev/docs/user_guide/install/

Have to run this clunky ass code in order to make it all work:

(
  set -e
  URL=https://storage.googleapis.com/gvisor/releases/release/latest
  wget ${URL}/runsc ${URL}/runsc.sha512 \
    ${URL}/gvisor-containerd-shim ${URL}/gvisor-containerd-shim.sha512 \
    ${URL}/containerd-shim-runsc-v1 ${URL}/containerd-shim-runsc-v1.sha512
  sha512sum -c runsc.sha512 \
    -c gvisor-containerd-shim.sha512 \
    -c containerd-shim-runsc-v1.sha512
  rm -f *.sha512
  chmod a+rx runsc gvisor-containerd-shim containerd-shim-runsc-v1
  sudo mv runsc gvisor-containerd-shim containerd-shim-runsc-v1 /usr/local/bin
)

Assuming that the above step completes itself without any issue (again, this would be within a containerized container to begin with), then the next steps need to be run, which are:

/usr/local/bin/runsc install
sudo systemctl restart docker
docker run --rm --runtime=runsc hello-world

Don't need to necessarily run that last command, but that's simply to ensure that runsc has successfully been ran (this must be done after docker is installed)

Quick Note: Have to 'cd' into /usr/bin then check on the presence of runsc using 'fzf' (or just ls | grep runsc to see if its in a path where executables can be ran ; this is important, otherwise the other commands that need to be ran with 'runsc' won't be able to be ran from that point moving forward)

Believe That This is an Additional Step

So when I was initially running this in the container, I wasn't sure whether this step was an alternate means of downloading gVisor or supplementary to everything that had been done, but I just followed the step anyway because...why not ? (it didn't create any errors, conflicts or yield messages indicating re-installation of packages which = wasted time & resources).

Step One

Running the following:

sudo apt-get update && \
sudo apt-get install -y \
    apt-transport-https \
    ca-certificates \
    curl \
    gnupg-agent \
    software-properties-common

Then configuring the key for the signed archives and ofc adding the repo where gVisor is held at (so that we can pull it down via apt when we're finished)

curl -fsSL https://gvisor.dev/archive.key | sudo apt-key add -
sudo add-apt-repository "deb https://storage.googleapis.com/gvisor/releases release main"

Once all of the above has been completed, then 'runsc' can simply be installed via the packages (like a normal package at that point): sudo apt-get update && sudo apt-get install -y runsc

And boom, voila.

Configuring Docker to Use Runsc

Just need to run sudo runsc install first.
Then run sudo systemctl restart docker

Starting Up a Docker Container With the Runsc Runtime

We just need to specify it on the command line by adding in the '--runtime=runsc' directive amidst the usual commands that one would run with the docker container; for example: docker run --runtime=runsc --rm -it ubuntu /bin/bash
The command above should take us to a bash shell of an Ubuntu pull from their docker repos (read up later on Docker security as it pertains to tightening Docker to ensure that there are no "breaches" that occur as a result of pulling a bad image from a repository (there are fake / malware images out there that have been fucking people up ; additionally, we need to actually lockdown the Docker network to ensure that there are no compromises that occur through there either // following the CIS benchmark requisites should help -- again that will be touched on in a different piece)

OpenSea / Wyvern Protocol Notes (Draft - Unfinished)

librehash — Wed, 05 Oct 2022 22:58:05 +0000

Somewhat complex how this works.

OpenSea = lazy minting (doesn't mint until you actually execute the sale; seems like this is what got those users when looking at the stack trace of those transactions)
"It never tells you why and for what purpose you are signing transactions!" (curious; https://forum.openzeppelin.com/t/eli5-how-opensea-nft-works/7645)
"OpenSea uses the WyvernProtocol, an (audited, battle tested) system that creates a personal proxy contract for each user. We dont' control the proxies that get created, and you have to approve access to each ERC721 contract individually (and some contracts, like CryptoKitties, you have to approve each asset individually) before the proxy can access any of your assets."
"Once a proxy contract is approved, you can sign orders indicating you are willing to sell a given asset for a specific price. The logic of the exchange contract only allows it to transfer an asset from your proxy only if A) you have signed an order, and B) it is properly matched by a buyer paying the appropriate funds. So not only does your asset never leave your wallet, it's only allowed to be swapped if an order you create is properly matched." #foodforthoughts
"The proxy addresses are created programmatically and can't be changed"

Quotes above are from a Reddit where someone answered about the way Wyvern Protocol works - https://www.reddit.com/r/opensea/comments/a3tax6/opensea_security/

More Information about Creation of Proxy Contract by WyvernProtocol

Some decent information here - https://victoryeo-62924.medium.com/wyvern-protocol-in-opensea-nft-marketplace-b0cef9a9143a

Mainly:

"Every user has a proxy smart contract" (apparently this is created for them by the WyvernProtocol itself; so each proxy smart contract address should be unique to a given user on the OpenSea platform - cool, got it)
"Each item which is traded on OpenSea is owned by a Proxy smart contract of a user" (okay, more food for thoughts)

Curious Facts Regarding the Mandatory Use of Proxy Contracts for Authorizing Trade

As stated above, the Wyvern Protocol is responsible for generating unique proxy addresses for each user on the platform. These proxy addresses are what are ultimately responsible for granting / revoking permissions.

Specifically, one particular function seemed to be a source of trouble for many users on the OpenSea platform and that was the isApprovedForAll function (which is auto-overrided in the current Wyvern v3 spec). Specifically, that function was found within the ERC1155 and ERC721 smart contracts for OpenSea's platform.

The function was written as such:

function isApprovedForAll(address owner, address operator)
    public 
    view 
    override 
    returns (bool) 
{
    // allows gasless trading on OpenSea 
    return super.isApprovedForAll(owner, operator) || isOwnersOpenSeaProxy(owner, operator); 
}

Extracted this code from here = https://gist.github.com/dievardump/483eb43bc6ed30b14f01e01842e3339b/revisions (underneath the 'revisions' because the user that published these gists later redacted them out of concern for end-user compromise in lieu of the permissions granted by this type of smart contract)

More information about how this function works can be found directly on OpenSea's site:

https://docs.opensea.io/docs/1-structuring-your-smart-contract#opensea-whitelisting-optional

Worth noting here is the statement, "Additionally, the ERC721Tradableand ERC1155Tradable contracts whitelist the proxy accounts of OpenSea users so that they are automatically able ot trade any item on OpenSea (without having to pay gas for additional approval)."

Essentially what this means is that when a user purchases an NFT on OpenSea (i.e., they receive a ERC721Tradable / ERC1155Tradable) that user would typically need to grant explicit permission to their proxy contract before being allowed to trade any given NFT (within a collection). Making that request explicitly would require a separate transaction in itself (in addition to the one necessary to sell the NFT).

Thus, OpenSea allowed users to 'whitelist' their proxy address via the isApprovedForAll function.

From here, we're going to double back over to the WyvernProtocol code specification for their smart contracts, which you can find here: https://docs.projectwyvern.com/docs/ProxyRegistry/

Specifically, we're going to take a look at the registerProxy function (represented by function: ddd81f82), which allows one to, "register a proxy contract with this registry" (i.e., registry being OpenSea / Wyvern).

Registering a proxy contract with the registry requires the express permission of the user (via signature via Metamask). As we read above, each user on OpenSea has a proxy address provisioned for them. And in order for a user to save on gas / allow gasless listings & sales on OpenSea, they only need to forego overriding the isApprovedForAll function within the ERC standard contract (either 1155 or 721; depending on the type of NFT).

Remember that excerpt from OpenSea's website:

This is likely the point at which users were actually phished, because this access here is what facilitated the actual theft of NFTs from users at a latter point in time. That claim about this access being the inflection point for wallet compromise is proven via examination of transactions related to affected users. Specifically, the stack trace gives us more than enough information to begin pinpointing the culprit here.

Brief Note: The smart contract(s) that played a key role in the compromise of affected OpenSea users are not marked on Etherscan; the only exception is the smart contract that's used in the orchestration that's obviously attached (i.e., it actually emits various event during the execution of the transaction itself)

The specification for the WyvenProxyRegistry can be found here: https://abidocs.dev/contracts/0xa5409ec958c83c3f309868babaca7c86dcb077c1 (check out the contract name in the URL)

Below is the necesssary code template for those looking make this call on a smart contract (for whatever reasons):

function registerProxy()
    public
    returns (OwnableDelegateProxy proxy) 
{
    require(proxies[msg.sender] == address(0)); 
    proxy = new OwnableDelegateProxy(msg.sender, delegateProxyImplementation, abi.encodeWithSignature("proxies"[msg.sender] = proxy; 
    return proxy; 
}

A reference for functions attached to OpenSea's smart contract orchestration can be found here as well: https://abidocs.dev/dapps/opensea

Specifically, we're going to take a look at how one may want to make use of that function (vs. any of the myriad of other choices they have).

As one can see:

registerProxy doesn't have onlyOwner attached it. Functions that do have this modifier attached to them can only be called by the owner of the proxy contract. Yet as we can see one does not have to be the owner to call registerProxy
This is not an event, so nothing is emitted when this function is called
Within the context of normal OpenSea marketplace behavior, this function is only used when a user is lookiong to purchase an NFT. According to OpenSea "if you're buying an item on Ethereum, the transaction will show as 'registerProxy' / Register Proxy".

Proxy contracts exist underneath the umbrella of upgradable contracts. That's why you'll find the variable OwnableDelegateProxy littered throughout the example code we outlined above.

Let's take a look at some example code OpenZeppelin gives us for a vanilla contract proxy (will have some minor variances, but the gist is the same):

// This code has not been professionally audited, therefore I cannot make any promises about
// safety or correctness. Use at own risk.
contract Proxy {

    address delegate;
    address owner = msg.sender;

    function upgradeDelegate(address newDelegateAddress) public {
        require(msg.sender == owner);
        delegate = newDelegateAddress;
    }

    function() external payable {
        assembly {
            let _target := sload(0)
            calldatacopy(0x0, 0x0, calldatasize)
            let result := delegatecall(gas, _target, 0x0, calldatasize, 0x0, 0)
            returndatacopy(0x0, 0x0, returndatasize)
            switch result case 0 {revert(0, 0)} default {return (0, returndatasize)}
        }
    }
}

ignore the function that deals with external payable, we're not going to discuss any assembly code yet at this point

Notice there's access restriction in that code excerpt. This access restriction is created by defining address owner = msg.sender then require(msg.sender == owner). On the contrary, for the OpenSea registerProxy the market is forced to forego this logic in its implementation, instead opting for, require(proxies[msg.sender] == address(0)).

The reason why OpenSea must forego this access restriction is because the buyer is the one making this call (thus, the buyer is the 'sender' in this instance; confusing but stick with me here). The lack of access restriction is to prevent NFT listers from scamming those who buy their NFTs by yanking them back after receiving payment.

Remember the function definitions we found for OpenSea's marketplace smart contracts. Specifically, we saw that onlyOwner was not a modifier attached to the registerProxy function (since the buyer needs to be able to propose whichever smart contract they desire).

Now let's go back to one of the transactions involving an affected user from February 19th/20th (when folks were getting their NFTs taken left & right, it seemed).

Let's use this TX for reference: 0xfd3ac0804b9f8af8e0185ecc43c855867a04ed10eede2d80295174e5a7024038

Specifically, we're going to pipe that TX into 'ethtx.info' (first time ever including tihs site in a report, but I really like it; great for getting the granular details of an Ethereum transaction for reports like these). Once we pipe that address in to the search, we should wind up here: https://ethtx.info/mainnet/0xfd3ac0804b9f8af8e0185ecc43c855867a04ed10eede2d80295174e5a7024038/

More than likely your screen will show you the following at the top of the page:

Let's scroll down until reach something called the 'execution trace'.

This is what gives us information about the various updated states of the transaction as it was processed by nodes / miners on the Ethereum network (this work here is what the gas payments are for; i.e., the more work that needs to do + more congested the network gets, the more one must pay in gas to have their transaction cleared - thus, the commodity for $ETH is gwei at the end of the day).

This may seem intimidating, but we're going to tackle this one slowly (easier than you think).

Check out what we have below:

For the second state update, the 'execution trace' shows us [receiver] 0xa2c0946ad444dccf990394c5cbe019a858a945bd.0x8a10f9ce(call_data=0x000000000000000000000000c99f70bfd82fb7c8f8191fdfbfb735606b...000000) => ()

Before we pick apart what this means, let's go take a look at that smart contract listed as the [receiver] there as this was the one smart contract everyone was talking about on Twitter while the actual heist was going on.

For this, we'll refer to Etherscan: https://etherscan.io/address/0xa2c0946ad444dccf990394c5cbe019a858a945bd

As we can see above, Etherscan is already all over this address - labeling it Fake_Phishing5176. However, a more accurate name for this smart contract would be Phisher_GetAwayDriver or something to that extent

mini-rant: seriously though, there should be a more standardized method for labeling addresses & smart contracts identified as being a facilitator of some widely known hack / theft / compromise in the community

Let's see if we can view the contract code on Etherscan. First, we'll scroll down and click the 'contract' tab.

And it appears (maybe) that there's no such luck for us:

At first glance, the obvious assumption is that whomever uploaded this contract did so in this manner (no source code available) with the explicit intent of foiling "armchair investigators" like myself and (the few) others that bother to take any time examining these things.

However, this may not have been the case. If we revisit that brilliant guide breaking down 'proxy delegates', we'll see that inline assembly was likely a requisite for the attackers to pull off a successful theft of NFT assets from impacted users.

Specifically we want to note the part where it states, "When using the call in the context of a proxy, however, we are interested in the actual return value of the function call. To overcome this limitation, inline assembly (inline assembly allows for more precise control over the stack machine, with a language similar to the one used by the EVM and can be used within solidity code) has to be used. With the help of inline assembly we are able to dissect the return value of delegatecall and return the actual result of the caller."

Remember, in order for an NFT sale to execute on OpenSea's platform, there must be a matched buy & sell order. This is validated via examining whether the sender (i.e., 'buyer') of the NFT has properly signed the "call data" created by the seller's proposed sale price.

This is the Wyvern smart contract that governs that exchange process: https://github.com/ProjectWyvern/wyvern-ethereum/blob/master/contracts/exchange/ExchangeCore.sol

Critically, the code notes for this contract state, "Buy-side and sell-side orders each provide calldata (bytes) - for a sell-side order, the state transition for sale, for a buy-side order, the state transition to be bought." Also, "Along with the calldata, orders provide replacementPattern: a bytemask indicating which bytes of the calldata can be changed (e.g. NFT destination address)."

That's curious. To digress for a moment, is it possible that users were 'phished' legitimately purchasing NFTs on OpenSea's platform? Before you answer, hold that thought. There's more.

"When a buy-side and sell-side order are matched, the desired calldatas are unified, masked with the bytemasks, and checked for agreement. This alone is enough to implement common simple state transitions, such as 'transfer my CryptoKitty to any address' or 'buy any of this kind of nonfungible token'."

This is what the atomicMatch_ function we see called on the Wyvern smart contract is emitted for.

The answer as to how users may have been compromised may lie in a potential instance of proxy collisions as well as the non-upgraded Wyvern contract's acceptance of isValidSignature before upgrade vs. after.

To get a better idea of what's being referred to here, check out the following update to the Wyvern Protocol smart contract orchestration (pushed Jan 31st, 2022; just a couple of weeks before the changes were merged upstream with OpenSea).

Check them out here: https://github.com/wyvernprotocol/wyvern-v3/commit/403f866940b4ef304d24c2147bd9503e89e1cec7

Specifically under ExchangeCore.sol, we can see that the bytes4 constant internal EIP_1271_MAGICVALUE was changed from 0x20c13b0b to 0x1626ba7e.

Specifically, the code used to read:

contract ExchangeCore is ReentrancyGuarded, StaticCaller, EIP712 {

    bytes4 constant internal EIP_1271_MAGICVALUE = 0x20c13b0b;

Now it reads:

contract ExchangeCore is ReentrancyGuarded, StaticCaller, EIP712 {

    bytes4 constant internal EIP_1271_MAGICVALUE = 0x1626ba7e;

For those that do not know, smart contracts do not come with associated private keys. The only type of addresses on Ethereum that come with private keys are EOAs (externally owned accounts). EOAs = regular Joe Blow Ethereum addresses (i.e., no smart contract logic or anything fancy; regular ETH address you generate when you create a new account w Metamask or some other wallet provider).

So instead there must be another means of validating a signature if its passed from a smart contract. For OpenSea / Wyvern Protocol, that method was governed by ERC1271.

If you're not familiar with that smart contract standard, look no further than here: https://eips.ethereum.org/EIPS/eip-1271

For those curious enough to follow the link above, you may have noticed that the suggested magic number for EIP-1271 under the specification = 0x1626ba7e (dating back to solidity 0.5.0; this was written in 2018).

Specifically the sample code given under this EIP is:

pragma solidity ^0.5.0;

contract ERC1271 {

  // bytes4(keccak256("isValidSignature(bytes32,bytes)")
  bytes4 constant internal MAGICVALUE = 0x1626ba7e;

  /**
   * @dev Should return whether the signature provided is valid for the provided hash
   * @param _hash      Hash of the data to be signed
   * @param _signature Signature byte array associated with _hash
   *
   * MUST return the bytes4 magic value 0x1626ba7e when function passes.
   * MUST NOT modify state (using STATICCALL for solc < 0.5, view modifier for solc > 0.5)
   * MUST allow external calls
   */ 
  function isValidSignature(
    bytes32 _hash, 
    bytes memory _signature)
    public
    view 
    returns (bytes4 magicValue);
}

The reason for the variation in the bytes4 magicValue in the Wyvern Protocol (older contract) and the one specified in EIP1271 are the structs that are included under each.

Judging from the commits to the Wyvern Protcol smart contracts on GitHub, it appears that the biggest change was made with regards to smart contract authentication for validating access restrictions related to calls made on the main smart contract.

We can see this under the contracts/exchange/ExchangeCore.sol contract underneath the main repo for WyvernProtocol: https://github.com/wyvernprotocol/wyvern-v3/commit/403f866940b4ef304d24c2147bd9503e89e1cec7

The contract used to read:

contract ExchangeCore is ReentrancyGuard, StaticCaller, EIP712 {
    bytes4 constant internal EIP_1271_MAGICVALUE = 0x20c13b0b;
    bytes internal personalSignPrefix = "\x19Ethereum Signed Message:\n";
// skipping about 150 lines to line 185 
        if (isContract) {
            if (ERC1271(maker).isValidSignature(abi.encodePacked(calculatedHashToSign), signature) == EIP_1271_MAGICVALUE) {
                return true; 
            }
            return false; 
        }
        (uint8 v, bytes32 r, bytes32 s) = abi.decode(signature, (uint8, bytes32, bytes32));
        if (signature.length > 65 && signature[signature.length-1] == 0x03) {
            if (ecrecover(keccak256(abi.encodePacked(personalSignPrefix,"32",calculatedHashToSign)), v, r, s) == maker) {
                return true; 
            }
        }
    }
// last bracket added for cohesiveness 
}

The two lines that were deleted in the code were:

(a) if (ERC1271(maker).isValidSignature(abi.encodePacked(calculatedHashToSign), signature) == EIP_1271_MAGICVALUE) {

(b) bytes4 constant internal EIP_1271_MAGICVALUE = 0x20c13b0b;

They were replaced with

(aa) bytes4 constant internal EIP_1271_MAGICVALUE = 0x1626ba7e;

(bb) if (ERC1271(maker).isValidSignature(calculatedHashToSign, signature) == EIP_1271_MAGICVALUE) {

The swap from abi.encodePacked(calculatedHashtoSign) to calculatedHashtoSign was a critical change in the authentication mechanism for smart contracts attempting to make cals calls on the exchange.sol contract deployed by Wyvern Protocol.

Keccak Caching

All contracts deployed before solidity version 0.8.3 were impacted by a bug called KeccakCaching; according to Etherscan, "The bytecode optimizer incorrectly re-used previously evaluated Keccak-256 hashes. You are unlikely to be affected if you do not compute Keccak-256 hashes in inline assembly."

Coincidentally, that's exactly what the malicious smart contract (labeled phishing_contract5961 on Etherscan), did. The source code was not published on Etherscan, but there are plenty of tools in the wild that allow us to decompile the smart contract's ABI (decoding) as well as the involved transactions to get a general feel for how this compromise was executed.

This bug was not discovered / published about publicly until March 20th 2021 (approx.) on the 'SolidityLang' blog.

That post can be viewed here: https://blog.soliditylang.org/2021/03/23/keccak-optimizer-bug/

Below is the basic gist of how this bug works:

"Solidity’s bytecode optimizer has a step that can compute Keccak-256 hashes, if the contents of the memory, over which the Keccak-256 built-in function is invoked, are known during compilation time."
"This step also has a mechanism to determine that two Keccak-256 hashes are equal even if the values in memory are not known during compile time"
"This step had a bug where Keccak-256 hashes of the same memory content, but of different sizes were considered equal."

To synthesize those details, this bug essentially allowed for asserting that a keccak256 hash of some data (i.e., keccak256(0, 32) or let's say.... keccak256(add(array, 0x20), size)) [hint: that latter function is located at line 656 of Wyvern's Exchange smart contract (earlier version; deprecated now), and is also explicitly calculated via in-line assembly, making the contract ripe for those looking to compromise users via OpenSea's market at the time this was the deployed standard]

Making an Educated Guess (Hypothesis)

At this point, what I believe happened is that users that bought certain NFTs (i.e., Bored Ape Yacht Club NFTs), signed calldata well in

We'll soon find out that the phishing attack was more than likely executed via the NFTs themselves, but not in the simplistic way originally visioned by 'Checkpoint Research' (all credit to those researchers for exposing various site vulnerabilities that would pull in malicious html code appearing to originate from the same site).

This attack vector identified by 'Checkpoint Research' is still potent, to be clear. But it is only just one among a gamut of compromise techniques being leveraged against the NFT ecosystem (appears that there is a potent threat actor that's been wreaking havoc on the protocol).

This is still unfinished, so there's no conclusion in here yet and this research doesn't get to the crux of how the compromise of user NFTs was executed back in February 2022; with that said, don't extrapolate anything from what's written above yet. This is just here as a placeholder

Do Not Purchase CoinKite Hardware Products (Part 1)

librehash — Thu, 04 Nov 2021 03:42:58 +0000

originally published on the Librehash blog (flagship) here - https://librehash.org/do-not-purchase-coinkite-hardware-products-part-1/

Their products are vaporware from top to bottom and their premise makes absolutely zero fucking sense (tantamount to pure security theater at times).

Starting With 'OpenDime'

There are numerous different product offerings under the 'CoinKite' flagship, so we're going to one by one here in our series, starting with 'OpenDime'.

Their main site = https://opendime.com

Upon visiting the site, visitors are presented with a huge, ugly orange "Buy Now" button which one would presumably click if they wished to order the "OpenDime 4.0" USB device (at the time of writing).

But let's hold our horses a sec. We need to dig into what this protocol is really about before we make any affirmative decisions.

Quick Note/Observation: Whenever 'open' prefixes any product in the tech space, the implication is that the product being provided is "open" as in "open source". Unfortunately, that's far from the case here (seems they just labeled it 'open' for the sake of instilling that association in customers)

"The Bitcoin Credit Stick"

Confused on what that means? You aren't the only one.

On the site, underneath those words, there are various phrases, written in bold, that unravel themselves in succession that describe the alleged characteristics of this device.

If you don't have the time to sit through all of the animations (you probably don't), no problem - that's what Librehash is for.

Below is a complete list of all of the unraveled phrases on the site underneath 'The Bitcoin Credit Stick' title (which, itself, is located in the panel beneath the top one, which contains the ugly 'buy now' button we were mentioning prior.

Next to each one of these phrases, there will be some comment provided.

"Internal Private Key" = Not sure what's meant by this. Assumption here is that the device stores the private key...internally (where else would it be stored?); guess this is good reassurance though for those that were questioning this..
"USB Flash Drive" = Not the words you want to read. Yes, it may look like a USB device at the end of the day, but it should not literally be a garden-variety USB device. You want to use a device that has some sort of secure, well-developed cryptographic module attached to the chip responsible for the light device's operation. There are some open source options available out there for this (we've already covered a couple of those in the @librechain channel already); it appears that these guys never consulted those sources though
"Verify Offline" = Its impossible to "verify offline", if we're talking about transactions. Crafting a transaction is a stateless process, which means it can be done entirely offline without running a full node or polling any information from any full node. Thus, the process is independent and mutually exclusive of the functionality of the underpinning blockchain network. This is why new transactions submitted to the chain or the wallet balances of other peers / users that one interacts with claiming to have $BTC must have their balances validated on the internet...
"Off-chain & 100% Private" = Bitcoin is not private, therefore this solution isn't either. Period. Also, all transactions confirmed on the Bitcoin blockchain are "on-chain", full stop. So, not sure what is meant or implied with the "off-chain" promo
"First Bitcoin Bearer Instrument" = Have no clue what the fuck this means; looking deeper into this site, next to this same title (Bitcoin Bearer Instrument), is the following excerpt: "Opendime is a small USB stick that allows you to spend Bitcoin like a dollar bill. Pass it along multiple times. Connect to any USB to check balance. Unseal anytime to spend online. Trust no one." [so many problems here; (a) what is meant by, 'allows you to spend BItcoin like a dollar bill'? (b) "Pass it along multiple times"? so much for '100% privacy', right? ( c ) "connect to any USB to check balance" so much for 'Verify Offline', right? "Unseal anytime to spend online" (unseal what?) (d) "Trust no one" [Bitcoin is already trustless by design, so how could any Bitcoin-based product claim to provide such a benefit as if its not already being enjoyed by users of the protocol?]
"Pass it Along Multiple Times" = At first glance, no clue what's meant here by this phrase; pass 'what' along?
"Trust No One!" = Repeat after me, "Bitcoin is trustless"; 'decentralization' + the concept of architecting the protocol so that the nodes would (or were supposed to be) distributed was a means to an end (that 'end' = trustlessness)

You've been lied to and told that 'decentralization' is the innovation of BItcoin. This could not be further from the truth. The internet itself, architecturally and by design, is decentralized.

Evaluating OpenDime's Features

On the same site where we found all of these bold claims about this USB stick are a host of purported features afforded to users that elect to waaste their money on this crap (if you visited the site, you just need to scroll down a bit to run into said features).

Specifically, the features (as listed above), are:

A) USB Drive - "Acts like a read-only USB flash drive. Works with any computer, laptop, or phone. A QR Image and Text files inside contain Bitcoin address and helpful information."

B) Ultra Secure - "The private key is generated inside the device, and is never known to any human, not even you!"

C) No Trust - "Given an OpenDime to anyone and they don't need to worry that you can take back the funds later. The private key is strictly in the device itself."

D) Free to Use - "This is physical Bitcoin as it was meant to be: just hand it to someone and they've got it! Pass it on multiple times! As simple as a handshake. No miner fees, no confirmation delays."

E) Open Standards - "Uses Bitcoin message signing, normal (non HD) bitcoin payment addresses and payment keys in WIF format."

F) Compatibility - "The Bitcoin world changes fast but OpenDime is built on the fundamental Bitcoin features that haven't changed in five years."

Premature Assessment of These 'Features' = Fucking Terrible

There are a ton of fucking issues with each and every single purported 'feature' of this project from: (a) the listing of some of these items as 'features' or 'benefits' at all (b) Multiple contradictions in the description of these benefits, from one to another (c) Inaccurate statements (d) Exaggerated / untrue claims made (e) Pseudo-features; i.e., for virtually all of the alleged benefits provided for the end user, none of the "issues" supposedly addressed by these features are legitimate issues / threat vectors for Bitcoin users at all

However, rather than nitpick from a distance, we're going to go through each one of these alleged features with a fine-toothed comb and pick them apart in one of the subsequent articles for this series.

For now though, we're going to focus on some of the major deficits in the 'OpenDime' product offering.

Carving Open 'OpenDime'

"Zooming out" for a second, its critical for users to adjudicate any hardware-based "Bitcoin wallet" product they purchase / are offered through the scope of that product's efficacy in handling any & all sensitive cryptographic data.

Bitcoin / cryptocurrencies aren't the only thing in life that are underpinned by cryptographic keys or sensitive cryptographic material that must be highly secured & protected.

HSMs are Effectively the World's Best Hardware Wallets

HSM stands for, 'Hardware Security Module'. In a nutshell, "The hardware security module (HSM) is a special 'trusted' network computer performing a variety of cryptographic operations: key management, key exchange, encryption, etc." (source - https://www.cryptomathic.com/news-events/blog/understanding-hardware-security-modules-hsms).

Also, see this description for an 'HSM' provided by Thales (to parity the sources used for this critical task of defining these devices):

https://cpl.thalesgroup.com/encryption/hardware-security-modules

Effectively, it does everything that Bitcoin hardware wallets market themselves as providing ; the only difference is that these solutions are **exponentially more secure than what you see out of your 'garden variety' Bitcoin hardware wallets.

As we'll see in the next section, there are a number 'boxes' that must be "checked" before we can declare an HSM device (effectively what these products are), to be secure in any capacity.

Properties of a Secure HSM Device

One of the best guides for this you'll find anywhere online is located here - https://wiki.opendnssec.org/display/DOCREF/HSM+Buyers%27+Guide

We're going to briefly summarize some of the finer points included in this document below (as a mini-criteria for what someone should want out of their HSM device)

There are four tiers of 'HSM' devices that one can obtain (based on scale of operation, required usage, and features / properties of the HSM device in question necessary for whatever its being purchased for)

Any HSM worth its salt should be compatible with PKCS #11

The HSM device in question should be audited (by a legitimate security firm qualified to conduct such audits); this audit, in specific, is different from what we have come to expect in the crypto space in relation to "smart contract audits". Instead of being commissioned for the purpose of finding any bugs/glitches/exploits/etc., audits of mission-critical hardware/software like this is usually commissioned and subsequently published publicly for the purposes of providing assurance to the general public via a trusted, reputable 3rd-party source that the construction of the device reflects the type of development / cryptographic acumen a device of this nature must possess.
Device should be compliant with National & International security standards established by the world's foremost Standards Organizations (i.e., 'NIST', 'FIPS', 'ISO/IEC', etc.)
This list is far from comprehensive, but if you're wondering what the most popular compliance standards are that companies seek to align with that are providing a product like this (HSM): GDPR, eIDAS, FIPS 140-2 (level 3) , Common Criteria, HIPAA, PCI-DSS, NITES, ANSI X9.24, ISO 13491, ISO 27799, ISO 27002, FedRAMP, GLBA, HIPAA, PIPA, PDPA, UIDAI, PSD2 (among others that aren't listed but compliance with the standard could still be considered desirable, contingent on the use case of the device & the corresponding context of the situation)
To be clear this 'compliance' label is usually cleared by the standards organization before the manufacturer makes this claim (simply asserting that one's device conforms to these standards without going through this process would do significantly more harm than good in the eyes of the prospective end-user / consumer if that were to ever be discovered & exposed)

Below is a screenshot of a real certificate (given to Thales by the NIST), certifying that their HSM was FIPS 140 complaint (Level 2).

https://csrc.nist.gov/Projects/Cryptographic-Module-Validation-Program/Certificate/3205

Picture of the actual 'Certificate' provided by the U.S. government for the product deemed to meet the threshold requirements of an FIPS-certified device.

https://csrc.nist.gov/CSRC/media/projects/cryptographic-module-validation-program/documents/certificates/JuneCertFinal.pdf (ignore the quality here; this is the best that the gov't provided on its site of this certificate for whatever reason)

The certificate shown in the screenshot above is simply the first page of a pdf document (linked directly from the NIST website). This next screenshot (from 'page 2' of that same pdf), provides a more granular outlook of the different facets of the HSM that needed to be adjudciated for certification (shown to give readers an idea of how meticulous this process is).

Can HSMs be Used for Blockchain?

In Two Words?: Hell yes.

In fact, there are a number of HSM manufacturers out there that have went out of their way to publish documentation on their products' respective site(s), outlining how their device can be purposed for securing one's blockchain addresses / funds.

Example One: 'Ultimaco'

https://hsm.utimaco.com/blog/why-hsm-is-vital-to-the-blockchain-technologies/

More relevant information can be found here - https://hsm.utimaco.com/blog/the-key-role-of-hsms-and-key-management-in-secure-permissioned-blockchains-for-banking-and-payment-services-an-overview/

Example Two - Thales Group HSMs

Thales published an entire whitepaper covering how their HSM devices could be used to provide elite protection for those looking to store $ETH / $BTC keys.

The prelude to the whitepaper (on their site), states: "Secure cold storage of cryptocurrencies such as Bitcoin or Ethereum, is a difficult and complex challenge. Traditional paper wallet-based solutions may be effective for the most basic use cases, but they present a substantial challenge for more complex environments as they do not scale, or address compliance requirements for strong key management."

That whitepaper can be found here - https://cpl.thalesgroup.com/sites/default/files/content/solution_briefs/field_document/2020-03/Securing_Blockchain_Ledger_ProtectServer_HSM_SB_v8.pdf

https://cpl.thalesgroup.com/resources/encryption/blockchain-protectserver-hsm-solution-brief

Below is an excerpt from that whitepaper (pdf document):

Open Source HSM Solutions (for cheap)

The best commercially available HSM solution out there, hands down (for those that don't want to get into tinkering with chips & hardware), is the 'Nitrokey 3'.

You can read about the features that come with this key here - https://www.nitrokey.com/news/2021/new-nitrokey-3-nfc-usb-c-rust-common-criteria-eal-6

these are some pretty significant features, right?

^^ That summary doesn't provide a comprehensive list of the benefits afforded by one of these devices.

Those benefits are presented below (screen'd from the site):

That's not all though, Nitrokey also provides a breakdown of the security technology embedded in these devices (and each component's respective role in the greater design of this mini-HSM product).

Fortunately for NitroKey users, the project is entirely open source (both the firmware and hard ware provided; 'OpenDime' only open sourced their firmware, which does little to provide us with the assurance one would desire when entrusting a device to effectively secure all of your hard-earned crypto funds).

The above referenced 'Security Technology' is outlined in the screenshots published below form the site, for convenience:

Wait, there's more

If you visit the product page of NitroKey's site, you'll find a list of some of the general security assurances their devices afford users across the board (regardless of what is purchased).

Let's Revisit the 'OpenDime' Features Again

from the main site: https://opendime.com/ (non-descript, vague "features" that are effectively unable to be verified beyond the statements on the website itself)

Hard to argue that this device provides a compelling and/or competitive use case in light of what we just learned in this article. But - who knows? Maybe this product makes up for it in its pricing (comparatively).

Fortunately, we don't have to speculate on this as the companies responsible for bringing each respective product to market have the price point for these items published online at the time of writing.

Price of 'OpenDime' / ColdCard Device

https://store.coinkite.com/store/opendime

As we can see in the screenshot above, the price of an 'OpenDime' disposable USB device (3-pack) at the time of writing is approximately, $49-59.

Let's see how much the NitroKeys are going for.

Price of NitroKey 3 HSM

https://shop.nitrokey.com/shop/product/nk3cn-nitrokey-3c-nfc-148

Per the screenshot above, it appears that this key is going for 49 euros, which equates to ~$56 at the time of writing.

Conclusion

There is none, this is only part one. We have a hell of a lot more to discuss here.

Brief ETH Wallet Security Guide

librehash — Sun, 17 Oct 2021 16:05:33 +0000

I would recommend taking a look at some of the following links (if you're interested); wouldn't bash Metamask for no reason, but there are just certain facets of their wallet app that make it wholly insecure (in my opinion & in that of most security researchers 'in the wild', I would imagine):

There are many more reasons that can be listed, but I won't get into those here.

Let's just move forward toward ensuring that we can generate a secure Ethereum address.

Securing a Metamask Wallet

Despite all of the drawbacks and negatives listed above, there is a way to ensure that your Metamask wallet is a secure construction.

The first step to doing so would be downloading Ian Coleman's BIP39 site, located here: https://iancoleman.io/bip39/

Upon visiting the site, you should see something like the following:

In order to download this tool (safely) for use offline, we're going to visit the official GitHub repo for this page.

Specifically, we're going to visit: https://github.com/iancoleman/bip39

From there, we're going to check out the latest releases (https://github.com/iancoleman/bip39/releases/tag/0.5.3).

Ian Coleman Values Our Security

If we checkout the releases, we'll notice that there's an attached PGP signed message accompanying each release (SHA-512) published by Ian Coleman.

The PGP message specifically clear signs the sha256 checksum of the bip39-standalone.html page that gets produced after we download & unzip the relevant files.

We have the option of either downloading the standalone html file or the entire source code for the file (either or works; we're going to go with the source in this instance though).

Unpacking the Source and Running the Code

This can all be done in a couple simple commands.

If you're a terminal person, these next steps are for you:

curl -tlsv1.3  https://github.com/iancoleman/bip39/archive/refs/tags/0.5.3.tar.gz

Assuming that this doesn't work for whatever reason, that simply means that the latest version of 'curl' likely needs to be installed on one's computer (there's going to be a little bit of footwork mandated with this portion of things if you're truly interested, but its all encapsulated within one concise script for those that need it).

Installing Curl

this step is only for people that want to ensure that they have an insane level of security in their default setups; never a bad idea to do this though and ensure that you have the latest versions of all of the best libraries that are needed to build the requisite tools needed to stay on the cutting edge of security

The below script can be saved to a file (with any name) on the terminal, then subsequently activated via chmod +x (filename).(ending) in order to ensure that it can be ran at some point in the future.

sudo apt -y update 
sudo apt-get -y upgrade # hopefully there are no funky problems on the machine that you're using ; could loop this through a command that first checks out the OS that someone is running first, then uses the appropriate packet manager based on the grepped & saved response (to a fd of some sort in the intermediate; random one preferably I suppose) 
# assuming ubuntu / debian for the rest of the commands here 
sudo apt -y install astyle cmake gcc ninja-build libssl-dev python3-pytest python3-pytest-xdist unzip xsltproc doxygen graphviz build-essential 
wget https://curl.se/download/curl-7.77.0.tar.gz
tar -xvf curl-*.tar.gz
cd curl-*
./configure --with-openssl --with-libssh2 --with-zlib --with-brotli --with-zstd --with-gssapi --with-gsasl --enable-tls-srp --enable-threateded-resolver --enable-ipv6 --enable-unix-sockets --enable-manual --enable-sspi --enable-ldaps --enable-rtsp --enable-librtmp --with-libmetalink --with-libpsl --with-nghttp2 --disable-telnet --enable-libcurl-option --with-libmetalink --with-ngtcp2 --with-quiche --enable-mime --enable-netrc --enable-get-easy-options --enable-dnsshuffle --enable-hsts --enable-sspi
sudo make 
sudo make test # sudo make check 
sudo make install

After this, we need to look for where the 'curl' binary is at (more than likely, we didn't replace the previous longstanding curl binary with this command ; not a problem though)

We'll just have to run the following script:

#!/bin/sh 

mkdir -p ~/Downloads/backups/
sudo cp ~/.bashrc ~/Downloads/backups/.bashrcbackup
cat <<EOF >>~/.bashrc
curl() {
    location/of/newlydownloaded/curl "$@"
}
EOF
# at this point the little curl command path we included above should be the path that's consulted first 
exec bash # this should renew the bash terminal 
which -a curl # this should tell us which curl will be used ultimately but if not then we can use the next cmd 
echo $curl # the result of this command should mimic what we just appended ~/.bashrc with 
# could add extra code that saves the output of either command above to assess whether they match what should be expected from a string we extract from the ~/.bashrc that gets grepped out but...too lazy, do it yourself if you are a reader

When this script is done executing, one just needs to type 'type curl' and the result should be

curl is a function 
curl() {
    /path/to/new/curlsrc "$@"
}

If this is the case, then you're good to go. Now all you have to do is run the necessary code to extract the ian coleman repo from its place on GitHub.

That would be (make sure to double check the URLs on your end):

#!/bin/sh 

mkdir -p ~/tmpdownload
cd ~/tmpdownload
curl -L -tlsv1.3 https://github.com/iancoleman/bip39/archive/refs/tags/0.5.3.tar.gz > iancole.tar.gz
tar -xvf *.tar.gz
cd bip39-*
# from here we're going to open up the webpage using firefox (assuming everyone has that downloaded)
firefox --new-instance --browser --private-window $(pwd)/src/index.html

All of the scripts above could be included in one bigger script, or there could just be a larger script created that calls each of these (or we can just create each one of the scripts above in one greater script). Doesn't really matter which choice we opt with.

Addressing any and All Concerns Associated with the Browser Use of the Script

The command that I used to open the 'index.html' in firefox:

firefox --new-instance --browser --private-window $(pwd)/src/index.html

This command:

a) calls firefox

b) ensures that a new instance is instantiated

c) ensures that the browser is called (vs. the headless version)

d) private window ensures that no cookies / history is saved at all

e) $(pwd)/src/index.html = location of the file we want to open up in the browser ; we want to make sure to only run this command from the root directory, otherwise we need to specify the explicit path that must be followed to enable these commands.

Dockerizing the Application

For those that may be even more paranoid than the most paranoid (assuming they are the ones that would have followed the above precautions), it would be recommended to dockerize or otherwise sandbox the application itself to ensure some level of isolation from the root / bare-metal / OS layer.

Regardless, there's a full guide that breaks this down for anybody that's curious as well (that will be included separately).

Assuming Everything Went Right and the Page is Offline

This is when we'll go ahead and generate a new 24-word mnemonic from the app itself.

We can do this one of two ways - we can either generate it using a random mnemonic (which it pulls from secure sources) or we can generate it from a hexadecimal source.

If you're not sure what either of those things means, then follow us on a brief journey below as we craft our own secure Ethereum wallet, starting with the Ian Coleman webpage that we downloaded initially.

Setting the Stage: Step One

Once you visit the Ian Coleman page, you should be greeted with a screen that looks like this one:

Once there, you're going to click on the dropdown menu where the number '15' is located and select '24' instead.

Once that's selected, we will then press the button that says, 'Generate'.

As you may have expected, 24 words will be generated (at random*) in the box below.

Check out the 24 words that were given to us:

report concert educate dirt door sorry season inject manual mixture logic item text indicate square wrap strike welcome permit frost sweet twelve round warrior

If we scroll a bit further, we can see that we're presented with other information, such as our wallet seed and our BIP32 root key.

If you notice, there's also a section where one can select the specific coin that they wish to use. This was left on 'Bitcoin' on purpose to allow this section to be a reminder that we need to adjust the coin to Ethereum if we're going to be producing a wallet for Metamask.

if you're curious why this is, the reason is that Ethereum uses a different hash operation in the creation of its addresses than Bitcoin does (pre-finalized version of the Keccak hash algorithm); Certain apps and blockchains use an entirely different word list than the BIP39 prevailing defalt 2048 word, word-list.

What was just demonstrated above was the "easy" way to create an Etheruem address.

This method is still secure, for the most part, but it does put the formation of your address up to some level of "chance" (i.e., contingent on the quality of the source of randomness used).

Quality of the Randomness Source

This si something that is critically important for anyone that's looking to generate a secure wallet (that won't be compromised at any point in the foreseeable future).

If you're thinking to yourself, 'What are the chances that someone could possibly guess my private key?', the answer is "Significant" if your source of randomness is not sufficiently random (i.e., someone is able to deduce the range / realm of results that the random number generator you're using tends to produce).

Prior Incidents

Back in 2013, there were a slew of Bitcoin users that ended up losing their funds. The one commonality among all of the thefts was the app that produced the compromised wallet addresses at the time.

Cybersecurity firm, 'Sophos' covered the incident at the time.

https://nakedsecurity.sophos.com/2013/08/12/android-random-number-flaw-implicated-in-bitcoin-thefts/

What's curious about this situation is that the wallets were not inherently compromised by the way that the formed, but rather by the signatures.

Since this is outside of the scope of what we're doing (since we're only creating a secure address vs. using it in a secure manner), this guide is going to go ahead and omit details about using it in a secure manner.

Mina Protocol Debunked

librehash — Sun, 17 Oct 2021 14:51:20 +0000

Since it appears that this project is garnering a ton of attention on social media recently (on TikTok, specifically), it felt incumbent upon Librehash to ensure that due diligence is performed on this once-in-a-lifetime opportunity to obtain a cryptocurrency of epic proportions.

Despite the hype around this project on TikTok, there isn't too much information out about it (outside of its official channels), so that's where we'll start for good measure.

Visiting the Mina Protocol Website

The official Mina Protocol website can be found here: https://minaprotocol.com

Per their site, Mina Protocol states that they are, "The world's lightest blockchain, powered by participants" (aren't all blockchains de facto powered by participants as part of the 'peer-to-peer' characteristic that they're all supposed to feature?).

The website goes on to state that:

"Mina is building a privacy-preserving gateway between the real world and crypto - and the infrastructure for the secure, democratic future we all deserve."

The website goes on to boast the blockchain's tiny size (comparative to that of other blockchains that are currently in existence), in another statement on the site proclaiming, "By design, the entire Mina blockchain is about 22kb - the size of a couple of tweets. So participants can quickly sync and verify the network."

Deconstructing the Claim Mina Protocol is Making About Size

When it comes to blockchain, size is largely an inevitability since the blockchain itself is supposed to serve as a ledger for any and all transactions that have been mined in a block from its Genesis (first block) to the present time of examination.

However, even with this in mind, this still doesn't explain to us why blockchains are so large in size.

Below are the total blockchains sizes of a few popular Proof of Work-based projects: 340.21 GB

Bitcoin - 340.21 GB
Litecoin - 44.81 GB
Ethereum - 6.9 TB
Bitcoin Cash - 192.38 GB

You get the picture at this point.

Prime Contributors to the Block Size

It may be known that the sheer volume of transactions on these chains contributes to their overall block size, but that doesn't tell us what the prime contributor is.

Fortunately, that answer is easy to source.

Cryptography Signatures and Public Keys

Let's take a second and evaluate exactly how a Bitcoin wallet is constructed (on a technical level).

First step is to generate a random seed (usually from entropy; "randomness")
We're going to pipe that random seed into the ecdsa (secp256k1) formula to generate a private key for ourselves. Assuming that we're iterating Bitcoin keys in their 'compressed' form, the key that's generated must be 32 bytes

Above is a screenshot from the 'Bitcoin Forgein' tool, located here: https://improvein.github.io/bitcoin-forge/#/cryptography/keys

As we all know, the private key does not get stored on the protocol but rather a representation of the public key.

To be specific:

The public key is generated from the private key (by calculating the corresponding 'y' coordinate point for the 'x' [private key; generated from the 'G' generator point multiplied by the 'r' random value [derived from entropy] to [hopefully] manifest a "random" point on the curve)
The public key is a signed integer (i.e., you must decide whether its negative or positive). If you opt to make the public key positive, then you need to prefix it with '02', otherwise '03' must be prefixed to symbolize a negative value for the public key.
Iterate the SHA256 operation over the public key
Compress the public key down to 20 bytes by performing a ripemd160 operation on the SHA256 output
Prepend a version byte to signify the network the key is being generated for (i.e., '0x00' for the Bitcoin mainnet)
You then SHA256 hash the ripemd160 output (with the 0x00 byte prepended to it)
SHA256 the output of number six.
Take the first four bytes of the output of number seven (that's the first 8 characters in hexadecimal); write down these bytes on a piece of paper or take a mental note of them
Remember the original 20-byte output we generated from stage '4'? We're going to append those '4' bytes to the end of that output (keep the 0x00 prepended to the front of the ripemd160 result)
Serialize the address using base58check encoding (this is a special construction created just for Bitcoin

Other Facets of a Transcation

Let's take a quick look at your 'typical' run of the mill transaction to refresh ourselves:

source: https://bitaps.com/831d8df2136ef7ede3e20c366bfa1ce5c45d67afef664b4cbb1cbf5736c1b90d

In the screenshot above, the following can be observed:

There's one input transaction (sender)
There are six output transactions

Fortunately, Bitaps provides us with greater transaction details (i.e., the scripts involved), which allow us to count the total size taken up by just the addresses alone:

For the input, we can see that a total of 136 bytes alone
The output addresses, combined, account for 120 bytes

Altogether the addresses in this transaction account for 256 bytes.

However, this does not represent the totality of the transaction itself - we still need to identify how much size is taken by the signature in this transaction (mandatory for the transaction to go through; we know this because there is a 'op_equalverify', 'op_checksig' opcode directive at the end of 4 of those addresses.

Below is an illustration of the 'Script' smart contracting language for Bitcoin for transactions such as these:

As we can see, transactions like only resolve when the mandate for a signature that corresponds with the identified public key has been met.

Since BIP64, all Bitcoin cryptographic-related material is supposed to be encoded in 'DER' format.

source: https://en.bitcoin.it/wiki/BIP_0062

Therefore, the size of a transaction for a Bitcoin transaction must be 64 bytes (anything lower than that is a malformed signature):

Therefore, the average transaction for Bitcoin will come to a size of about 150-250 bytes (for a first-time send with no more than one input and one output [no change address]).

Evaluating the Preposterous Nature of Mina Protocol's Claim

In light of what was explained above, we should be incredulous of Mina Protocol's claim that they've figured out how to compress the size of their network's blockchain to no more than 2.2Kb total.

This total represents 14.5 of the smallest Bitcoin transactions (one input & one output). If we're looking at the gamut of transactions that have passed through the Bitcoin protocol, there are singular transactions that have exceeded this limit.

Compression World Records

To date, the world record for compression condenses information from sample Wikipedia pages (to serve as an ample writing sample to test the prowess of the compression algorithm submissions' effectiveness against bricks of real, legitimate English text).

Fabrice Bellard (world-renowned computer scientist), was only able to compress the sample down to roughly 10% of its total size.

source: https://bellard.org/nncp/readme-gpt2tc.txt

Taking all of this into consideration, we should be sufficiently excited to read into how the Mina Protocol has managed to expand former theoretical constraints for what was considered possible in the field of computing.

Recursive Snarks?

Upon clicking the link located on the Mina Protocol frontpage (titled, 'See the Tech'), we're taken to the following page: https://minaprotocol.com/tech

It is on this page where the 'secret' to the Mina Protocol's extraordinary compression ratio secrets are revealed:

In the photo above, the Mina Protocol team states:

"Rather than apply brute computing force, Mina users advanced cryptography and recursive zk-SNARKs to deliver true decentralization at scale."

Gaining a Better Understanding of Why Mina Protocol Believes Their Blockchain Can Be 2.2Kb

The misconception here is a bit comical (and very much akin to the one that Coda Protocol had a few years ago).

Evaluating Similar Claims by the Coda Protocol

For those that remember, the Coda Protocol similarly claimed that they were able to compress the size of the blockchain to just a few kb due to their use of Snarks.

Specifically, in their whitepaper (Abstract) Coda stated:

"We introduce the notion of a succinct blockchaikn, a replicated machine in which each state transition (block) can be efficiently verified in constant time regardless of the number of prior transactions in the system."

"Traditional blockchains require verification time linear in the number of transitions. We show how to construct a succinct blockchain using recursively composed succinct non-interactive arguments of knowledge (SNARKs)."

source: https://eprint.iacr.org/2020/352.pdf

Coda IS Mina Protocol

Turns out that, that faintly reminiscent feeling that struck us as we were reviewing the construction of the Mina Protocol wasn't just a feeling.

Public reporting from various 3rd-party sources reflect that, at some point during 2020, Coda decided to rebrand itself as the Mina Protocol.

source: https://medium.com/minaprotocol/coda-protocol-relaunches-as-mina-the-worlds-lightest-blockchain-269636e4b044

Sticking with that same press release (linked above), we can see that the Mina Protocol claims that, "Unlike first generation blockchains, such as Bitcoin or Ethereum, with heavy chains, Mina uses a chain that is, and always will be, 22 kb so participants can sync the entire chain in seconds.

Understanding Zero Knowledge Protocols

In the example that we gave for Bitcoin above, we constructed something that's similar to a "zero knowledge protocol".

In effect, by only mandating a signature that corresponds with a user's submitted public key (to spend a transaction), the blockchain is accepting the 'zero knowledge proof' that the holder of said public key & signature must also be in possession of the corresponding private key.

This is because the 'proof' generated by the secp256k1 elliptic curve construction allow for the key holder to construct their own proof that, when solved, provides mathematical reassdurance that said proof could have only been proven (i.e., signature provided) by virtue of owning or having access to the corresponding private key (satisfying the imposed transaction conditions to spend whatever unspent transactions are in limbo at this stage of the transaction process).

Deconstructing zk-SNARKs

zk-SNARKs stand for "Succinct Non-Interactive Argument of Argument" (in other words, a 'zero-knowledge proof').

However, rather than appealing to the inherent zero knowledge proof inherent in Bitcoin's construction, ZCash (the originators of this cryptographic scheme) decided to allow the sender of transactions to construct an entirely different (supposed more established) proof.

Digging into the Protocol's Technical Specifications

The whitepaper on zk-SNARKs (published by the ZCash Foundation), provides us with the technical specifications necessary to discern what data, if any, must be kept on-hand to prove the proof was ever met itself, in the first place (otherwise the trustless construction of blockchain that's designed to prevent double-spending is undermined in this cryptographic scheme's assumptions.

Digging into the Mathematical Foundation of zk-SNARKs

Per the whitepaper:

"We always assume we are working with a field Fr for prime r chosen according to a desired security parameter. We assume together that Fr we have generated groups G1, G2, Gt, all cyclic of order r; which we write G1 and G2 in additive notation and Gt in multiplicative notation."

From the above, we can assume that the 'numbered' "G" instantiations are the different scalar multiplicative values for some public / private key that you're looking to kill me over (or with).

Proving the MPC Construction

What makes zk-SNARKs unique as a zero-knowledge proof cryptographic scheme is that it instantiates a process know as 'MPC' (multi-party computation).

Specifically, the whitepaper for zk-SNARKs states:

"The protocol is conducted by n players, a coordinator, and a protocol verifier."

"In the implementation the role of the coordinator and protocol verifier can be played by the same server. We find it very useful to separate these roles, though, as the actions of the protocol verifier may be executed only after the protocol has terminated, if one wishes to reduce the time the players have to be engaged...."

Most important part here:

"...Any party wishing to check the validity of the transcript and generated parameters can do so solely with access to the protocol transcript."

In total, the protocol consists of four total 'round-robin' rounds.

The rounds are delegated as follows:

Round One = Commitments
Round Two = Revealing Commitments
Round Three = "After the random-powers subprotocol and the FFT, the MPC consists of a few invocations of the random-coefficient subprotocol. These invocations add a total of two rounds to the MPC, as sometimes and random-coefficient subprotocol will need the output of a previous random-coefficient subprotocol as input.

Reconstructing the Zero Knowledge Proof

It isn't enough to simply assert that the zero knowledge protocol has been iterated with a hash record acknowledging such.

Coda, like any other blockchain, can only retain legitimacy of the derived results themselves are auditable (and ZCash is).

Curiously, this auditability has been the primary contributor to ZCash's blockchain size (see below):

source: https://bitinfocharts.com/zcash/

In the chart above, we can see that ZCash, founded by Zooko (the creator of the zk-SNARKs concept) has a total blockchain size that well exceeds (22 kB).

$ZEC is currently trading above $250 at the time of writing (and there's a Grayscale Investment Trust for it as well).

Transaction Sizes For ZCash

Per ZCash's own website, we can see the average transaction sizes for both shielded and unshielded transactions:

Shielded Transactions = 2000 bytes
Unshielded Transactions = 500 bytes

Notably, shielded transactions account for more data than unshielded ones.

Given this information, how is it that the "Mina Protocol" proposes that they'll be able to construct a blockchain that's exponentially smaller than that of ZCash's when $ZEC has an active implementation of the same zk-SNARKs construction that Mina proposes will shrink the size of its blockchain down to no more than 22kb (ever, at any given point in time).

Going by ZCash's construction, that means that the maximum # of shielded transactions that can ever be present on the Mina Protocol at any given point in time (before the data is irrevocably erased, one must assume), is 11, tops.

Conclusion

Unfortunately for the crusaders of the Mina Protocol the plausibility of what they propose is out of the question (yet, ironically, creates several more questions about the integrity and competency of the 'Core' team behind Coda).

Brief Dive into Ring Signatures

librehash — Sun, 17 Oct 2021 14:45:26 +0000

Little write-up on Monero's "ring signature" construction; enjoy!

Below is a graphic showing what a "normal" transaction looks like (Bitcoin), for comparison:

As we can see in the chart above, transactions can be finitely tied to addresses on blockchain (without a doubt). While it is true we may not always know the name of the identity behind a given address, there is zero doubt about where a given transaction came from. In fact, Bitcoin does just the opposite by enshrining quasi-permanent evidence on the blockchain akin to a living archive that one refer to as as proof that a certain address sent some form of payment on the blockchain.

Specifically, when we mention proof - we're referring to the fact that virtually all transactions include a signature, which is cryptographically linked to the associated public key for the wallet address, removing virtually all doubt about the address of the sender.

Below is a closer look at some of the granular information included within each transaction:

How Ring Signatures Work

Ring signatures are expressly different in that the sender of the transaction includes addresses of several other potential senders of the transaction.

Out of all the addresses in a given ring signature construction, only one of them is the actual sender of the transaction. Transaction amounts are also not included with transactions as a means of further removing information that observers could use to 'decode' the transaction and figure out the true sender.

Despite there being several proposed candidates for the transaction (including the "real" one), only one signature is produced and verified by the blockchain as proof that the transaction is legitimate. This signature can be verified & validated as legitimate without knowing the identity of the "true" sender in the group.

All of these characteristics are able to exist within this "ring signature" structure due to cryptographic principles premised on certain empirical mathematical proofs. For the sake of brevity, those cryptographic principles will not be elaborated upon in this write-up.

Below is a visualized representation of a transaction constructedf rom a 'ring signature' setup:

Take a mental snapshot of that photo above its going to be used in the next section where we uncover how 'MyMonero' rips this privacy model to shreds.

Understanding How Decoys are Selected on Monero

Few are familiar with how Monero works on a fundamental level (if you read the description), its clear in MyMonero's construction that there is zero privacy afforded to the end user.

Reasons for this are:

Use of WebRTC: This exposes the user's IP address to the server that they are connecting to. Also, this deviates from the JSON-RPC that is normally for RPC connections. Since there is one endpoint that is receiving the information, polling the blockchain and 'bookmarking' various points in the blockchain where transactions are stored, 'MyMonero' stands as one major central point of failure for anyone relying on their services.
Deceptive Marketing Surrounding the Use of the View Key: According to MyMonero's website, "only your view key" is shared with the server. Yet, in the very next sentence the service claims that they "keep no log". If that is the case, then there is no reason for any portion of any user's keys to be kept on the server.
OpenAlias is Not Secure: This goes down to the construction of OpenAlias itself as a protocol. While Monero claims that DNSSEC validation is provided for any and all URIs linked with OpenAlias, there is no documentation outlining exactly how this is done. Additionally, it is not clear in the codebase where (if anywhere) such validation takes place. That point aside, the DNS system was never designed to afford anonymity or privacy to those that use it (hence why 'TLS', 'dnscrypt', 'VPNs' etc., are so popular today). Thus, by taking a private protocol like Monero and tying one's address with a finite entity, the opsec risk incurred is enormous (potentially eroding privacy flat out for all users of the protocol).

False Claims Made on the Site

On the site, there is a brief paragraph at the bottom of the page that makes the following claim:

"Your app data is saved locally under strong encryption and only your "view key" is shared with the server. We keep no logs. You can also connect to your own server under Preferences."

However, this statement is wholly inconsistent with one made at the top of the webpage where it states:

"There's no Monero blockchain node to run. The MyMonero server does the heavy lifting for free. Forget spending days syncing the blockchain from your phone while waiting in line to pay for coffee. Get your entire transfer history instantly on any device with only your seed words."

Breaking Down Transaction Sending on the Monero Protocol

The key to understanding the contradiction in the two quotes requires some understanding of how transactions are sent to users on the Monero protocol.

When a user generates a Monero address they receive 5 different addresses in return:

The formatting of the webpage chomped up one of the inputs (use your imagination), but what a user will typically receive is their:

private spend key
public spend key
private view key
public view key
concatenated Monero address

Breaking Down the Spending Process

Whenever someone wishes to send funds to another using Monero, they will send over their 96-byte Monero address.

This address is a concatenation (combination) of both the public spend and view keys.

The sender splits this 96-byte key into its two constituent parts, then derives a sub-address from the public spend key (first). This address is considered the stealth key.

Once the stealth key has been created, a transaction is crafted by the sender that makes the payment to the stealth key, then that transaction is encrypted to the public spend key of the recipient.

From that point, the recipient must scan each and every single transaction on the blockchain, attempting to decrypt each, until they find the correct one (i.ehttps://dev.to/librehash/rust-ephemeral-encrypted-containersfs-maybe-4jlk., the transaction that they are able to successfully decrypt). At that point the recipient can log the transaction in their wallet address as one that they've positively received (without finding this information, the payment is effectively "lost" [to everyone except the sender of the transaction]).

This process requires the recipient to use their private view key. Once the transaction has been retrieved, the recipient must use their private spend key to actually spend it to someone else (spending the transaction requires the same process).

Below is an illustration that captures this process succinctly:

Tying This into the Research Paper's Findings

Let's go back to how someone sends a transaction on Monero.

First they receive the 96-byte address (or copy it from whatever website its hosted at). The address is the result of the concatenated public view & spend keys of the intended recipient.
Once these two keys are extracted from the 96-byte address, a subkey is derived from the public view key.

Once that subkey is generated / derived from the public view key (using scalar multiplication ; leveraging commutative property), the subkey (public) is then encrypted to the recipient's public view key.
The sender does not usually reveal where they sent the transaction to. However, the sender does possess knowledge that will allow them to know when the transaction has been sent - the key image.

Key Image in Monero

Every single transaction is accompanied with a 'key image' of some sort. That key image is necessary for funds to be spent by the recipient of (whatever) transactions that they have received.

The key image is unique for each and every single transaction on the blockchain. The key image is generated with each output, but the key image from that output is not seen in the actual chain until that output is spent (at some point).

Thus, the sender is in a position where they're able to at least tell when/whether a recipient has spent the funds that they received by (a) retaining the derived public key that they generated & (b) also remembering the key image that was generated with the transaction itself (if given directly to the recipient, the 'key image' can be used as a means of bypassing the extensive process of scanning the entire blockchain & attempting to decrypt each output until one's key successfully does so).

Exemplified in Documentation + Monero Construction

By virtue of the cryptography that Monero uses, there exists a way for spenders to prove that they spent funds from their wallet (w/o needing to enter the derived recipient address into the equation).

Documentation (in laymen's terms), can be found here - https://www.getmonero.org/resources/user-guides/prove-payment.html (not entirely sure about the veracity of this source, but from what I can see, it appears that the information on *this page was at least accurate; mentioning this because there are a substantial # of pages where the information was not accurate for some reason).

More information about 'proving' that one has made a payment can be found here as well - https://www.monero.how/tutorial-how-to-prove-payment

Out of both links that were sent, however, this latest one provides the best 'proof' that a sender can tell when a transaction has been spent (by the recipient; assuming the sender kept all of the technical details of the send).

Here is the link - https://monerodocs.org/cryptography/asymmetric/key-image/ (these are great docs)

Specifically, this documentation notes that:

Key images prevent double spend attempts
Funds are always spent to a one-time public key (derived from public spend key as sub-address / subkey)
Each key image can only be spent once, since it is related to the derived subaddress that was generated by the sender

Therefore if the sender sees that key image on the blockchain, then they can be assured that the transaction they sent is being spent at whatever block height where they've spotted the transaction. As an added bonus, once this deduction has been made, the observer (sender here), will also be able to rule out the subaddress they sent funds to if they see it in rings subsequent to identifying the spent generated key image. Thus, if and when they do (if they're observing), they will retain the added benefit of striking off another mixin from the ring when they spot a re-use of the generated pubkey subaddress.

How Monero's Model Yields Way for Abuse

If we go back to that pdf (have to upload it now since the Linode servers are suspended), we can see that the researchers publishing about the 'flood attack' came to what should be a fairly obvious consensus based on what we know - and that's that ring signatures on Monero can be decoded (to some extent) if someone is able to rule out some % of the mixins (accurately).

Unfortunately for Monero users, validating / removing certain outputs via process of elimination is something that can be cross-referenced empirically (since this is all based on cryptography and mathematical proofs).

Undertanding the Mixin Process for Monero

At the time of writing, Monero mandates 11 mixins per transaction (giving an observer a 1/12 chance in 'guessing' the true input).

Below is an illustration that provides a bit more clarity on how these mixins are slotted into future transactions.

The researchers that we're covering that published information about the transaction flooding deduced that if they could send enough transactions on Monero (in a short enough timeframe), then inevitably, some of the future blocks would contain public keys generated from them (via those sends), that they can later recognize & rule out.

Since Monero has no provision that to combat this, this simple method of analysis is essentially 'checkmate' for the project until they change its construction entirely.

Why This is Checkmate

Some may be tempted to argue that Monero could simply add more 'mixins' to the equation to increase the difficulty of deciphering the "real" input.

However, those individuals should keep in mind that additional mixins means additional selections must be made from the blockchain. Thus, if we're in a situation where there are 10 mixins (hypothetically) and the flood attacker is responsible for creating 5/10 of those mixins, it must be considered that tacking on an additional mixin (as a requirement), could result in another attacker mixin being added (resulting in 6/11 vs. 5/10).

Assuming there is an attacker using this technique (which evidence that we'll review later suggests there is), then the benefit of mandating any additional mixins could be negligible at best. In a worst case scenario where the attacker is able to maintain a TX flooding output that makes them responsible for 60%+ or more of transactions outputs, its quite possible that adding more mixins as a requirement could deteriorate the protections provided by the ring signature even further.

Rust Ephemeral Encrypted Containers/FS (maybe)

librehash — Sun, 17 Oct 2021 14:41:09 +0000

Rust Ephemeral Encrypted Containers/FS (maybe)

Running through the 'zboxfs' code and these are some notes. Should be able to spin it up & get the general gist from what's written here, enjoy!

What's Up With 'ZBoxFS'?

ZBoxFS is a random project that I had came across a few times prior and logged in my notes somewhere. However, very recently when researching a few solutions for a blockchain-based wallet (agnostic) that I was devising for Librehash members, I stumbled back onto their main repo once again.

You can all find that URL here - https://github.com/zboxfs/zbox

Breaking Down te ZboxFS Project

The project caught my eye for a few reasons:

Smart Design - The way its constructed actually makes sense & it appears to fit into a niche use case / purpose that no other app has fulfilled as of yet.
Strong Cryptographic Algorithms - We'll get to this part soon, but the cryptographic algorithms this project uses are 'strong', for lack of a better term. Truly that better term would be that the algorithms it employs in its orchestration are secure (there are strong cryptographic algorithms / functions that can be vastly insecure when applied incorrectly or used in inappropriate situations).
Continuously Maintained - The development is up to date on this project; as a rule of thumb, I generally don't touch 'dead projects' unless I have some sort of long-term plan to revive them in the future at some point (to be rebranded under Librehash when I can be sure that we have the resources to effecticely maintain the project w/o abandoning it ourselves).

Describing the ZBoxFS Project

In their 'readme', they state, "ZBoxFS is a zero-details, privacy-focused in-app file system. Its goal is to help application[s] store files securely, privately and reliably. By encapsulating files and directories into an encrypted repository, it provides a virtual file system and exclusive access to authorized application."

Curiously, it goes on to state, "Unlike other system-level file systems, such as ext4, XFS and Btrfs, which provide shared access to multiple processes, ZboxFS is a file system that runs in the same memory space as the application. It provides access to only one process at a time."

Finally, the authors state, "By abstracting IO access, ZboxFS supports a variety of underlying storage layers, including memory, OS file system, RDBMS and key-value object store."

This unique property means that not only does this app encrypt on the fly, it also provides some level of isolation from the other processes / facets of the filesystem (on the OS its deployed on).

Listed Features

"Everything is encrypted 🔒, including metadata and directory structure, no knowledge can be leaked to underlying storage"
"State-of-the-art cryptography: AES-256-GCM (hardware), XChaCha20-Poly1305, Argon2 password hashing and etc., powered by libsodium."
"Support varieties of underlying storages, including memory, OS file system, RDBMS, Key-value object store and more"
"Files and directories are packed into same-sized blocks to eliminate metadata leakage"
"Content-based data chunk deduplcation and file-based deduplication."
"Data compression using LZ4 in fast mode, optional."
"Data integrity is guaranteed by authenticated encryption primitives (AEAD crypto)"
"File contents versioning."
"Copy-on-write (COW 🐮) semantics"
"ACID transactional operations."
"Built with Rust."

The very last listed feature is a huge one. Rust is our favorite language (up there with Golang, Python & C++ / C), for its memory-safety features as well as its robust community & surprisingly well-designed apps (which really feel like a 'hook up' everytime you run into one of them; this tool being case-in-point).

What's there not to love here? (we'll get into that soon, which will explain the rabbit hole that we went down just to get to this point).

ZboxFS Architecture

Below is one of the diagrams Zbox provides on their GitHub to help readers visualize the difference between the way their software is instantiated versus other well known file systems and tools.

Which was then followed by a feature matrix.

Below is a feature matrix that shows the different storage backend options that come with Zbox.

Rust-specific documentation can be found here at this link - https://docs.rs/zbox/0.9.2/zbox/

Running Through Some of the Mock Rust Code for ZboxFS

Since there are some easy-to-run examples provided right on their Rust project page, we'll extract those (in code blocks), for those that may be interested in running this code on their own personal machines (as they read).

The following code is said to be designed with the intent of showcasing how to 'create and open a repo using memory as underlying storage' (sort of like tmpfs / ramfs).

use zbox::{init_env, RepoOpener};

// initialise zbox environment, called first
init_env();

// create and open a repository
let mut repo = RepoOpener::new()
    .create(true)
    .open("mem://my_repo", "your password")
    .unwrap();

File content IO using Read and Write traits

use std::io::prelude::*;
use std::io::{Seek, SeekFrom};
use zbox::OpenOptions;

// create and open a file for writing
let mut file = OpenOptions::new()
    .create(true)
    .open(&mut repo, "/my_file.txt")
    .unwrap();

// use std::io::Write trait to write data into it
file.write_all(b"Hello, world!").unwrap();

// finish writting to make a permanent content version
file.finish().unwrap();

// read file content using std::io::Read trait
let mut content = String::new();
file.seek(SeekFrom::Start(0)).unwrap();
file.read_to_string(&mut content).unwrap();
assert_eq!(content, "Hello, world!");

"*Discovery navigation can use


 and

 ```PathBuf```

. The path separator should always be "/", even on Windows.*"



```Rust 

let path = Path::new("/foo/bar");
repo.create_dir_all(&path).unwrap();
assert!(repo.is_dir(path.parent().unwrap()).is_ok());

Cryptographic Primitives

of the most ‘relevant’ ones for our endeavors (hint: most of them are going to be related to the memory handling of the k
This is one of the most important features of this app (since we don't have time to play Daniel Bernstein to someone else's project). Information about the cryptographic schemes baked into this project can be found here - https://docs.rs/zbox/0.9.2/zbox/enum.Cipher.html

Among ciphers (encryption), users have the option of either going with AES256-GCM (known to be vulnerable to side-channel cache timing attacks; not good) or XChaCha20-Poly1305, which is considered to be highly secure; specifically, it is resilienit to the same side channel cache timing attacks that AES256-GCM could fall prey to.

Encryption Parameters

Key Size - 256 bits
Nonce Size - 192 bits
Block Size - 512 bits
MAC Size - 128 bits

Up to this point, this write-up has failed to mention that one of the libraries baked into this program is 'libsodium'. For those that don't know, 'libsodium' is one of the best open-source cryptographic libraries available to programmers (hence why you its in use so frequently).

Official GitHub repo for this library can be found here - https://github.com/jedisct1/libsodium
website - https://libsodium.org/
libsodium documentation - https://doc.libsodium.org/
libsodium audit (sponsored by PIA before they were bought by an independent company) - https://www.privateinternetaccess.com/blog/libsodium-audit-results/

Critical libsodium Feature: 'Secure Memory'

There's one portion of the documentation that provides extensive information on the code / syscalls / declarations one would need to use in order to provision 'secure memory'.

Zeroing Memory

void sodium_memzero(void * const pnt, const size_t len);

"After use, sensitive data should be overwritten, but


 *and hand-written code can be silently stripped out by an optimizing compiler or by the linker.*" 

"*The*

 ```sodium_memzero()```

 *function tries to effectively zero*

 ```len```

 *bytes starting at*

 ```pnt```

, *even if optimizations are being applied to the code*."

Locking Memory

int sodium_mlock(void * const addr, const size_t len);

"The


 function locks at least*

 ```len```

 *bytes of memory starting at*

 ```addr```

. *This can help avoid swapping sensitive data to disk*."

Some additional recommendations given:

"Totally disable swap partitions on machines processing sensitive data."

"Use encrypted swap partitions"

Disabling Core Dumps When Running Crypto Code (in order to ensure that sensitive data cannot be leaked out during the process itself). "This can be achieved using a shell built-in such as


 *or programmatically using*

 ```setrlimit (RLIMIT_CORE, &(struct rlimit) {0,0})```

. 

Its also recommended for folks to disable kernel dump as well if they find themselves in a situation where they're disabling swap partitions. 

**More Restrictions to Secure Memory** 

Its worth noting that all of these restrictions are ones that can be exercised w/o libsodium since they effectively mirror already existing Linux syscalls. 

For those curious, here is a link to all existing Linux syscalls (per the 5.14 kernel release at the time of writing) - https://elixir.bootlin.com/linux/latest/source/include/linux/syscalls.h (ignore the underlying source code for the syscalls here). 

Below are a list of the most 'relevant' ones for our endeavors (hint: most of them are going to be related to the memory handling of the kernel itself anyway). 

If this were the direction that we were electing to go in, then we would need to find a way to bind that 'C' code to be used with Rust (since this is at the heart of the program). 

### One Major Issue With the ZboxFS Setup 

Just when you thought everything was perfect! There's a little problem we run into here with the instantiation of this tool (zbox). To understand this problem, one must visit their website (https://zbox.io). 

![](https://notes.librehash.org/uploads/upload_53425baf8ee235f68ed6f6d3f5dd0350.png)

As we can see in the photo above, the site pivots this tool toward a paid model / subscription-based service rather than maintaining its posture as an open source tool / app for us to use. 

This is likely the reason for the restricting coding dictating the available backends (should be configurable vs. finite options). 

![](https://notes.librehash.org/uploads/upload_038eb311e5e9ed3204a0927c400221d4.png)

Also, rather than positioning itself as a mountable, custom fs (file system ) created on the fly for the purposes of local on-the-fly encryption, the website conveys that this tool is purposed to facilitate cloud storage (i.e., encrypt the data on one's desktop / locally, then store said data remotely). 

If the app fails to provide us with flexibility in the backend tools that we can provision, then all of its advertised 'features' are a mirage. 

![](https://notes.librehash.org/uploads/upload_ee8d85dbfbb9dbeacfb8d9ad98272ee7.png)

Further evidence that this app was designed to pivot developers & users alike toward their custom, proprietary storage setup can be found in the example code snippets they give on their main site. 

Below are two samples of code they give for creating an instance of 'zbox' and attaching it to a storage (cloud) backend via API (which of course has their site plugged in out-of-the-box, with no documentation on how one would effectively swap out their provided IPs for anther [custom one] provided on the backend). 

The first code sample is Javascript, second = Rust.



```javascript 
// create a Zbox instance
const zbox = new Zbox();

// initialise Zbox environment and turn on debug logs
await zbox.initEnv({ logLevel: 'debug' });

// open the repo
var repo = await zbox.openRepo({
  uri: 'zbox://yb2CCTcmEuxenZVuZhVKMCJD@AWCpPaNkvG6vVW',
  pwd: 'secret password',
  opts: { create: true }
});

// create a file and write content to it
var file = await repo.createFile('/hello_world.txt');
await file.writeOnce('Hello, World!');

// seek to the beginning of file and read all content
await file.seek({ from: Zbox.SeekFrom.Start, offset: 0 });
const str = await file.readAllString();

// close file, repo and exit Zbox
await file.close();
await repo.close();
await zbox.exit();

// initialise Zbox environment
init_env();

// create and open a repository
let mut repo = RepoOpener::new()
    .create(true)
    .open("zbox://yb2CCTcmEuxenZVuZhVKMCJD@AWCpPaNkvG6vVW",
          "secret password")
    .unwrap();

// create a file and write content to it
let mut file = OpenOptions::new()
    .create(true)
    .open(&mut repo, "/hello_world.txt")
    .unwrap();
file.write_once(b"Hello, World!").unwrap();

// seek to the beginning of file
file.seek(SeekFrom::Start(0)).unwrap();

// read all content
let mut content = String::new();
file.read_to_string(&mut content).unwrap();

Of course, the kicker here is when they provide a preview of their architecture (geo-distributed cloud storage); enticing users to create an account / node / storage pool that they host & maintain.

App is Still Usable

Fortunately for us, we can still definitely use the app spec as it is currently (but we're going to need to work at it a bit though first).

Additionally, we can provision this app in a way where we can be sure that the remote server we authenticate with (i.e., not 'zbox.io', but something provisioned by Librehash), will be 100% ignorant of the content being stored on the server (hopefully to the extent of not revealing any metadata about what's being encrypted remotely).

Ultimate Goal - Use this as an application backend for wallet apps & other similar tools where sensitive cryptographic operations are being performed

Good News - API is Swappable

The references to the remote server provided by Zbox in their code can be edited (with trivial ease) to be replaced with our custom backend (alongside some authentication mechanisms to provide significantly enhanced security assurances against a potential MITM attack [in case there were a malicious entity attempting to phish / impersonate our desired target remote server storage]).

API reference can be found here - https://docs.zbox.io/api/

Specifically, there is reference code for Javascript, Rust, and Android (Java). We're going to focus on the Javascript for the time being (despite the fact the app is written in Rust); there's a reason why we're doing this [that will be explained at a latter point].

Diving into the API Reference

From the picture above, we can deduce that the only palpable change that needs to be made here is in the URL where the data will be stored (we'll get to explaining exactly what the replacement backend storage will be shortly).

Example 'Calling' Style

As we can see below, the 'calling' style for this app (API; javascript), is very similar to what we've seen elsewhere (if you're someone that deals with API frequently).

Below is some boilerplate code that was prepared to demonstrate the iterated call style for this app.

// Promise chaining
zbox.openRepo({
  uri: 'zbox://access_key@repo_id',
  pwd: 'secret password',
  opts: { create: true }
})
.then(repo => repo.openFile('/foo/bar.txt'))
.then(file => file.readAll())
.then(data => console.log(data));

// Async/await
async function asyncFunc() {
  var repo = await zbox.openRepo({
    uri: 'zbox://access_key@repo_id',
    pwd: 'secret password',
    opts: { create: true }
  });
  var file = await repo.openFile('/foo/bar.txt');
  var data = await file.readAll();
  console.log(data);
}

Of course, the app comes with 'error handling' as well (nothing that we're going to spend too much time focusing on anyway).

The following configurations are relevantly important (this provisions the local / client-side encryption & derivation schemes via the provided KDF).

{
  opsLimit?: OpsLimit,    // default: OpsLimit.Interactive
  memLimit?: MemLimit,    // default: MemLimit.Interactive
  cipher?: Cipher,        // default: (see below)
  create?: boolean,       // default: false
  createNew?: boolean,    // default: false
  compress?: boolean,     // default: false
  versionLimit?: number,  // default: 1
  dedupChunk?: boolean,   // default: false
  readOnly?: boolean,     // default: false
  force?: boolean         // default: false
}

Explaining the Difference Between Bitcoin and Ethereum Transcations (UTXO vs. Account-Based Transactions)

librehash — Thu, 01 Apr 2021 07:29:26 +0000

This breaks down the difference between account-based transactions (which Ethereum uses) and the UTXO-based transactions that Bitcoin, Litecoin, Bitcoin Cash and many others use.

While both protocols are Proof of Work (at the time of writing), this difference in assessing / accounting for transactions dramatically alters the way that transactions are confirmed on each distinct protocol type.

First Step: Confirming the Exact Cryptographic Operations

We need either documentation or an extensive resource - this is not information we want to extract from a run-of-the-mill crypto site that you find on Google.

Found a Reliable Source: https://www.oreilly.com/library/view/mastering-ethereum/9781491971932/ch04.html [Mastering Ethereum]

This resource is verbose because it goes through the additional trouble of breaking down cryptography (waste of time at this point - if you're new to these concepts, then you won't be able to grasp the importance of the actual cryptographic primitives that are used to generate an Ethereum address - at least not at this point).

But We Found Out

A) Ethereum uses the same elliptic curve that Bitcoin uses (secp256k1 ; Koblitz Curve on a 256-bit prime)

(this needs to be cross-referenced with specific parameters for the generation of an Ethereum wallet, as provided by Ethereum developers because their implementation of the Keccak algorithm is different than what modern cryptographic libraries [i.e., OpenSSL or any other library that would be used to create such a wallet address would use]).

Their implementation of the Koblitz curve, however is standardized - so that's not an issue.

The 'Mastering Ethereum' book simply reiterates what we already know from the parameter standards published by SECG (https://www.secg.org/sec2-v2.pdf), but below is a picture from the M.E. (Mastering Ethereum abbreviated - we'll use that from here out):

As the book acknowledges, modern cryptographic libraries (just about any on planet earth) possess this algoritihm:

To be clear, however, the library in question for this specific use case (client-side, in-browser cryptographic operations) - would be the 'WebCrypto API' (based on Mozilla's crypto library [NSS] or the crypto modules that Chrome uses).

Both have possessed the capability to perform this type of operation within the browser for quite some time - we're not worried about this at all (our website certificate uses elliptic curve cryptography & was generated manually with a higher bit strength than secp256k1 ; our SCT pinning will soon be of a higher bit-size too [although we'd prefer ed25519 / ed448 key generation in place of these NIST-curves ; but that's another story for another day]).

Ethereum's Hashing Algorithm Choice

The fact that Ethereum opted or Keccak-256 (SHA3) vs. SHA256 (which Bitcoin uses) is already widely known information and there is no problem with this choice.

In fact, its probably a superior option - and not for the idea of an inherent security boost (although that's always a plus ; SHA256 is considered sufficiently secure though) or to mitigate malleability (although this was still an issue that needed to be separately addressed at a later point) ; its primary benefit is increased efficiency for x64 architecture (which virtually everything, even ARM devices, use these days).

More to the point though, this excerpt below is the most 'concerning' point here:

Adding in the tidbit about Edward Snowden is entirely irrelevant and there is nothing noble about Ethereum's refusal to swap out Keccak for the updated parameters provided by the NIST.

The NSA, which works closely in concert with the NIST, has used the NIST as an instrument to include backdoors in published cryprographic algorithms before. This was not revealed by Snowden but rather cryptanalysis by external, independent cryptographers (https://www.schneier.com/essays/archives/2007/11/did_nsa_put_a_secret.html ; long before news of the NSA Program, 'Bullrun' was leaked out - essentially confirming what cryptographers knew to be the truth years prior).

Why the Hash Function is Important

One notable feature of blockchain is that the resulting public keys (addresses ; public-facing alphanumeric identifiers used to mark recipients), is that they require a hash function during the creation phase.

Difference From PGP

The most similar cryptographic system around that mirrors Bitcoin is PGP (GPG; whatever).

The way PGP works is widely known & should be familiar to those that at least understand Bitcoin but aren't familiar with PGP.

For that reason, we won't waste time climbing into that rabbit hole - but one thing must be brought up (to understand how all of this ties together).

PGP restricts hashing to the signing / authenticating of messages in their cryptographic system (see below):

[source: https://users.ece.cmu.edu/~adrian/630-f04/PGP-intro.html#p9 ; site will give you an SSL warning in your browser - its just old, nothing can happen to you because you're just reading html / plain-text [pro-tip: *no site that you visit on the 'darkweb' via Tor Browser has an authenticated certificate, barring some rare exceptions']].

Specification for Bitcoin Wallet Generation

This is technical, but put in simple enough terms to be understood if you sit down and read it (versus skimming it like a social media status):

(source: https://en.bitcoin.it/wiki/Technical_background_of_version_1_Bitcoin_addresses)

Notice that there is a hash operation that is performed immediately after the ECDSA operation (secp256k1; derived from the random seed phrase).

You can ignore the RipeMD-160 as that was used primarily to shorten the output (length) of SHA256's hash function in order to make Bitcoin compatible with x32 architectures (which was a smart, reasonable decision back in 2007/2008 when Bitcoin as being designed & developed by Satoshi Nakamoto).

Specification for Ethereum Wallet Generation

There are some major differences in this process for Ethereum vs. Bitcoin.

Most of these differences derive from the fact that Ethereum's blockchain relies on 'account-based' balance verification vs. Bitcoin's 'UTXO-based' method.

The main difference here is that the user is accounted or in Ethereum, whereas in Bitcoin, there is no concept of a "user" ; rather, Bitcoin is simply interested in ensuring compliance with protocol rules - namely the biggest one, which is avoidance of double spending (not counterfeiting ; that's already addressed off-chain, offline through the 'SCRIPT' language & C++ programming-like op-code functions used to evaluate whether the necessary conditions for spending unspent funds been fulfilled).

Unfortunately, the best source of information on this process is the Ethereum Yellow Paper.

The reason why the word 'unfortunately' is used is because it is extremely dense in the language that's used. We don't think that it needs to be dense as it is (this is not to 'dumb it down', but simply to make the writing more fluid & intelligible ; but we'll dig into prose conversations later).

See the first relevant excerpt below:

(source: Ethereum Yellow Paper ; its located all over the place, so access it from someone / somewhere you trust)

Attempting to Crawl Through the 'Thick' of the Ethereum Yellow Paper

The excerpt above outlines an important reality of Ethereum.

Since they use an account-based means of accounting for spent vs. unspent currency, they must rely on a different means of authentication.

To be clear, this is different than validation (the Proof of Work mining process). That is the method used to ensure that nobody cheated the process.

What we're referring to is the process those miners are validating in the first process (hence the term, 'authentication').

State 'Nonce' Value

Bitcoin 'stamps' transactions via block generation in a way that allows users on the network to quickly access the validity of spend attempts by simply polling which blockchain possesses the greatest Proof of Work.

The limit here, however, is that the most up-to-date view of the blockchain is restricted to whichever chain has the greatest Proof of Work. And that Proof of Work total is only updated every 10 minutes (or so). Thus, anything that happens between updates (i.e., new blocks being published) is in limbo.

There's no telling when a block will be created.

For Ethereum, the 'limbo' is mitigated significantly (but the throughput is still limited ; that's a different conversation).

In order to 'update' the blockchain, the blockchain maintains the 'state' value of each "account" by mandating an eternally increasing 'nonce' to delineate the blockchain's state at any given time.

How the 'Nonce' Works

Each time that an Ethereum account sends a transaction or performs an operation, the 'nonce' value increases (by just one integer).

See below for a super simplified, super quick breakdown of how that works:

Account A sends 1st Transaction: Nonce state = 1

Account A sends 2nd Transaction: Nonce state = 2

Account A makes a call on some random contract: Nonce state = 3

... (etc)

As one can tell from what we showed above, the nonce state is an infinitely, ever-increasing value that is referenced in order to ensure that nodes on the chain are not accepting blockchain versions with competing 'versions' of how these nonce epochs played out.

Benefit

The biggest benefit here is that this adds an additional layer of verification (on top of just using Proof of Work) and this is needed given the contract functionalities that are on Ethereum.

(let's leave this here and move on with it).

Check Out the Explainer Below From a Wonderful Medium Article That Digs Into Ethereum Blockchain Nonce Values

(source: https://medium.com/swlh/ethereum-series-understanding-nonce-3858194b39bf)

This brings us all the way to the trouble with Ethereum wallet apps (and why you don't really see a ton of them in the same way that you do with Bitcoin).

Why Ethereum Wallet Apps are Almost Forced to be Insecure By Design

This except below tells us all:

The example that was given above was merely a simplified way to explain this nonce concept.

But in practice (for Ethereum) that increasing nonce value is determined, in part, by the state of the entire blockchain

MyEtherWallet Does Not Need to Account for 'Nonce' Total for Wallet Generation Though

In specific, this increasing 'nonce' total is only relevant for trasactions.

Conceptual Understanding of Wallets

Even though we speak of wallets in terms of some concrete, tangible concept or item that can be manifested or created - the blockchain doesn't account for what addresses "exist" or not.

In reality, the total number of addresses in existence is always equal to the total number of addresses that could be in existence.

The blockchain accounts for this ridiculously large sample space (impossible to create an array for) by only tracking addresses that have been identified in a transaction on the blockchain.

What That Means

When you create a Bitcoin / Ethereum wallet address, the blockchain has no clue this happened.

In fact, that address is as good as "invisible" / nothing until it is involved in a transaction - and at that point, its only significance derives from the fact that it will forever play a role in the accounting of legitimately spent / unspent funds going forward.

This is also the reason for why the blockchain does not need to 'care' about what wallets exist and don't.

Digging Back into the Keccak Hash Function Used During Wallet Creation or Ethereum

We don't need the Ethereum Yellow Paper for this one (fortunately).

Let's take a look at how an Ethereum wallet address is created (per 'FreeCodeCamp' ; see below):

(souce: https://www.freecodecamp.org/news/how-to-create-an-ethereum-wallet-address-from-a-private-key-ae72b0eee27b/)

Yes, its that simple.

Merged Mining With RSK: Deep Dive

librehash — Thu, 01 Apr 2021 07:26:59 +0000

Won't get into the technicalities of how merged mining works (just yet); just going to look at something that I found and we can go off there when I have the time one day.

This is a coinbase reward for this transaction here: 7a14dc3f8340c4d81cb29a5c1f49f56536a45030a5bfe659e4f27bce59a2e15e

Using the 'EY Blockchain' tool, we can glean significantly more information about the transactions:

We also have the benefit of seeing the details of each input in the transactions as well (shown below):

Above are all of the details of the op_return inputs that were fed into the transaction (remember this TX is a coinbase reward, so all inputs are generated "out of thin air").

The recipient address (1KFHE7w8BhaENAswwryaoccDb6qcT6DbYY) had the following TX Script attached to it:

Understanding the Op_Return Flags Better

I'm curious about the 'op_return' flags that were added to the transaction as well.

See that below:

Transaction ID (once again if not saved above) = 7a14dc3f8340c4d81cb29a5c1f49f56536a45030a5bfe659e4f27bce59a2e15e

That means that the current documentation is (and has always been) wrong re: transactions on Bitcoin / Litecoin / other chains using op_return within a UTXO framework.

question: is the documentation on op_return actually wrong or have I simply not read it closely enough to discern the difference?

Some Links:

Generalized Bitcointalk Link: https://en.bitcoin.it/wiki/OP_RETURN (this provides a peripheral conversation re: merits of op_return) ; nothing in here explicitly suggests that op_return opcodes being added into the transaction somehow invalidate the entire transaction.
General Documentation RE: 'op_return: Encompassed within the article, 'Script', published on the Bitcoin Wiki [https://en.bitcoin.it/wiki/Script]. Turns out that a TX that contains op_return in it, no longer burns data on the protocol??.. [could've sworn it was like this just a few weeks ago].

Visiting the Bitcoin Core Reference Client Documentation

On the Bitcoin Core website there is a section dedicated to addressing some facet of 'op_return' (based on the 0.12 release, which featured more flexible options to be used in conjunction with op_return).

source: https://bitcoin.org/en/release/v0.12.0#relay-any-sequence-of-pushdatas-in-opreturn-outputs-now-allowed

It states:

"Previously OP_RETURN outputs with a payload were only relayed and mined if they had a single pushdata. This restriction has been lifted to allow any combination of data pushes and numeric constant opcodes (OP_1 to OP_16) after the OP_RETURN. The limit on OP_RETURN output size is now applied to the entire serialized scriptPubKey, 83 bytes by default."

This is even more interesting when considering the fact that there has been a wealth of information to suggest that this is simply not the case though...but okay.

Hmm; in that case, this means that op_return only makes a specific transaction output unspendable (not the entire transaction, which is what we all had figured at one point in time... interesting; if there's anyone that's reading this that has anymore information on this, please reach out and provide some feedback on this).

RSK Merged Mining

What makes 'bitaps' a great tool is the fact that it provides an ASCII translation of some of the information included within the transaction.

See below if you're lost:

The only intelligible portion of the blob circled in the picture above is 'RSKBLOCK'.

Clues to Discern the Meaning of This Block

It appears that we don't need to look far since Sergio Damian Lerner and Jameson Lopp both provided their own dissection of the block (following a pretentious chastisement of the Federal Reserve for doing everything in their power to save the world from a financial apocalypse unlike any other):

https://twitter.com/lopp/status/1259929075902222345?s=20

That tweet bears no importance for us, but the following one by Sergio (longtime Bitcoin Core developer team member) does:

https://twitter.com/SDLerner/status/1259954999305613315?s=20

What is RSK and How is Merged Mining Used With it?

It seems prudent to start with their Twitter account (linked in Sergio's Twitter post), which can be found here: https://twitter.com/RSKsmart

In their bio, they claim to provide, "Smart contracts for ₿ [symbol for Bitcoin]"

One tweet that really got our attention on their page was the following one:

https://twitter.com/RSKsmart/status/1348721442339377156?s=20

More than 50% of the Bitcoin hashing power has been leveraged for merged mining with RSK? That's a considerable amount, especially considering the fact that there are few (if any) individuals that mention RSK when talking about the features / benefits of Bitcoin

What the Hell is "RSK" For Real?

To learn more, we decided to visit the homepage of RSK to see what it is about this platform that's managed to garner >50% of the network's total hash rate.

This DeFi promise is obviously recent (more than likely added in response to the recent DeFi craze in the blockchain space).

What we're looking for more information about can be found below:

For users that can't read the screenshot above (for whatever reason; contact the author if this is the case), it says:

"RSK is the most secure contract platform in the world. RSK's Contract goal is to add value and functionality to the bitcoin Contracts ecosystem by enabling smart contracts, near instant Contracts payments, and higher scalability."

It then states (at the bottom, in bold):

"RSK Blockchain is connected to Bitcoin through Merged Contractsr Mining and the two-way peg also known as the bridge."

Interesting.

Let's press that 'learn more' button to see get some details on how exactly this is supposed to work...

Clicking said button takes us to this link here: https://www.rsk.co/rsk-blockchain/

For All the Visual Learners Out There

Before we even get into an explanation of how RSK Mining works (especially in lieu of its merged mining property), below is a GIF that effectively gives the general gist for how this merged mining works:

A more verbose explanation of how it works:

Still confused? Don't worry - so are we. So let's climb a bit deeper into this rabbit hole.

How the RSK Mining Two-Way Peg Works

More information (documentation) on the ("POW"-peg as they term it), is located here: https://developers.rsk.co/rsk/architecture/powpeg/

According to the documentation:

"RSK’s 2-way peg protocol, called “the **Powpeg”, has matured from its inception in 2018 as a federation to now include many decentralized qualities. The new RSK Powpeg protects private keys stored in special purpose PowHSMs based on tamper-proof secure elements (SE). Each PowHSM runs an RSK node in SPV mode, and so signatures can only be commanded by chain cumulative proof of work. Security is established in the Powpeg through the simplicity of a layered design we refer to as defence-in-depth."

The explanation here is a bit convoluted, admittedly, and seems to be significantly inferior to a directly interopereable solution (such as what Librehash is attempting to do currently!).

General Gist of the 'Two-Way Peg' (as well as the overall protocol)

Essentially, the documentation acknowledges a supposed shortcoming of the Bitcoin protocol by noting that it is Turing "incomplete" (although, this is also what allows Bitcoin transactions and addresses to be generated in a stateless manner; so this appears to be a fair tradeoff).

RSK posits itself as an "extension" to the regular Bitcoin protocol. In order to utilize the supposed extended features that come with RSK, one must send their bitcoins to a "special address" (multi-signature as well) .

This is because, RSK was designed to, "distribute trust among parties: multi-signatures."

According to the documentation:

"With a multi-signature it is possible to give a group of notaries the task to protect locked bitcoins, tolerating a certain amount of malicious, hacked or unavailable parties."

PoW-peg

According to the documentation, this was an evolution in the federated consensus standard that RSK was using previously.

Per the documentation:

"The Powpeg is a unique 2-way peg system that secures the locked bitcoins with the same Bitcoin hashrate that establishes consensus."

[Merged mining, in essence]

The means by which this 'two-way peg' is created is a bit convoluted.

Without wasting too much time, the specification for this facet of the protocol was grabbed from the documentation for time's sake (you can read this all directly if you really want to know more about the specifics of the specification):

This setup honestly feels very convoluted, and what's still confusing here is that there does not seem to be any external / intrinsic reason why someone would want to help keep this network functioning (specifically >50% of the hashrate on Bitcoin).

The motivation that the documentation gives can be found here:

"Since there is no collateral, the RSK Powpeg members are incentivized to participate by receiving a small portion of RSK transaction fees that is automatically channeled to them. As seen in the Ethereum ecosystem, transaction fees can eventually provide a sustained income for miners and sometimes even higher than the blockchain subsidy."

Intermediate Conclusion

People will probably hate me for this conclusion at some point in the future (assuming they ever read that far into this write-up ; if you did, good on you!), but this doesn't feel like something that's worth too much more of our time.

Merged mining is not a new concept (in fact, Satoshi Nakamoto devised the concept on the fly in responise to the proposal of Namecoin as a supplementary project designed to fulfill another duty of Bitcoin that the original protocol is not designed to do)
Considering the fact that the RSK protocol requires 100 confirmations for a "peg-in" transaction to be considered valid (3/4th of a day pretty much), it is unlikely that there will ever be an influx of users looking to submit bitcoins for a 'peg in' to the RSK network (the process feels a bit convoluted as well)
The additional requirement of a PowHSM ownership for interaction with the RSK protocol places a fairly substantive burden upon any prospective end users (and even calls into question who the target audience for this tool actually is)