The program consists of two parts

• The first one uses a collection of ciphers to encrypt the text message. This part has been written by Hagen Reddmann. It is written in Delphi and is distributed from Borland website. The package is called " Delphi Encryption Compendium", and includes the source files so the implementation of the encryption algorithms may be examined by anyone who can read Delphi. It may be downloaded from a number of other places. For example you may get the entire package from: http://www.delphi32.com/vcl/3267/  (this includes the source files)
• The second part of the program, written by Moshe Szweizer, writes the encrypted text into an image. In this manner the encryption is not visible and may be distributed as an ordinary bitmap image. The source files for this part of the program are not public.
   

Ciphers used in the program

3-Way

Comment: The byte ordering convention is as follows: within each 12-byte block, the 32-bit words are represented in the same order as they are written in chapter 7 of Joan Daemen's thesis. Within each 32-bit word, the bytes are in big-endian order. This is consistent with the four test vectors in Crypto++ (note that the same four test vectors are included on page 659 of Applied Cryptography, 2nd edition, with the words written in the opposite order).

Security comment: 3-Way is vulnerable to related-key attacks, and therefore it should only be used with keys that are generated by a strong RNG, or by a source of bits that are sufficiently uncorrelated (such as the output of a hash function).

Security comment: The weak keys described in Vaudenay's paper do not appear to be significant for full (16-round) Blowfish.

Comments: The paper "The Diamond2 Block Cipher" does not appear to specify a recommended number of rounds, only a minimum number of rounds. For that reason, the rounds parameter has been made mandatory. The "Diamond2 Lite" variant does not have a standard name.

Security comment: The paper "A chosen key attack against the secret S-boxes of GOST" cited above describes how to recover the S-boxes in about 232 encryptions. The main significance of this is on tamperproof hardware implementations where the S-boxes were assumed to be secret; for a software implementation, they should be assumed to be public in any case.

Comments: The range of specified key lengths has been extended since SCAN 1.0.12 (which only specified 128, 192 and 256 bits). This is an incompatible change for the key lengths that were not previously supported. Rijndael is pronounced approximately as "Rhine-dahl".

Comment: Conventionally, the key length for SAFER is included in the algorithm name, e.g. "SAFER K-64", "SAFER K-128", etc. Because a SCAN algorithm may have variable-length keys, all of these are referred to as "SAFER-K".

Security comment: As a result of the key schedule attack by Lars Knudsen cited above, SAFER-K has been superseded by SAFER-SK.

Comments: Conventionally, the key length for SAFER with strengthened key schedule is included in the algorithm name, e.g. "SAFER SK-64", "SAFER SK-128", etc. Because a SCAN algorithm may have variable-length keys, all of these are referred to as "SAFER-SK". SAFER_SK.TXT suggests a maximum of 10 rounds for a 64-bit key, and 12 rounds for a 128-bit key; however here we do not specify any limit on the number of rounds. Also note that because the number of rounds can be given in the algorithm name before the key length is known, it is possible to use a 128-bit key with 8 or 9 rounds (i.e. less than the default), but this is definitely not recommended. A 40-bit key schedule has also been specified for SAFER-SK; this is not required to be implemented, and application designers should not assume that a SAFER-SK implementation will support 40-bit keys.

Security comment: "The Interpolation Attack on Block Ciphers" analyses a "variant of SHARK, which deviates only slightly from the proposed SHARK", reduced to 5 rounds. SHARK normally has 6 rounds.

Security comment: "The Interpolation Attack on Block Ciphers" analyses a "variant of SHARK, which deviates only slightly from the proposed SHARK", reduced to 5 rounds. SHARK normally has 6 rounds.

Comment: Big-endian byte order is used when converting the plaintext, ciphertext, and key to 32-bit words. Note that this may not match some other TEA implementations. The algorithm "XTEA" (sometimes called "tean") was intended to be a modification of TEA resistant to related key attacks. However, that algorithm is not well-defined (it was implemented inconsistently, due to an ambiguity in the paper describing it [PS, PDF]), and is not included in SCAN. "Block TEA" is also not included in SCAN, and neither is this correction to Block TEA.

Security comment: TEA is vulnerable to related-key attacks, and therefore it should only be used with keys that are generated by a strong RNG, or by a source of bits that are sufficiently uncorrelated (such as the output of a hash function).

Comment: The C and Java reference implementations differ from the specification in "Twofish: A 128-bit Block Cipher," for key lengths between 8 and 64 bits inclusive. A strict reading of the specification would zero-pad these keys to 128 bits, and use k = 2; the reference implementations zero-pad them to 64 bits, and use k = 1. This algorithm follows the reference implementations (however, the use of keys this small is definitely NOT RECOMMENDED).

Block Cipher Modes

For byte-oriented modes, the plaintext or ciphertext can be processed one byte at a time (by use of internal buffering if necessary). This means that a padding scheme is not required, i.e. the standard name will be of the form "cipher/mode". For backward compatibility, however, any of the forms "cipher/mode", "cipher/mode/NoPadding", and "cipher/mode/NONE" should be accepted when the mode is byte-oriented. The last two of these are deprecated.

Comment: If a padding scheme is not specified (i.e. the algorithm name is given in the form "cipherName/CBC"), then PKCSPadding MUST be assumed. The standard name always specifies which padding method is used, i.e. it always has three components.

Comment: The value of feedbackBits does not affect the granularity of data that can be encrypted or decrypted. Implementations MUST support immediate processing of individual bytes, in a similar fashion to a stream cipher. This means that it is never necessary to specify a padding scheme (and therefore the standard name always has two components).

Comments: Implementations MUST support immediate processing of individual bytes, in a similar fashion to a stream cipher. This means that it is never necessary to specify a padding scheme (and therefore the standard name always has two components). The reason for not supporting feedback sizes less than the block size, is that this greatly reduces the expected period of the keystream (e.g. from about 266 bytes to 234 bytes, for a cipher with a block size of 8 bytes).

Block Cipher Padding

Comments: CTS is only defined for block ciphers in ECB and CBC modes. The "RC5-CTS" mode in RFC 2040 is equivalent to RC5/CBC/CTS; this gives a source of test vectors, at least for one cipher. The amount of data that must be buffered by the cipher implementation is increased when ciphertext stealing is used (specifically, up to two blocks can be buffered, for both encryption and decryption). If the total length of plaintext or ciphertext, excluding IV, is less than or equal to one block when doFinal is called, a BadPaddingException will be thrown. (I.e. the minimum length of plaintext that can be encrypted is one block plus one byte.) The diagrams in Applied Cryptography do not make clear the behaviour when the plaintext or ciphertext length is an exact number of blocks. In this case the "last" block is considered to be the last complete block, rather than being of zero-length. This matches the specification in section 8 of RFC 2040. Note that in this case the last two blocks of the ciphertext will be interchanged when compared with ECB or CBC mode with NoPadding.