While hanging out on the "privacy" channel on Bitmessage, someone sent the following:
"You have no files saved. For instructions please send a message to BM-2cUqBbiJhTCQsTeocfocNP5WCRcH28saPU with the subject 'help'."
This is actually pretty cool. No doubt should you call into question a faceless storage provider, but I thought I would play around with it. When you send 'help' to the address, you get the following information:
"You send commands to the service via messages, the message subject is used to tell the server what you want to do. You are authenticated via the address you send from, so be sure to keep it safe. Below are the possible commands:
LIST - Lists all the files you currently have saved to your account.
NEW [file_title] - Save a new file to your account. e.g "NEW my top secret file", put the contents of your file into the message body.
UPDATE [file_id] [new_file_name (optional) ] - Update an existing file saved to your account. The new_file_name is optional and is only used to rename your file. e.g "UPDATE a567f My even more top secret file"
REMOVE [file_id] - Removes a file saved to your account. e.g "REMOVE a567f".TOP TIP!!!
When sending the LIST command, type some random blurb into the message. If you send multiple LIST commands to the server in a short period of time the Bitmessage client see's your requests as duplicate messages and ignores them. The random blurb ensures the server always hears you."
Intrigued, I started thinking about this. Due to the limitation of BM sending up to 256KB messages, your file can be no bigger than 256K, unless you setup a striped RAID array. Then you can chop up the file into multiple messages. However, the messages will likely be decrypted at the other end, and will very likely be stored unencrypted. So, they need to be encrypted, then converted into base64 before sending to the address.
Initially, I figured GnuPG would work for this. But then I thought that it's not a good fit, because I lose plausible deniability. So, instead, I'll use the 'dm-crypt' module with the cryptsetup(8).
First, I need my block devices. I'll setup some files with dd(1), then add them to loopback devices. Notice that I'm building the files from /dev/urandom. This is critical, so no metadata, including encryption boundaries, is leaked:
$ dd if=/dev/urandom of=~/file1 bs=256k count=1 $ dd if=/dev/urandom of=~/file2 bs=256k count=1 $ ls -l file? -rw-rw-r-- 1 user user 262144 Nov 29 07:57 file1 -rw-rw-r-- 1 user user 262144 Nov 29 07:57 file2 $ sudo losetup /dev/loop1 ~/file1 $ sudo losetup /dev/loop2 ~/file2 $ losetup -l NAME SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE /dev/loop1 0 0 0 0 /home/user/file1 /dev/loop2 0 0 0 0 /home/user/file2
Because I want plausible deniability, I'll use cryptsetup(8) first, _then_ create the RAID array. If I create the RAID array first, the two files will reveal information that they belong to an array. I don't want any metadata leaked at all.
$ sudo cryptsetup create aes-crypt-1 /dev/loop1 $ sudo cryptsetup create aes-crypt-2 /dev/loop2 $ ls -l /dev/mapper/aes-crypt-? lrwxrwxrwx 1 root root 7 Nov 29 07:47 /dev/mapper/aes-crypt-1 -> ../dm-0 lrwxrwxrwx 1 root root 7 Nov 29 07:47 /dev/mapper/aes-crypt-2 -> ../dm-1
I can now create the RAID array, format it wxth ext2, and mount it. A couple notes: I'll first want to set the RAID chunk size to something low, otherwise I won't be able to put down a filesystem on the block device. So, I chose the minimum according to mdadm(8), which is 4KB. Then, when formatting with ext2, I'll only get a total of 64 inodes, which means a total of 64 files. I'm going to increase this to 256, so I can intentionally fragment the filesystem before putting down the data. I'll explain the reason for the intentional fragmentation in a second.
$ sudo mdadm --create /dev/md0 --level 0 --raid-devices 4 --chunk 4 /dev/mapper/aes-crypt-{1,2}
$ sudo mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Sat Nov 29 07:47:19 2014
Raid Level : raid0
Array Size : 464
Raid Devices : 2
Total Devices : 2
Persistence : Superblock is persistent
Update Time : Sat Nov 29 07:47:19 2014
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
Chunk Size : 4K
Name : example:0 (local to host example)
UUID : 2bca1bf9:3af4a5d1:1989bb34:9b46bb9c
Events : 0
Number Major Minor RaidDevice State
0 253 0 0 active sync /dev/dm-0
1 253 1 1 active sync /dev/dm-1
Now the formatting. Notice I'm changing the number of inodes. Also, we don't need to set aside any space for the root user: It's occupying precious disk space.
$ sudo mkfs.ext2 -N 256 -m 0 /dev/md0 $ sudo mount /dev/md0 /mnt $ ls /mnt lost+found $ df -h /mnt Filesystem Size Used Avail Use% Mounted on /dev/md0 427K 15K 412K 4% /mnt $ df -i /mnt Filesystem Inodes IUsed IFree IUse% Mounted on /dev/md0 256 11 245 5% /mnt
Now before putting data into the filesystem, I'm going to fill it with small files of random data, then remove every n-th file to create enough space to put down my data. This fill force my data to be intentionally fragmented. The reason for this is to avoid a snapshot attack on the files I'll be storing remotely. If I did not fragment the data, then as I update the filesystem, only small incremental changes will take place. This will allow the attack to "subtract" a previous filesystem iteration from the current, allowing them to know where my stored data resides, as well as possibly figuring out what it contains. Because we're talking about a 512 KB filesystem here, even encrypted, disk I/O isn't a concern.
First, how big can each file be at a maximum? It appears to be 1721 bytes.
$ echo '(412*1024)/245' | bc -l # 245 available inodes, 412K available space 1721.99183673469387755102
Next, create the files, each with 1721 bytes:
$ for i in {1..245}; do sudo dd if=/dev/urandom of=/mnt/file$i bs=1721 count=1 2> /dev/null; done
Unfortunately, the filesystem filled up before completion. As such, we have empty files. So, we'll find those and remove them:
$ find /mnt -empty -type f | wc -l 25 $ sudo find /mnt -empty -type f -delete $ ls /mnt/file* | wc -l 204
Now, I'm ready to fragment the filesystem. I know that one file I want to copy is 8820 bytes in size. So I need to free up 6 non-contiguous files. according to my math, I need to free up every 34th file:
$ echo '8820/1721' | bc -l
5.12492736780941313190
$ echo '204/6' | bc -l
34.00000000000000000000
$ sudo rm /mnt/file{$((34*1)),$((34*2)),$((34*3)),$((34*4)),$((34*5)),$((34*6))}
$ df -h /mnt
Filesystem Size Used Avail Use% Mounted on
/dev/md0 427K 415K 12K 98% /mnt
I'm now ready to copy in my 8820-byte file:
$ sudo cp ~/secret-file.txt /mnt $ df -h /mnt Filesystem Size Used Avail Use% Mounted on /dev/md0 427K 424K 3.0K 100% /mnt
Now I can tear everything down:
$ sudo umount /mnt $ sudo mdadm --stop /dev/md0 $ sudo cryptsetup close aes-crypt-1 $ sudo cryptsetup close aes-crypt-2 $ sudo losetup -d /dev/loop1 $ sudo losetup -d /dev/loop2
Now I need to convert my two files to base64, copy, paste, and send the resulting output to BM-2cUqBbiJhTCQsTeocfocNP5WCRcH28saPU. The subject of the first message would be "NEW file1", while the subject of the second message would be "NEW file2". The body of each message would be the base64 output for file1 and file2.
$ base64 file1 | tr -d '\n'; echo yAFtXPy7NgHl5Q0ueJiZgjOlYyrocWaxcvA6CjKF0rNd10sTfNvMCmQrL0cA79oO0 ...(snip) ... $ base64 file2 | tr -d '\n'; echo T3GTNvwiewXnnOHTjITNpukyLz4d8iv8wl/JP0YjY0v5s5euF1qv4WwMv9Ejl9AsNMm5NXoK/hFQK ...(snip)...
Of course, sending 2 messages with 256 KB in size will take some time to calculate the PoW, so be prepared for that (I don't know why the PoW is what it is. It should have been a double SHA256() like Bitcoin. Meh)
When you want to update your files, you wll need to build everything backup, except you won't "create" the RAID array, you'll "assemble" it, and you won't format your filesystem, obviously:
$ sudo losetup /dev/loop1 file1 $ sudo losetup /dev/loop2 file2 $ sudo cryptsetup create aes-crypt-1 /dev/loop1 $ sudo cryptsetup create aes-crypt-2 /dev/loop2 $ sudo mdadm /dev/md0 --assemble /dev/mapper/aes-crypt-1 /dev/mapper/aes-crypt-2 $ sudo mount /dev/md0 /mnt
You'll also need to move your file off the filesystem and rewrite all the random files, before copying the new data on. This is important, because we're trying to prevent a snapshot attack against our encrypted filesystem. So, on every commit to the BM storage service, as best as we can control, every bit on the filesystem needs to be changing.
As the help mentions, sending frequent "LIST" commands can cause your message to be ignored, unless the body of the message includes unique random data for each message sent. So, the "TOP TIP" of sending random data in the body of the message is a good idea. As such, I'll run the following for each "LIST", practically guaranteeing that I'll see a unique string, and the query will succeed:
$ dd if=/dev/urandom bs=2k count=1 2> /dev/null | rhash --sha3-512 - 4b5b19c9a8a61cf724cd710c6fd0c54edb46de2bfa55f2ec9a179a590b808993593d333f95dd6c607e9d366c385037cc0a600d262898e3b4c5be26479d3c962c (stdin)
I'll copy and paste the result into the message body before sending.
I don't know that I'm ready to store sensitive data with it, but I do think it's pretty cool. The 256KB limit for the file size is pretty damning, so this isn't something to use for intense media storage, but instead, mostly for documents, such as password storage, browsing bookmarks, student grades, etc. It works, although it's definitely a niche product for a niche group. I wouldn't expect my wife to use this.
{ 8 } Comments