上传日期:2004-06-30 23:22:44
上 传 者wangyong
说明:  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. 2) Huh!? -------- 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. 3) So...? --------- 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 flawed). 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 ... ...