: Frequently Asked Questions: Frequently Asked QuestionsOctavia E. Butler was a groundbreaking author of science fiction and other novels notable for their complex and nuanced perspectives on race, power, and gender; at the same time, she inspired people with her magnificent imagination. Butler achieved all this in short but dense stories that reward multiple readings.
Future Octavia clients will keep track of a configurable number of directory descriptor versions, enabling a feature like FreeBSD/NetApp/Plan 9 “snapshots”: old versions of your files will still be available in a .snapshot directory. Since the directories and files are stored on many servers, including old versions, that may be good enough for you as a recoverable backup system.
If that is not good enough for you, you will still be able to use whatever other backup system you prefer along with your Octavia filesystem.
Unix UIDs/GIDs and NT SIDs are local concepts, valid no more widely than a single domain (e.g. an Active Directory or LDAP domain). Even on such a small scale, these domain management systems are not known for security. Octavia is a secure internet filesystem, and so implements access control in the only way that scales globally: cryptography.
Each directory has a distinct encryption key, which the client uses to encrypt the files and directory descriptors contained within. Thus, the directory subtree is the unit of read access sharing. Each client has symmetric signing key relationships with one or more servers, allowing that client the ability to write blocks to the server. It’s up to the client to organize those blocks into files and directories, including possibly new versions (“forks”) of directory subtrees shared from another client.
The server has no notion of files or directories, only blocks of ciphertext, and thus cannot enforce any permission other than block writes, and rate-limiting block reads by IP address.
No. Each write is a new, independent version (fork) of the original file or directory. Octavia files and directories are purely functional (or persistent) trees (see Okasaki).
Even a true Octavia client in your OS kernel is probably not going to support memory-mapped I/O (such as with the mmap(2) or MapViewOfFile system calls) particularly efficiently.
The lack of file or region locking and efficient mapped I/O make Octavia a bad choice for storing database files. In that regard, Octavia is no worse or better than existing network filesystems like CIFS and NFS.
Other cryptographic network protocols like TLS and SSH include nifty mechanisms allowing clients and servers to negotiate security parameters such as cipher algorithm, block cipher mode, key exchange protocol, and integrity protection algorithm. This is a great idea because cryptographic functions have a disturbing tendency to be exposed as broken over time (for example, DES and MD5). Making the protocol flexible allows deployers and developers to configure new, hopefully-safer security parameters.
However, the flexibility comes at the high cost of increased protocol and code complexity. Complexity is a leading cause of bugs, including security vulnerabilities. (See Ferguson and Schneier, section 1.2 “The Evils of Features”.) SSL version 2, for example, had a security downgrade vulnerability in its negotiation (see Wagner and Schneier). Similarly, SSH endpoints supporting both SSH 1 and 2 can be downgraded by an active network attacker (see Click Death Squad; note that the Squad specifies that the attacker have a cold beer on hand but that tawny port works just as well).
The increased complexity manifests as increased cognitive load for users — in order to make the right choice, people have to understand the problem and the options. To expect normal people to make the right choice between SHA-1, Tiger, and Whirlpool is unrealistic and plainly silly.
Additionally, for people to deploy a new, more secure cipher, they have to get a new version of the application supporting the new cipher. (If they had the good cipher in their old version, why would they choose to use the bad cipher?) Thus, people have to wait for a safe upgrade in any case.
This leaves compatibility with non-upgraded peers as a key reason to make the protocol flexible. But why would we want to converse with known-vulnerable peers? How would we avoid downgrade attacks?
Instead, Octavia ties security functions tightly to the protocol version. Each protocol version uses believed-strong security functions; for example, version 0 uses AES-128-CBC, SHA-256, and HMAC-SHA-256. As far as we know in late 2009, these functions provide something close to 128-bit security, which even if slightly weakened should be sufficient for the medium-term future (see Ferguson and Schneier, section 3.7 “Security Level”).
If someone finds a weakness in one of these functions and/or in the Octavia protocol itself, we will develop a new protocol version and implementation(s) to address the problem(s). Particular client and server implementations can provide more or less configuration flexibility, and deployers can deploy the implementations and versions they feel comfortable with.
Octavia makes no attempt to defeat traffic analysis attacks. This is unfortunate, because traffic analysis is a powerful attack technique. It is also incredibly difficult to defend against.
While there is a beautiful system designed to defend against traffic analysis, Tor, at this time Tor can only work with TCP streams. Octavia uses UDP datagrams for all its transport.
Sorry about that.
It is possible that Tor may support UDP or even IP someday (see this message from Nick Mathewson and this Tor FAQ entry), but it’s not going to be easy.
