Yesterday Bitcrypt, another attempt at innovation using the blockchain, was announced in a small Reddit thread. The idea is that you can write encrypted messages to owners of Bitcoin addresses. A tipster indicated that the author of this tool is credible, so I was dispatched to investigate further.
The code for Bitcrypt is itself just 104 lines of Python with a deep dependency on Jeeq, a 500 line Python script that concentrates on using ECDSA, the Elliptical Curve Digital Signature Algorithm, in a novel fashion.
As this is a brand new piece of code, the commenters on Reddit immediately found things to dislike. The chief complaints were the use of Python’s built in random number generator and the untested nature of the overall encryption process.
All encryption depends on having a good source of entropy to fuel the random number generation process. The developer selected Python’s random library, which is deemed suitable for statistical applications and the like, but the documentation for it contains this specific prohibition:
“However, being completely deterministic, it is not suitable for all purposes, and is completely unsuitable for cryptographic purposes.”
The library’s documentation suggests the use of os.urandom as a source for cryptographically secure random number generation. This is provided on unix systems via the /dev/urandom device, which collects ‘noise’ produced by CPU interrupts, network traffic, and use of the mouse/keyboard in order to randomize its output.
Systems that will bear more encrypted traffic than a general purpose CPU can support can be enhanced with the addition of a cryptographic accelerator such as those produced by Exar, which bundle encryption, data compression, and a hardware random number generator.
This is an easily corrected issue, and its presence is a hint to how Barisser views this effort.
The other complaint commenters voiced was the unclear nature of the application of methods.
Cryptography isn’t a black box, it’s a construction kit. There are public key exchange methods, secure hashes, and stream encryption ciphers. If your key exchange method is flawed, the toughest cipher available is worthless. If you perfect your key exchange your communication startup is fine, but if it’s followed with a weak cipher, you have again created a hazard rather than a solution.
Many of the problems mentioned in conjunction with cryptography are not faults in the algorithms, but instead they are errors on the part of the developer who selected them. A prime example of this is OpenSSL’s Heartbleed bug. The fix for it was preventing the implementation from leaking random bits of previously used memory, rather than any changes to cryptographic methods.
Those who responded did not suggest that they had already seen some fatal flaw, they were simply pointing out that any purported innovation like this needs more sets of eyes on it than just the hopeful creator.
The author, Andrew Barriser, has appeared on CCN.com before, defending the use of the Bitcoin blockchain rather than alternatives such as Counterparty; this level of expertise and engagement is part of the reason he is counted as credible. He made his intent clear in the first line of the post:
Check out this bit of code I whipped together.
The Bitcrypt code is operational, but it’s clearly intended as a proof of concept rather than something to be put into production. The reader complaints are technically correct, but they should not be read as discrediting the effort Barisser has made. He may choose to release an update that corrects the obvious problem with the random number generator, or he may simply choose to let the code sit and track where the concept goes from his initial post.
What do you think of the Bitcrypt idea and preliminary implementation? Comment below!
Images from Shutterstock.
Last modified: June 10, 2020 4:07 PM UTC