PDA

View Full Version : Is this protocol for plausible deniability worth while?


n33m3rz
April 16th, 2009, 06:09 PM
Pretty much it attempts to offer plausible deniability by first of all having everything hidden in an AVI and for two having a (Admittedly very large, with all the headers and padding taken into consideration) binary block that can be broken down and decrypted into many files with many different passphrases (With the total amount of files being unknown to anyone with out all the passphrases).

-{ Quote: "
1. The user is presented with a file selection screen where they select the files they wish to encrypt, including any throw away files they wish to include. A throw away file is essentially a non-sensitive file the user can reveal a pass phrase to if required. The user can additionally select an avi file to hide the encrypted files in.

2. The user sorts the files into up to twenty groups and enters a pass phrase to be used for decryption of each group. If two files are in a group, they will both be decrypted when the user decrypts the final encrypted file. There should be at least one throw away file.

3. The user selects an amount of end block padding to use. Although no end block padding is necessary for static files, it substantiates plausible deniability to include the option to add end block padding for static file encryption.

4. The pseudo random number generator creates a 256 bit initialization vector.

5. The pseudo random number generator generates a 600 bit string which is viewed as a series of 30 bit strings. Each group has a section of the string assigned to it (1 being the first 30 bits, 2 being the second 30 bits, etc).

6. Each group has its size and the section of the previously generated string assigned to it encrypted with its pass phrase, after the plain text is XORed with the initialization vector. This is called a header. Padding is added prior to encryption to make each header be 256 bits of cipher bits, the first 40 bits of each header prior to encryption is a standardized "successful decryption" string.


7. The files intended for encryption are transformed to binary and combined together according to their groups, with 128 bit start stop signals separating them. The resulting binaries are encrypted with their passphrases in combination with Serpent in CBC mode using the previously generated initialization vector with XOR. After the groups are encrypted, their bits are mixed together. This is done according to the 30 bit numbers associated with each group. The numbers are put in order from least to greatest. The group with the lowest number starts the resulting encrypted binary with one of its bits, the second lowest then provides the second bit and this continues until every groups bits are accounted for.

8. A new binary block is created. The first 256 bits consist of the initialization vector, the next 5,120 bits consist of the headers of the groups (or if there are less than twenty groups, random padding is used). The next 600 bits consist of the 600 bit string used to assign order to the encryption mixing of the groups. Following this there is the binary of the encrypted groups, followed by padding in the user defined length.

9. If an avi file was selected to hide the encrypted file in, the avi will be decompressed. Each frame will have a part of the encrypted binary hidden in it with the mirage algorithm (using a user provided pass phrase that should be different from any pass phrases used for groups). After the data is hidden the frames are recompressed back into an avi, the original avi is over written with eight passes of random data.


" }-