Join GitHub today
GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
Fetching latest commit…
Cannot retrieve the latest commit at this time.
|Failed to load latest commit information.|
cryptogether currently works for me but is experimental and could change in the future. cryptogether allows you to store several secret files in a resizable archive with a single key. it aims to be a safe and simple, but sufficient for most personal file hiding. the total size of the archive is not hidden (but could be by adding a large blank file to the archive). the number of files, the individual file sizes, and the filenames are hidden. (more hidden depending on the padding of the index file: if you don't pad your index file and an adversary knows that and knows the size of this file, they probably know one particular linear combination of [sum of filename lengths] and [number of files].) note that if you want to move a file from unencrypted media to a cryptogether archive, you should add the file to the archive and then use a program like "wipe" to (hopefully) irrecovably remove the original from the original media. "rm" typically leaves the original data intact. initial version limitations: - note that currently storing each file of size less than 10MB uses 10MB (tail-combining is not yet implemented). - no padding of index file limitations: - cryptogether performs no compression. files can be compressed before they are put in the archive. - file permissions are not remembered. the goal of cryptogether is to be a safe and simple way to store personal secret data without the advanced configuration and more extreme information-hiding possible with a block device or such. it is not intended for scenarios where multi-user info tracking is necessary. - cryptogether won't store empty directories. alternatives: - archive which supports non-compressed encryption (like 7z): - more prone to full-archive corruption during crash? - i was _adding_ a large file to a large archive with 7z and the process died in the middle and the entire archive was corrupted. - a design goal of cryptogether is to minimize the chance of full-archive corruption (while preserving metadata secrecy). - more prone to full-archive corruption? - cryptogether simply places the encrypted files one after the other in the encrypted data file. a single byte error in that file will only corrupt a single file in the archive. - it is true that a single byte error in the encrypted index file will corrupt the entire archive. however, this file is smaller and can be backed-up more easily. - EncFS: - individual file sizes are exposed - use an encrypted block device: - resizing is a dangerous hassle? - encrypt a tar file: - you have to decrypt the entire file each time? - tar has slow seeking, but that's is fine for many cases? architecture: - one file for encrypted index. this file contains a map; for each filename, we have the list of data chunks making up the file data. - one set of encrypted data main chunks. each chunk is 10MB. each chunk is from only one file. - one set of encrypted data tails. not implemented currently. future: - could make a fuse wrapper for convenience? - kerberos integration for password-reuse? notes: - extracting large files takes longer than expected? strictness issue? 50M -> add 1.7s, extract 1.1s 1G -> add 17s (ok), extract 33s (a little long..?)