Odd Passenger: Solving User Authentication via Artificial Intelligence, Pt. II



Part II: Networked Smart Contracts

Since the beginning of my winter break from Columbia SIPA, I’ve had the opportunity to do some fairly extensive dev work on some personal smart contract projects. Among my aims was exploring the possibility of networked smart contracts (“NSC”). By NSC, I am not referring simply to contracts with public function calls of their peers, but rather to contracts that make public function calls to other contracts on other chains.

Currently, contracts written in Solidity have external visibility, and function parameters can be declared so that they may be accessed externally by other contracts. Should a contract need to pull in a function that is defined elsewhere, it can do so by creating an EVM function call and have that brought over to the current contract that is being executed. This has obvious advantages as some contracts may be complex and require segmentation for organization, or more practically, to ensure that gas is spent in an efficient and easily-auditable manner.

An oversimplified call can be seen in the following example:

However, the downsides of this system is that contracts can only reference others if they are operating on the same blockchain, such as ethereum. For now, given the relative infancy of the technology, this isn’t a problem as smart contracts are comparatively simple relative to their physical counterparts, and don’t require massive computations or complex logic. This will eventually change as time progresses and blockchains are incorporated into and built by more industries.

The reason that this functionality should be implemented is due to this future adoption, as well as the high likelihood that proprietary chains will be built to handle different processes and solve different issues. While a number of companies and projects are attempting to lead the future of blockchain development and design what will be the eventual standards of blockchain, there isn’t mass adoption of one set (even though there is certainly heavy sway towards technologies such as ethereum). Over the past year, I’ve consulted on a number of different blockchain projects and have identified a common theme in my work: while everyone wants their own “chain” to satisfy the same requirements as their peers, several clients (and especially larger institutions) need some intercompatibility with their partners. If everyone is using different blockchains, we’ve accomplished little more than overcomplicating extant proven systems.

Eventually what I see happening is that the number of available and competing blockchain technologies will get smaller. Hobby projects will eventually get abandoned, some of the more innovative chains produced by smaller firms and startups will be acquired, and several institutional collaborative efforts (such as Hyperledger) will remain as the enterprise-class options. Further, I envision that multiple chains will still exist, and this is especially true in industries where larger organizations have a good argument for implementing their own proprietary versions of blockchains (such as the financial industry).

Going back to my original point, there is no current way for these various blockchains to talk to one another. One might argue that the security provided by decentralization obviates the need for multiple blockchain implementations, and that all data that might need to be transacted on a blockchain could be transacted on a single chain. There are obvious disincentives. For example, in a highly-regulated industry such as banking, financial institutions would need their own ledgers to ensure adherence to incredibly complex auditing requirements. Organizations that require exceptional security such as governments might need to run their data in-house with each agency maintaining their own chain. Instances even as simple as a separation between corporate sales and manufacturing departments might have a decent argument to maintain separate blockchains. If chains are implemented independently, we need to design protocols and standards for NSC to facilitate secure and reliable communication and connectivity between them.

It’s important that the blockchain community writ large makes two important policy decisions. First, the community needs to decide on a clear and defined set of standards to abide by in the development of various blockchains. This is difficult given that interested companies, project collaborations, and open source efforts are constantly expanding the limits and possibilities of the technology. Everyone is moving outward in various directions to be first-to-market with their respective inventions and improvements. However, those moving in substantially similar or even parallel directions need to agree on a set of structural standards to ensure that if both chains get adopted, there are commonalities between them. An example of this is the Bitcoin Improvement Proposal (“BIP”) process where standards for Bitcoin go through a lengthy path of submission, evaluation, and implementation.

Second, in these standards, the blockchain community needs to implement robust communication protocols for these chains to communicate with one another. Chains will eventually replace many legacy systems but will likely do so independently rather than cumulatively, and they will need to be capable of “smart” conversations with their counterparts. There will be an eventual need to have movement by and between chains, either in the generation of new contracts on other chains, or simultaneous execution of contract terms on chains implemented parallel to one another.

