I'm going to increase this to 256, so I can intentionally fragment the filesystem before putting down the data. Then, when formatting with ext2, I'll only get a total of 64 inodes, which means a total of 64 files. So, I chose the minimum according to mdadm(8), which is 4KB. 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. I can now create the RAID array, format it wxth ext2, and mount it. Lrwxrwxrwx 1 root root 7 Nov 29 07:47 /dev/mapper/aes-crypt-2 ->. Lrwxrwxrwx 1 root root 7 Nov 29 07:47 /dev/mapper/aes-crypt-1 ->. $ sudo cryptsetup create aes-crypt-2 /dev/loop2
$ sudo cryptsetup create aes-crypt-1 /dev/loop1 If I create the RAID array first, the two files will reveal information that they belong to an array. NAME SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILEīecause I want plausible deniability, I'll use cryptsetup(8) first, _then_ create the RAID array.
$ dd if=/dev/urandom of=~/file2 bs=256k count=1 $ dd if=/dev/urandom of=~/file1 bs=256k count=1 This is critical, so no metadata, including encryption boundaries, is leaked: Notice that I'm building the files from /dev/urandom. I'll setup some files with dd(1), then add them to loopback devices. So, instead, I'll use the 'dm-crypt' module with the cryptsetup(8).įirst, I need my block devices. But then I thought that it's not a good fit, because I lose plausible deniability. Initially, I figured GnuPG would work for this. So, they need to be encrypted, then converted into base64 before sending to the address. However, the messages will likely be decrypted at the other end, and will very likely be stored unencrypted. Then you can chop up the file into multiple messages. 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. Intrigued, I started thinking about this. The random blurb ensures the server always hears you." 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. When sending the LIST command, type some random blurb into the message. REMOVE - Removes a file saved to your account. e.g "UPDATE a567f My even more top secret file" The new_file_name is optional and is only used to rename your file.
#Bitmessage file size limit update
UPDATE - Update an existing file saved to your account. e.g "NEW my top secret file", put the contents of your file into the message body. LIST - Lists all the files you currently have saved to your account. You are authenticated via the address you send from, so be sure to keep it safe. "You send commands to the service via messages, the message subject is used to tell the server what you want to do. When you send 'help' to the address, you get the following information: No doubt should you call into question a faceless storage provider, but I thought I would play around with it. For instructions please send a message to BM-2cUqBbiJhTCQsTeocfocNP5WCRcH28saPU with the subject 'help'." While hanging out on the "privacy" channel on Bitmessage, someone sent the following:
0 kommentar(er)
