3 ms·

I've been looking for a good truecrypt replacement, but this unfortunately isn't it (yet at least). 1) Closed source. I can't take security software seriously

by TheDong 12y ago

I've been looking for a good truecrypt replacement, but this unfortunately isn't it (yet at least). 1) Closed source. I can't take security software seriously without the source code. 2) Windows only. Ditto for the above 3) There's no point in encrypting a folder with N files to result in N encrypted files. It's always more cryptographically sane to create a large block of data (as truecrypt did) rather than reveal information about how many inputs there were and allow people to correlate them. Those three issues mean I won't be using this (especially the open source bit).

mcdoug 12y ago
Exactly what I was going to say with 1 & 2. Your point #3 is arguable. It's more secure to encrypt a block than files, but it's not always nearly as convenient. You wouldn't want to sync a multi GB block to S3 every time it changes. You have to encrypt filenames, and pad the files, but file-level encryption has its uses.
- ryan-c 12y ago
  Knowing the approximate file sizes and number of files in a directory, especially with further context of overall directory structure can allow someone to guess what the content is with high probability if the files are "well known". Consider a directory containing pirated episodes of a tv show, organized with a subdirectory per season. "Scene releases" tend to have one a few possible approximate file sizes, and depending on how much padding, it may be enough information to identify a set of files as all being scene releases of the same show. Many other examples like this - anything "popular" that's will have a fingerprint of extracted file sizes.
  - StavrosK 12y ago
    Block encryption methods like XTS have their fair share of problems too: http://sockpuppet.org/blog/2014/04/30/you-dont-want-xts/ http://sockpuppet.org/blog/2014/04/30/you-dont-want-xts/
  - EmanueleAina 12y ago
    You can also encrypt N files yielding M > N blocks, to avoid much of the issues you described while still avoiding the one-large-blob concern.
    - ryan-c 12y ago
      M - N must be "large enough" and must be unpredictable, though. It might need to be pretty big.

by TheDong 12y ago

mcdoug 12y ago

Exactly what I was going to say with 1 & 2. Your point #3 is arguable. It's more secure to encrypt a block than files, but it's not always nearly as convenient. You wouldn't want to sync a multi GB block to S3 every time it changes. You have to encrypt filenames, and pad the files, but file-level encryption has its uses.

ryan-c 12y ago
Knowing the approximate file sizes and number of files in a directory, especially with further context of overall directory structure can allow someone to guess what the content is with high probability if the files are "well known". Consider a directory containing pirated episodes of a tv show, organized with a subdirectory per season. "Scene releases" tend to have one a few possible approximate file sizes, and depending on how much padding, it may be enough information to identify a set of files as all being scene releases of the same show. Many other examples like this - anything "popular" that's will have a fingerprint of extracted file sizes.
- StavrosK 12y ago
  Block encryption methods like XTS have their fair share of problems too: http://sockpuppet.org/blog/2014/04/30/you-dont-want-xts/ http://sockpuppet.org/blog/2014/04/30/you-dont-want-xts/
- EmanueleAina 12y ago
  You can also encrypt N files yielding M > N blocks, to avoid much of the issues you described while still avoiding the one-large-blob concern.
  - ryan-c 12y ago
    M - N must be "large enough" and must be unpredictable, though. It might need to be pretty big.