上 传 者
说明： twocrypt(2c)是一个 PoC工具，用于超狂妄者。它把两个文件加密成一个。不同的口令可以用于解译不同的变量。输出不能从单个加密文件中识别出来，并且这个工具使用一种合法的算法，这种算法本身并不意味着要隐藏任何信息。
(twocrypt (2c) is a PoC tool, uses in the ultra arrogance. It
encrypts two documents. The different password may use in the solution
to translate the different variable. The output cannot from
individually encrypt in the document to distinguish, and this tool
uses one legitimate algorithm, this algorithm itself certainly did not
mean must hide any information. )
2c\Makefile (669, 2003-02-01)
2c\2c.c (14952, 2003-02-02)
2c\config.h (732, 2003-02-01)
2c\types.h (471, 2003-02-01)
2c\lzf.h (685, 2003-02-01)
2c\TODO (247, 2003-02-02)
2c\lzf.c (4371, 2003-02-01)
2c\macros.h (1556, 2003-02-01)
2c (0, 2004-06-30)
2c - twocrypt
Copyright (C) 2003 by Michal Zalewski
GNU GPL, I guess. Go get yourself a copy of the license.
1) What is this?
2c is a simple symmetric file encryption utility that has but one
interesting 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 other file. The design
is such that the fact of using this method alone does not constitute
a credible evidence of data hiding (IANALBMSUTDO).
BE WARNED: this is an early prototype code. It very well may have
some terrible, terrible flaws that can expose or even destroy your
data. Use wisely, test, review, send back comments.
The idea is to have an encryption utility that makes it possible to
have one chunk of encrypted data that can be decoded to several
alternative contents, so that, should the creator of the encrypted
file be forced to disclose one key protecting the file, the remaining
portion of data remains safe and its presence is not evident. In
the simplified implementation I used, only two chunks of data can
be stored in a single encrypted file, and the recovery of the "deeper"
chunk requires you to know both passwords - but this can be changed.
In essence, there are two methods to approach the problem of creating
an encrypted file that can be decrypted to a set of alternative files.
First method would be based on the observation that, in theory, any data
can be decrypted to any plaintext representation. An encrypted message
that reads "ZHfmj4tu97kKXctl3z" could mean both "kill the president"
and "must buy more food". The problem with this approach, however, is
that it is not practical. Even if we do not take the effort that needs
to be invested in finding two matching keys that would produce the
desirable plaintext - that varies depending on the encryption algorithm
- the length of the key would have to be close to the shortest possible
representation (a compressed form, most likely) of the plaintext message.
When hiding files this way, this becomes a considerable problem, because
it is not acceptable to store two sizeable, password-protected keys
on the disk - that would be a clear evidence of user's intent. Thus,
most of the key information would have to be derived from the
passphrase, and passphrases are generally very short compared to the
size of data protected.
The other approach is to combine two separate passphrase-protected
files into one. The problem is quite obvious - it's not much different
from storing two separate files on the disk, the attempt to hide some
information would be obvious.
The solution this package uses is a modified version of the latter
approach by selecting an algorithm that - quite legitimately - uses
some random data to generate the output to encrypt a single file. We
can, but do not have to, replace the randomness with some information
that is meaningful, but retains the statistical characteristics of
a random data. And a headerless encrypted file is a perfect example of
an information that can't be told from a meaningless entropy obtained
from the OS (granted both the encryption and the system RNG are not
The tool itself is an implementation of such an algorithm that has an
option to be configured to obtain "randomness" from another encrypted
stream. In absence of the additional stream, it implements a regular
encryption scheme that generates output that is no different from the
"covert data" scenario.
Since good encryption is essentially indistinguishable from random data,
the presence of the hidden file is not evident. To make sure we do not
run into problems, however, we routinely encrypt the rando ... ...