This is a log from some idiot who participated in Status.im hackathon.
They did some brainstorming. A said let's make a todo list. B said sounds reasonable. The data would have to be stored in a decentralized file storage solution, like StorJ, or IPFS. Good enough. But then, what good is a todo-list, when paper is already good enough? And even then, B wished to learn more about DApp, and they suggested to move on to the next light.
B posted a list of winning hackathon ideas that he scraped from a hackathon website. But none of them were suited for DApp.
DApp refers to decentralized application. A decentralized app should be server-less. It must be powered by no other than those who consume the application itself. However, not all consumer wishes to be worker, and thus the blockchain derives a new job, miner, those whose job is to spare their power to keep the DApp running.
Had decentralization came faster, we might have called it the cloud. Ironically, the ugliest cloud, are those gray heavy blob of rain drops. The most beautiful however, are of the Mackerel sky.
How about, a decentralized 2FA service?
A's quite skeptical, for he has yet to dabble with the space. On the other hand, B is also not very far from the starting position.
They first started with Parity, probably the best ETH wallet implementation out in the market, for it was written in Rust, the language that nullified null. They look into the Kovan test net, go to the faucet gitter, and request some test ETH. All went extremely well.
Then, they discovered the DApp tutorial written by none other than Gavin Wood, the founder of ETH: https://github.com/paritytech/parity/wiki/Dapp-Tutorial
Going through them was a breeze, for B was a strong Node x React developer.
Now that they have to derive a game plan, the first thing to do, was a little bit of research. Has anyone done this before?
Decentralized Multi-factor Authentication yielded 1 prominent result: http://bitcoinauthenticator.org/
However, from the sample implementation, it is clear this solution requires a centralized server to validate the bitcoin token. The search continues...
Decentralized 2FA yields some promising results: https://lzf.com/PSKey/
From the technical writing to the video demo, all indicates that PSKey is a legit product. However, all news coverage about the company behind it died down by the mid of 2016. Furthermore, no working implementation of PSKey were found, thus leaving A and B more speculation than insight.
From these result, it seems like a decentralized 2FA wouldn't be too bad of an idea. And thus they set sail for the implementation. B spends the next morning deriving a flow diagram for how such a system could look like. The 2nd draft diagram looks like the following:
The assumption is that, as long as the token were generated from two trusted source, one of which belongs to the user (the phone client), then the Auth flow is complete.
The most difficult piece of all, is the Generator Contract. It must complies with the hash implementation coming from the mobile client. The mobile client of choice is the Google Authenticator: https://en.wikipedia.org/wiki/Google_Authenticator
They soon found out the most disturbing flaw...
This is the algorithm in pseudo code:
function GoogleAuthenticatorCode(string secret)
key := base32decode(secret)
message := counter encoded on 8 bytes
hash := HMAC-SHA1(key, message)
offset := last nibble of hash
truncatedHash := hash[offset..offset+3] //4 bytes starting at the offset
Set the first bit of truncatedHash to zero //remove the most significant bit
code := truncatedHash mod 1000000
pad code with 0 until length of code is 6
return code
After spending half an hour of researching the algorithm and the way to implement it in Solidity, B found out that there is a need to generate a HMAC-SHA1 hash of the message. However, SHA1 is not natively supported by EVM (Ethereum Virtual Machine). There is a SHA1 contract floating around on gist: https://gist.github.com/D-Nice/43d60515263f9854bd92e952dfc0dea5
Fairly optimized per the generous author, this contract however remains very costly to run. According to his last comment in his proposal to add SHA1 natively into EVM (https://github.com/ethereum/EIPs/issues/180), a 2kb message would cost 8.5M gas, which come down to 0.153ETH, or around $36. This is for a single request with a payload of 2000 characters.
In perspective, the same job can be done in AWS Lamdba for $0.0000002. To be generous, let's say they would need to run 5 consecutive Lambda job, which total $0.000001.
In ratio, running on the decentralized Ethereum cost 36,000,000 times more than running on a cold server.
Now, 2kb messages seems like the extreme end of the usage. Seems like the original author was trying to validate HTML data. What if the payload contains only the necessary data for the job?
According to the analysis in the github issue, hashing 55 bytes or 55 characters cost around 300k gas, that's around $0.01 per character. A HMAC_SHA1 hash is 20 bytes. To round the number, let's say we are quite generous and willing to let our user use a secret that, after adding the hash total 50 bytes or 50 ASCII characters. This would cost around $0.5 per request.
$0.5 request versus $0.000001
that's still 500,000 times more expensive... Which is quite fascinating in term of number. Only time will tell if this ratio would go down.
Now, compare this to Azure's 2FA pricing:
$1.40 per 10 authentications, that's $0.14 per request. Well, now Ethereum is looking more promising. Only ~4 times more expensive than a dedicated service!
Then compare this to Duo's 2FA pricing:
$9 / User / Month
Let's say the average user login once everyday, that's $0.3 per request. Here's the comprehensive list:
ETH Contract: $0.5
AWS Lambda: $0.000001
Azure : $0.14
Duo : $0.3
The contract has a long way to go toward a dedicated farm like AWS Lambda, but in term of its 2FA authenticator, and for a specific use case, not bad at all! It is, actually, not bad at all comparing to the dedicated 2FA authenticator!!!
But then... SHA1? B said. Who would want to use a service that relies on such an obsolete algorithm for hashing???
B tried to look for an authenticator that would use SHA3 or SHA256 instead, as those are the algorithm natively supported by the EVM, but... to no avail.
C joined the party...
They searched briefly for "decentralized file sharing"
An insight: It seems people associates "decentralized" with "being able to upload their data into dropbox or their cloud"
Ironically, it is not their cloud... even if it was, that cloud would be a pain to own by themselves, for it is a huge, rainy cloud. It is the opposite, of "decentralized"...
They decided to move on...