If you have downloaded a binary, then extract it using the command:
tar xvzf xcrypt.XXXX.tgz"
or by extracting the binary from the "xcrypt.XXXX.zip" file if you have downloaded that.
Then move or copy the executeable to a suitable directory on the disk.
Please note: the XXXX above is in fact the version number of the program.
If you are compiling the source then enter command...
tar xvzf xcrypt.XXXX.tgz"
or by extracting the "src" directory from the zip file if you have that.
Then, from the "src" dirextory within, on UNIX, LINUX and other POSIX systems enter:
make
and on CYGWIN, enter:
mv Makefile.cyg Makefile
make
and copy/move the executeable to a suitable directory.
xcrypt OPERANDS [sourcefile destinationfile]
xcrypt OPTION
If sourcefile and destination file is not specified then the standard input and output are used. That means this can be used in a pipe. Either both or neither the files can to be specified this way. If only one is required then the "infile" and "outfile" operands need to be used.
tar cvz . | xcrypt keyfile=mysecret > /dev/tape
| check=on|off |
Under normal circumstances xcrypt places an encrypted check-hash of the key in the header of the output during encryption. This is checked on decryption and if the hash used to decrypt is not equal the one used to encrypt the program exits with an error. When "check" is set to "off" the generation of this hash at encryption is surpressed, and the checking of it is surpressed at decryption. |
|||||||||
| chunk=off|on|NNNN |
The encrypted file can be divided into "chunks" of a size. Each "chunk" terminates with a 16 byte chunk markerand an 8 byte chunk number. On decryption, if a "chunk marker" is not seen when expected it will skip ahead until it fimnds one, padding the output file with the respective number of "NULL" (0) bytes to maintain it's length. When a chunk marker is found (expected or otherwise) the IV is reset (to the original weighted by the chuink number) and decryption is processed.
The chunk, if applicable, is processed when decoding, and if a chunking error occurs a warning appears on the standard output. Although the decryption will continue as well as "padding" the chink(s) out, the program will exit with an "error code" of 4 when it terminates. |
|||||||||
| crc=off|on|NNNN | This controls the placeing of a CRC checksum value for each "segment" of data. The options are:
The CRC, if applicable, is checked when decoding, and if a checksum error occurs a warning appears on the standard output. Although the decryption will continue, the program will exit with an "error code" of 2 when it terminates. |
|||||||||
| crcpad=on|off |
This is only applicable if the "crc" operand is not "off" and a srtream cipher is being used. If the last segment of a file being decrypted by a stream file is less than the crc segment size then that segment does not have a CRC checksum generated for it. When this operand is set the file is "padded out" using the NULL character (0) to the CRC segment size and a checksum is included. This means that on decryption the file will have a whole lot of NULL characters appended to it. If this is not desireable then the "crcpad=off" operand should be included. A "block" cipher - that is the default - CBC - as ECB well as ECB and ECBCTR is not effected by this operand, CRC checksums when calculated are so for all segments of the file in this case and there is no need for any "pad" character. |
|||||||||
| header=on|off |
If this is set to "off" details of the cipher (IV, cipher type etc) are not transmitted in the header of the file, and those arguments need to be re-specified on decryption. This defaults to "on" as cipher mechanism details do not detract from security and it makes operation easier. It is worth noting that not including the IV in the transmitted data does not improve security. In fact, not generating it using random numbers is makes it far more possible for the data to be cracked. In short, setting the "headeriv", "iv" and/or "ivfile" parameters makes the data less secure and none of them should be used. |
|||||||||
| infile=file | This is an alternate way of specifying the input file. It needs to be done this way when specifying this when in a file defined using the "parfile" argument. | |||||||||
| headeriv=on|off |
When encrypting data the program will usually generate an "Initialization Vector", or "IV", based on random numbers, and it is included in the header of the encrypted data. However it is possible to tell the routine to generate one based on a phrase or file contents 9using the "iv" or "ivfile" operands), and also possible to not include it in the transmitted data by setting this operand to "off". It is worth noting that the "key" is never transmitted or stored in the encrypted file. |
|||||||||
| iv="phrase" |
Under "normal" running the IV, or "Inintialisation Vector" is randomly generated by the system. In LINUX systems this is done by reading form the "/dev/urandom" device file. In other systems this is achieved by performing a hash on the current time. This IV value is then included as part of the encrypted file header. The system gives the operator to create his own IV value by using the "iv" (and "ivfile") arguments. This is generated the same way as the "key" data is. Care should be taken when using this that selecting the same IV more than once for the same key will greatly reduce security. It is not neccessary for the IV to be "secret" (in fact, it is included in the header information of the encrypted file), just unique. For this reason It is not reccomended that this or the "ivfile" argument is used. |
|||||||||
| ivfile=file | As with "key" data IV can be derived from the contents of a file. | |||||||||
| key="phrase" | A phrase used to generate the key. If there are spaces in the phrase then it needs to be enclosed by quotes. If more than one key (or keyfile) argument is supplied then the keys are combined (exclusive or'd) to create the key that will be used. The key itself is 256 bits long (32 bytes) and is obtained by hashing the appropriate data supplied by the operatori using the SHA256 algorythm. | |||||||||
| keyfile=FILE | Here, file is a readable file whose contents is used to generate the key. This can be combined with other key and keyfile arguments. Please note the "hashing" algiorithm used to generate the key for the "keyfile" argument is different to the one used for the "key" argument, so you cannot use "key" to encrypt, and "keyfile" to decrypt even if the phrase is the same as the file contents. | |||||||||
| mode=encrypt|decrypt | This program usually decides if to "encrypt" or "decrypt" a file based on the header of the file. However, encryption or decryption can be forced by supplying an "encrypt" or "decrypt" value to the "mode" argument. | |||||||||
| outfile=FILE | This is an alternate way of specifying the output file. It needs to be done this way when specifying this when in a file defined using the "parfile" argument. | |||||||||
| parfile=FILE |
The file specified here is a parameter file that can contain any OPTION specified here, one operand per line. This file can contain comments by prefixing it with a "#". There should be no spaces at the begginning of lines (comments or otherwise). For exampe... # A parameter file for xcrypt # # # The key is in the contents of a file called "mysecret" keyfile=mysecret # # The input file is always saved as this.... # infile=messagefromyou.enc # # And the output is # outfile=messagefromyou.doc # # When using this - should always be decrypting # mode=decrypt # ### End of file |
|
--version
--help |
Display version and list of operands, then quit. All operands (and other arguments) are ignored. |
On decryption there is no validation that you have the correct key using checksums or anything else, so the incorrect key will produce rubbish.
This routine makes no attempt at authentication, or at the use of "public key" technology such as RSA. If using this to securely transmit data the key file or phrase needs to be somehow commuted to the recipiant in an independant ecure way.