simple, safe, secure resizeable archive with hidden metadata
Switch branches/tags
Nothing to show
Clone or download
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

- 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.

- 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?

- 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.

- could make a fuse wrapper for convenience?
- kerberos integration for password-reuse?

- 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..?)