Earlier this week I heard about a new startup called Bitcasa which is offering “infinite” secure cloud storage for a low monthly fee. Now, I’m not particularly interested in relying on a brand-new startup for all of my off-site storage needs, but one of Bitcasa’s technical claims seems to have raised a few eyebrows on the Internet. In particular, I learned from an episode of the podcast Security Now that Bitcasa claims to use exclusively client-side encryption and also to be able to de-duplicate files server-side.

Think about that for a moment, and it may at first seem impossible. How can you de-duplicate plaintext that the server never has access to? But it’s not impossible, and I wouldn’t doubt that many ways of doing this are widely known, but I did find it to be a really interesting computer science brainteaser. Here’s the problem, in my words:

Design a service that allows users to store blocks of data and retrieve them later. The service must have the following properties:

  1. No block is stored more than once.
  2. No more than O(1) additional space is used per user who “owns” a particular block.
  3. No user is able to decrypt a block that he does not own.
  4. The service could not be compelled by any authority to decrypt the blocks it stores.

Extra Credit:

  1. No communication between users, directly or through the service, is required.
  2. The service could not be compelled by any authority to divulge which users own which blocks.

In the Security Now episode in question, the host gave a solution which satisfied 1-4, but not 5 or 6, so I have labelled them as extra credit. If you want to try solving this problem yourself, stop reading now — my solution follows.
Continue reading

The recent launch of two-factor authentication for Google accounts inspired me to re-evaluate and improve the security of the numerous accounts I’ve accumulated in my time on the Internet.

I’ve always been cognizant of good password practices. Even my very first password on AOL in 1994, while it was rooted in a dictionary word, at least had numbers at the end of it. I’ve never been so blithe as to use “password” as a password, or use things like names and dates. All of my passwords today are what most would consider “strong” passwords — composed of letters of varying case, along with numbers, and not incorporating any dictionary words. However, my password practices could still stand to use some improvement.

Continue reading

Update 11 July 2010: The move was a lot more painless than I had anticipated, and is already done. If you’re reading this, then your DNS has updated and you are accessing the new server. Hooray! See below about user accounts if you missed the original announcement.

Sometime later this month, Nerdland will be moving. The content and URL of the site won’t change; only the hosting provider will. The new host will be a Rackspace Cloud Server. This probably doesn’t affect you directly unless you are one of the people to whom I gave a Nerdland “user account” with web hosting space and e-mail over the past eleven years. If you are one of those people, please read the next few paragraphs.

As part of the move, I’m going to take the opportunity to clean out a lot of cruft that’s been building up on the Nerdland server over the past half-decade since the last hosting change. Most of the user accounts that I provided for friends and relatives aren’t being used anymore, and aren’t linked from anywhere on the Internet, so there’s no reason to migrate them. Rest assured, nothing will be permanently deleted. I’m an incorrigible data pack-rat, so I’m of course going to archive and back-up everything, including what I don’t move to the new server. If you had data stored on Nerdland, you can always contact me in the future, and I will gladly send you a copy of your old files and unretrieved e-mail, or restore your data and account to the server.

Continue reading