|
|
|||||||||||||||||||||||||||||||||
BitCrypt Technical |
|||||||||||||||||||||||||||||||||
|
The program consists of two parts
Ciphers used in the program
3-WayDesigner: Joan Daemen 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 ModesSymmetric block cipher modes fall into two categories: block-oriented and byte-oriented. For block-oriented modes, the plaintext or ciphertext can only be processed one block at a time. This means that a "padding scheme" is needed to specify how to handle the last block of a message, i.e. the standard algorithm name will be of the form "cipher/mode/padding". If messages are always an exact number of blocks in length, "NoPadding" may be specified as the padding scheme. 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. |
|||||||||||||||||||||||||||||||||
