twocrypt 2

twocrypt provides a crypto tool with a deniable encryption option. twocrypt (2c) is a tool for the ultra-paranoid, providing a traditional crypto, but also an option of deniable (subpoena-proof) encryption. It encrypts one or two files at once. Each file can be recovered with its respective passphrase, but the presence of more than one file cannot be demonstrated, and the presence of this option alone should not be a credible argument for data hiding. 2c2 is a simple symmetric file encryption utility. It comes with an interesting optional feature - it is capable to embed an additional file within an encrypted data. This is done in a way that cannot be detected without knowing the passphrase protecting the "hidden" file, even if the password for the primary file is disclosed. The design is such that the fact of using this method alone does not constitute a credible evidence of data hiding (IANALBMSUTDO). This kind of encryption is also called "subpoena-proof" or "deniable". There is some previous work in this area. There are two popular approaches, one is to throw away the encryption key, but store some information that can be used to recover the key with a considerable computation effort (several years or so). The concept seems to be risky for obvious reasons, and is also impractical if the data has to remain accessible before the projected cracking date. The other approach is to have a number of containers protected with a number of passwords, of which some but not all might be encrypted data (rubberhose does that). I think its needlessly complex, and usually applied to a storage such as a disk drive. As such, 2c would be the first tool to implement this functionality in a reasonable and practical fasion, at least I think so. Whats New in This Release: - It was possible to tell a two-file result from a single-file output, _statistically_. This does not mean the question can be answered for a particular archive, but single-file archives had a tendency to result in a slightly larger file, and if you have a number of 2c-protected files for which the primary password has been obtained, it can be told how you use 2c. The reason for that was slightly broken compressed pad length logic. Severity: medium - As a cryptographic safeguard, the random pad stream now consists of a random, compressed file of a random length, followed by true garbage. This is to mimick second file scenario more closely, so that if the encryption proves weaker than originally thought, and some statistical properties of a stream can be deduced, theres no exposure. Version 1 always used a full-length compressed pad, which was silly in that its not that common to store perfectly-fit secondary files. Severity: hypotetical issue - In v1, random chunk would seldom get compressed, because the compression algorithm resorted to storing uncompressed data if compression would result in output bigger than input. This is not a flaw per se, but defeats a minor safeguard intended to mimick a file that would often be compressible. Now, encryption of all blocks is forced, even though it might be less efficient. Severity: hypotetical issue - Input blocks are now split randomly to avoid placing compression headers and other known structures at constant locations. This is just another arbitrary safeguard for the algorithm. Severity: hypotetical issue - per Jamess suggestion, I added a counter to the PRNG generator internal state. This prevents a hypotetical (although *extremely* unlikely) generator stall scenario. This spectacularly breaks v1 compatibility, blame James ;-) Severity: low.

Requirements:	No special requirements
Platforms:	Linux
Keyword:	Crypto,  Data,  Deniable,  Deniable Encryption,  Encryption,  File,  Miscellaneous,  Security,  Tool,  Twocrypt
Users rating:	0/10