If blockchain truly is the future (which I firmly contend that it is), the community should also look ahead to future challenges for the technology. Regardless of how many chains will exist within the ecosystem, they will eventually need the ability to interact with each other to guarantee advanced functionality. Designing blockchain products that are completely isolated from one another may seem like good business practices today, and may help businesses realize significant market shares, but it will hinder the technology’s overall potential going forward.

If you have feedback on this idea, I’d love to hear it! I can be reached via


Featured Image Credit: Gerd Altmann, “untitled”. Public Domain Work. Modified, Desaturated.

SHA256( 09055f5b819086ada38c6e20654df5c7eb28944d18491a7c966822adefea14e8

Codename Brazilian Mango: An Ad Hoc, On-demand, Pre-authenticated Dynamic Routing System



It’s astonishing what a midnight cab ride through New York City can do for creativity and imagination.

A few nights ago, on my way back from having dinner with friends, I was casually reading reddit in the back of a taxi. One of the links that caught my eye was by HACKREAD, “South Korea says their military cyber command was hacked”. Upon review, I clicked a bit farther to the source, Yonhap, South Korea’s largest news agency. A representative of the Korean government mentioned that “[a] malicious code [was] identified and it seems to have taken advantage of the vulnerability of the routing server”.

Although hacks that target routing mechanisms are certainly not unusual (as we have very clearly seen as recently as this past August), we should nonetheless continue to build better alternatives that mitigate their viability.

I started thinking about potential ways to address this problem more generally. Certainly, the easiest answer is to keep security products and perimeter defenses constantly updated to guard against known vulns. Additionally, having a team alert and ready to monitor logs and respond to incidents (especially in systems as critical as the South Korean Military Cyber Command) is crucial.

However, I was curious if there was a way to sidestep this problem entirely. I was trying to conceive a truly out of the box answer and I think I may have one. As with my inaugural post, I’d like to tack on the disclaimer that everyone knows me as “that blockchain guy” and that I typically think about solutions to cyber issues in terms of blockchains (“BC”). This idea is no different. I’d also like to note that I’m not a network guy – although I have some familiarity with terms and protocols, it’s definitely not my area.

Introducing Brazilian Mango

I’d like to introduce you to a [very cursory] new concept, Brazilian Mango (“BM”), an Ad Hoc, On-demand, and Pre-authenticated Dynamic Routing System (“DRS”) for Secure, High-value Networks. Brazilian Mango addresses the following two questions:

  • If high-value systems must be public-facing and accessible over the internet, why must the destination addresses always be reachable?
  • Wouldn’t a target that isn’t there be preferable to a strong target which everyone knows how to locate?

Admittedly, question two seems excessively theoretical, but certainly not without possibility.

A fundamental weakness of current routing systems is that the destinations must always be in a resolvable state to facilitate connection requests and then serve up content or run some type of service. Even if these systems are well defended, happen to be situated behind strong firewalls, employ sophisticated intrusion detection mechanisms, and have safeguards in place in the event that an attacker does break through, they’re still always reachable.

Now, obviously it’s possible to lock down networks in a manner where they only respond to connection requests from certain IPs they recognize (say for example, devices that facilitate interbank wire transfers, or ICS/SCADAs that allow remote access by devices connected via VPN and assigned an internal IP). However, if these networks are public facing and statically addressed, given enough time, intruders can plausibly work out ways to bypass or overwhelm these measures (such as through spoofing or through a DOS/DDOS attack).

Brazilian Mango mitigates these issues by keeping these high-value destination networks unreachable until such time as a trusted client is interested in establishing a connection.

A Nod to the Potential Shortcomings

At this moment, some may argue that this solution is prone to the same caveats as those mentioned above since at some point in the Brazilian Mango process, servers and networks are reachable. With BM however, this is addressed by pre-agreed upon shared ‘secrets’ that permit only pre-authenticated devices to connect, but in a dynamic manner. These secrets, in the context of exceptionally high-value systems, are relatively easy to prearrange (see Step 1, below).

Some may also contend that the concept is similar to services such as Cloudflare. However there are three important distinctions.

    • First, the destination addresses are kept undisclosed or are locked down to accept connection requests only from trusted clients (in this case, Brazilian Mango in Step 4a.1 below). Rather than being able to pass along a connection request to a service such as Cloudflare for routing to an endpoint, the request instead gets announced to Brazilian Mango for routing. If a destination server chooses to accept the connection, then it makes the opportunity available.
      • BM has an alternative to this in Step (4b.1) below wherein no active connections are permitted, and instead the Server (or, as defined below, HVN) monitors the BM BC to generate new network security policy as necessary.
    • Second, destination addresses can change quickly and on an ad hoc basis. One of the main aspects of BM is that destination servers maintain a large pool of available IPs (perhaps ones that they trade in a clearinghouse with other organizations that use BM so that IPs are not routinely reused by the same entities). Think AWS Elastic IPs.
    • Third, destination addresses are only online for the duration that staying in a resolvable state is necessary, otherwise they remain uncontactable.


The Impatient Dog Analogy

Before I get increasingly technical, I offer up “The Impatient Dog Analogy” as a simplified alternative. Obviously I would prefer you read on through the “Steps of the Brazilian Mango DRS Process”, but this is a 10k foot view looking at the fundamentals of the process.

I liken this concept to a dog, who we’ll call Molly, that is outside on a porch next to a door. The owner of the dog is inside sitting on the couch not paying attention to their pet. The owner wants to allow Molly in, but only when they know that she is actually waiting outside. Keeping the door constantly open will enable any one of the members of the family of raccoons that has taken refuge in the nearby forest to enter at will. The owner thus waits for Molly to announce their presence and desire to be let in by listening for a familiar bark. Once the owner hears Molly’s request, they will get up and open the door for her. Unfortunately for the raccoons however (all whom are unable to replicate Molly’s sound), they cannot indicate their presence and desire to enter the house. Molly has an added benefit: the house has multiple doors that the owner is willing to open, barking at any of them will get the owner’s attention and she will be let in. Unfortunately for the family of raccoons however, doing anything other than barking in the same manner as the dog at any of the doors will not induce the owner to open the door.

Steps of the Brazilian Mango DRS Process

  1. The Client and Server (and/or High-value Network, “HVN”) exchange their public keys (kpub) with each other (likely through a physical exchange). Much like with specialized military communications equipment, devices must initially be in the same place or must at least have an initial, absolutely known-secure transfer medium to coordinate the sharing and/or pre-arrangement of ciphers.
  2. At some time in the future, Client makes a request for connection using the Server/HVN’s (kS/HVN)pub that was previously shared during (1).
    • Using the Server/HVN (“S/HVN”) (kS/HVN)pub, the client encrypts its current public IP address along with other parameters in the connection request (such as preferred connection duration, expected bandwidth usage, etc).
  3. Client broadcasts encrypted request to the Brazilian Mango network. This request publically shows a Txinput from Client address (a hashed Client (kclient)pub) and a Txoutput to S/HVN address (a hashed (kS/HVN)pub). Once this request is broadcast, nodes will propagate the connection request throughout the network. Presuming a valid request (see 4a.1 and 4b.1 below), the network will confirm the request, thus signifying to the Destination Server and/or Network that there is a potential connection waiting to be fulfilled.
  4. Infrastructure Type Determines Step Four
    • 4a.1 If BC is Ethereum-based (or an Ethereum-derivative), Autonomous Agents accept request, check for specific criteria, and route request to the Destination (the S/HVN).
    • 4b.1 If Brazilian Mango is not an Ethereum-based BC (or a derivative thereof), the S/HVN will consistently and recursively scan the BC for any confirmed connection requests transacted on the network and sent to the Destination address (the specified Txoutput in Brazilian Mango).
      • The S/HVN may also maintain a local copy of the BC to verify transactions independently and maintain an audit log of both fulfilled and unfulfilled connection requests (See 6).
    • 4a.2 & 4b.2  S/HVN receives request and decrypts it for connection info (assuming it matches criteria set by the Admin of the Destination or the team ensuring 4b.2 the security policy of the network).
  5. S/HVN amends security policy, and assigns a Public IP to a gateway that acts as an intermediary between the Client/Server and/or Client/Network, that accepts connections only from the Public IP listed in the initial encrypted connection request from the Client (the confirmed transaction on the BM blockchain). This IP acts as a unique (to the Client) gateway into the remote network and is assigned from a pool of IPs that the network maintains for Brazilian Mango connections (that can be traded via clearinghouse as mentioned earlier). Client can request, and S/HVN can grant via BC scripting several parameters (similar to Bitcoin’s nLastTime, and OP_CHECKLOCKTIMEVERIFY) that invalidate certain security policies and specific connections at, before, or after a certain amount of time. The routing information is encrypted using the Client (kclient)pub that was previously exchanged during (1).
  6. S/HVN broadcasts acceptance of the connection request in encrypted form (See 5) to the BM nodes for confirmation and consequent addition to the BC. This indicates that the Client may communicate with the Server/Network using an IP (assigned to the Server/Network gateway), encrypted with the Client (kclient)pub, and returned in the connection response. This step is similar to (3), only the response is transacted backwards — from the Txoutput address to the Txinput address.
  7. Client parses the BM blockchain to search for the response and decrypts the response to receive the individual IP assigned to it for connection with the Destination S/HVN.
  8. Client and S/HVN communicate using the IP allocated for the connection by Brazilian Mango. In-transit communications can be encrypted using standard and commonly accepted methods to secure packets/connection during the session. Routing protocols such as TLS, IPSec, OpenVPN, and SSH, among others can be used to facilitate communication as necessary. These communications, once routing has been facilitated by stages (1) through (7) take place independent of BM as destinations have now been identified to the Client and the S/HVN, and both parties are made aware of where to route their secure sessions.
    • At this stage, BM has now fulfilled two separate functions: first, it has securely helped coordinate potential connections, and second, it has replaced conventional authentication servers that are used in extremely-secure implementations.


A Note on Path Vectoring and Associated Protocols

Before I approach the analysis of the above process, I want to touch on the relationship of BM to current routing protocols. Brazilian Mango works predominantly at the application layer, and it’s merely a way of announcing and coordinating connections rather than facilitating them. This idea is not meant as a protocol to replace current path vectoring options like BGP or OSPF (among others) because it simply informs clients of which IPs they need to eventually route to.  Instead, BM acts as a hybrid tool that complements current path vectoring. BM also ensures that routes that are authenticatable and ensured to be secure as the address is only known by the respective endpoints. Once IP information is exchanged by BM Steps (5 – 6), then protocols such as BGP, OSPF, among other link state routing protocols can take over to facilitate the connections.

That being said, Brazilian Mango is not meant to be a replacement for DNS either. The amount of applications that take place by DNS far outnumber the amount of potential applications that are composite to BM. This is specifically due to the fact that Brazilian Mango is a slow way of connecting secure S/HVNs with their users rather than a quick way of connecting users to both secure and non-secure destinations.


This concept is certainly in its infancy. One notable drawback is the lengthy period of time in which it would take to make a request for a connection, have the destination S/HVN authenticate it, and open up the gateway for the Client to communicate with the S/HVN. Even with a block confirmation time of less than 60 seconds, this is still far slower than most other alternatives to remotely accessing a secure network (for example, just using a conventional VPN). Obviously this means that if it were to move past being a theoretical and onto the design and implementation stages, the service would be best for secure connections that don’t need to be immediately resolved but need to remain secure and whose existence would benefit from some secrecy and obscurity.

On the other hand, there are quite a few benefits to this method of connection. Rather than remaining operational and waiting for connections to resolve, thus leaving oneself open as a target, connections can be specifically tailored depending upon what the users and the network need.

Further, using a blockchain-backed access request log provides a concretely secure audit trail of connections (and alternatively, attacks). If something like Brazilian Mango existed and were maintained agency-wide, company-wide, and/or organizationally (or, less likely though even more compelling, industrially) it would be pretty hard to lose faith in logged access history since it would be maintained by so many different nodes.

Additionally, this type of blockchain does not suffer from the same issues as other BCs, such as those used for cryptocurrencies. Brazilian Mango is not hindered by size limitations and scalability issues because BM doesn’t have to maintain records of all unspent Txoutputs. There is little likelihood that networks that use BM will need to keep IPs in a resolvable yet unconnected state for Clients a far time into the future. In these particular instances, the Clients can simply make a new request. After a certain period of time where a S/HVN approves a connection request that remains unfulfilled by a Client, it is advisable for the S/HVN to invalidate the unique IP from (5) above for security reasons. As such, the size of the Brazilian Mango BC only needs to be as large (and records need to be kept only as long) as the number of open sessions. Once the oldest open or authenticatable session expires, BM can dispose of any blocks prior and up to the block height where all connections are expired. Though, notably, some S/HVNs may keep the entire BC to ensure a sufficient audit trail of connections.

Finally, and most importantly, Brazilian Mango provides a new way of approaching access that doesn’t explicitly require cross pollination between systems. Put another way, requests for connections are abstracted from devices, and there isn’t a direct exchange between the connection requester (the Client), and the connection permitter (the Destination S/HVN). All of the data indicating how to facilitate communication is housed on a blockchain, in a size-enforced and encrypted set of request/response pairs. In short, there is very little likelihood that anything malicious would be passed along this venue that could potentially harm the Destination S/HVN before a secure connection could be established — unlike if an infected or malicious computer were to request access directly from an authentication server. Tackling this from an analogous perspective again, this is largely due to the fact that BM acts mainly as a town square where salesmen can yell to a large crowd that there is something for sale for particular individuals. However, these interested people don’t need to identified in the crowd to the salesmen for the message to be effective, and they don’t need to directly converse with the salesmen.

If you have feedback on this idea, I’d love to hear it! I can be reached via


Featured Image Credit: Mark Hillary, “Mangas”. Creative Commons Attribution 2.0 Generic. Modified, Desaturated.

Secondary Image Credit: Germán Poo-Caamaño, “Almendra y su curiosidad”. Creative Commons Attribution 2.0 Generic. Modified, Desaturated.

Diagram Clipart:

SHA256( fd6d0199cf917d79eb52ab6fb78c52ce1c031240a5af1a5597d9320f7d52a366


Authenticity > Identity



I attended a dinner last night where the principal topics of conversation were cyber risk and cyber risk metrics that evaluate one’s own cyber impact relative to the rest of the global ecosystem.

One of the questions presented was, in paraphrase, “what is the biggest cyber threat that exists today”? I was expecting the usual trite response. I anticipated ‘advanced cyber weapons’, ‘APTs’, ‘hacks by nation states’, ‘metamorphic malware’, ‘information leakages’, or ‘organized hacking collectives’, and was caught off guard by the answer proposed: spam. I recognize there is a possibility that my MPA in International Security Policy has just made me a bit too security-inclined.

Out of the plethora of choices, spam was considered to be one of the biggest cyber threats today as it adds clutter to an already noisy environment. I would wager that this threat is considered dangerous less due to its [relatively minimal] propensity for tangible damage and more due to its innocuous state. Expectation and familiarity of conventional cyber threats causes a relative downplay of the real issues that spam causes. A significant amount of people expect a hack from Russia (and anticipate the ability of the United States to respond proportionally), but so many people expect to receive spam that they’re deadened to the reality of it.

The answer, “spam” was so shocking to me that I was curious if there was a better approach to eradicating it then we’ve seen previously. That made me think about blockchain solutions to the problem. Obviously I don’t purport my idea to be better than the rest (especially since alternatives have been tried for decades), but I do think it’s time for a shift in the status quo. Perhaps attacking the issue foundationally would be more effective than tackling it defensively.

What if you could cut through the noise caused by spam not by attacking the issue itself, but by redefining the landscape in which it exists? I think this solution manages to address this transformation.


This is a transformational paradigm shift. If emphasis and value is placed on the items themselves (in this case, email communications), rather than on where they’re coming from, then it’s possible to unburden ourselves from spam.

Perhaps now would be an appropriate time for a disclaimer. Friends and colleagues know me as “that blockchain guy”. Admittedly a lot, if not an excessive amount, of my technical conversations manage to involve blockchains and/or cryptocurrency in some form or another. However, I do greatly enjoy thinking about the world’s problems in terms of these innovations. They’re robust, exceptionally dynamic, and groundbreakingly tailorable.

Getting back to the spam issue, let’s consider a solution to this problem by taking origin and identity out of the equation. This can be achieved by a concept that I’ve codenamed Slate Hawkeye (I give codenames to my own inventions simply so that they’re easier for me to reference in the future).

Slate Hawkeye works by maintaining a blockchain of the hashed contents of emails that are submitted by users (or via their mail clients). End user clients, mail servers, and recipient systems can be setup to only approve emails that match a particular hash, pattern, or those that are transacted on (read: submitted to) the blockchain by a certain k_priv. Spammers or malicious users are disincentivized by utilizing this system as it would be too resource heavy to submit hashes to the blockchain for large numbers of recipients, and it would be too costly from a resource standpoint to justify the transactional costs.

As with most of my work, I think this is explained better visually – please see the following diagram.


In this concept, authenticity comes from access control. Those that have the ability to transact on the blockchain, or in another usage, those that are willing to expend the resources to transact on the blockchain are the ones that have the ability to communicate. In the above example, the ability to do (3) can be done via a secure web app (a user requests access to be able to send a message). Alternatively, (3) can be built into an internal network, thus ensuring that only trusted machines are able to send messages (this would work well for incredibly secure networks where the ability to guard against spoofing is crucial). In either instance, this places the value of a message on the authentication stage rather than where it came from. This authentication medium is made possible by a multitude of factors, such as access management, and supported by expensive, and irrevocable or nearly irrevocable access.

One important issue to note is that this would be a lot slower than email as it is presently situated and would also be more computationally intensive – because of the need for the emails to be hashed. The hashes at least maintain anonymity of senders and security of the message as it’s not posted as plaintext, but it requires the client to hash the contents of the message, transact it along the decentralized ledger, and also requires the recipient to verify that the hash of the email they received is the same as the hash as submitted to the rest of the network via the blockchain.

Although there have been many other designs and implementations for blockchain-backed communications systems this is the first that both addresses the trust issue and the opportunity to counter nefarious adaptations of current systems. Perhaps the best implementation only exists in circumstances where authenticity of the message is imperative or security of the communications infrastructure has to be ensured. Since this is just a preliminary concept, I haven’t thought exhaustively about which hash functions would be the most appropriate for this adaptation, but I think that this would be a fun side project in the future.


Featured Image Credit: Markus Spiske, “Nosy People”.

Secondary Image Credit: Netflix, House of Cards.

Diagram Clipart:

SHA256( 4986561ae2145093a3c7aa588b9d88f0ff1d51c1467a2ca13ec0f99107a7e8aa