Loom Security
I introduced the Loom.cc electronic accounting system on Monday. Since then, I talked extensively with it's creator, Patrick Chkoreff. He gave me a link to the source, and I got it working in a Linux virtual machine on my Mac (I wasn't able to install one of the Perl libraries it needs in Mac OS X). It took me a little while to figure out how to bootstrap the first folder, the one that owns the usage tokens, but I found a comment in the code that pointed me in the right direction. I made a suggestion to Patrick to make this easier in the future, and I think he'll probably do it. I'm running v58 of the software, which is an older version than the one that is currently running at Loom.cc. Mine is missing the "CMS".
The Loom Grid Help page gives a good overview of the logical implementation of the grid. But there are a few details of that representation that have important ramifications for the security of your assets in the system.
You still have to trust that Patrick's code does what he says it does, i.e. that Loom.cc is really running the code that he distributes, and you have to trust that he's using a secure web host. The latter seems pretty likely since "whois loom.cc" says that the nameservers are ns1.rayservers.com and ns2.rayservers.com, and rayservers.com's web page says that they specialize in security, availability, and high bandwidth. Only time and experience will tell how trustworthy Patrick is with our assets.
One of the first things I wondered about the security of the Loom.cc database is how much information someone who got access to a raw database files would be able to extract from it. Turns out that not much can be gleaned, but possibly more than ideal.
The database itself is currently implemented using GNU gdbm, a persistent hashtable mechanism that is part of most Linux distributions. The keys and data in this can be any string of bytes. It's quick and mature. Loom's interface to gdbm is centralized and very simple, so replacing it with another persistent hash-table mechanism wouldn't be hard.
The loom database is used to store two types of data, the grid of asset values and what Patrick calls the archive. In the source code I have, the archive is used only for storing your folder information, your name, the assets you know about and their names, and the locations you know about and their names. In the current development code, the archive enables a complete, secure Content Management System (CMS).
Except for the initialization of an asset, which stores -1 in the issuer location, changes to the grid are always done in pairs, subtracting the transferred amount from the source location and adding it to the destination location. The database key for a location is the concatenation of the asset id and and the SHA256 hash of the location. The value is the raw integer number of asset tokens, which is formatted for display according to how you configure the "Scale" and "Min Precision" on the "Edit Asset Type" web page. This allows identification of the values and raw integer asset IDs from a database dump, but no idea of the locations themselves. A knowledgable person could, however, recognize values for assets that they care about, and change the database to transfer assets from unknown locations to locations that they know, "stealing" assets from unknown Loom users. The advantage of the current scheme is that it enables auditing of the assets to make sure all the numbers add to -1. It might be better from a security standpoint, however, to hash the concatenated asset ID and location as the datbase key, and, possibly, encrypt the values, using the raw location as the encryption key, as is done in the archive.
Encrypting and storing the concatenation of the value and its hash would allow validation of a users's assets at login time, for a doubling of the value storage space.
The archive, where your folder information is stored, and where the CMS is stored (I think), is much more secure. The database key is the SHA256 hash of the location ID. The value is AES encrypted with the raw location. So, though you can see the hashes in the database, you need to know the unhashed locations to decrypt the data. The folder location ID is a hash of the login passphrase. The folder information is encoded as a text string in KV format, as printed when you fill in the text areas and click one of the buttons on the Loom Grid Tutorial page.
Previous Posts:
Forty Second Boyd and the Big Picture
2008 Presidential Endorsement
Remington to Acquire Marlin Firearms
Marlin's New XL7 Bolt Action Rifle
Extradition Hearing To Begin January 21
Quote
New Bush Coins
Loom Electronic Accounting System
Money as Debt
Airport profilers: They're watching your expressions
Patrick added encryption
Patrick added encryption to the database storage, with a simpler mechanism than I proposed. Works good for me. Don't know if it makes sense to make it the default. Some operators will prefer to have an auditable database.
I also checked the random number generator that is used by the "Random" buttons in the interface. They all go through one random number module, which uses /dev/urandom. It's cryptographically secure, though not quite as truly random as /dev/random, but /dev/random can block while it collects entropy, which is not good for web server responsiveness.
Edit comment