|
BitCryptAn Ultra-Strong Encryption that is easy to use
BitCrypt can be used to encrypt non-Latin texts.
|
|||
3Way Blowfish Diamond II Gost Rijndael SAFER-K128 SAFER-SK128 Sapphire II Shark Square TEA Twofish |
Block
Cipher Modes
Cipher Block Chaining Cipher Feedback Output Feedback Block Cipher Padding Cipher Text Stealing |
|||
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). |
||||
BlowfishDesigner:
Bruce Schneier Security comment: The weak keys described in Vaudenay's paper do not appear to be significant for full (16-round) Blowfish. |
||||
ADVERTISEMENT |
||||
Diamond2(rounds)Designer: Michael Paul Johnson 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. |
||||
GOSTAlias:"GOST-28147-89" 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. |
||||
RijndaelDesigners:
Joan Daemen,
Vincent Rijmen 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". |
||||
SAFER-K[(rounds)]Designer: James Massey 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. |
||||
SAFER-SK[(rounds)]Designer: James Massey 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. |
||||
Sapphire-IIDesigner: Michael Paul Johnson |
||||
SHARK-ADesigners:
Vincent Rijmen,
Joan Daemen,
Bart
Preneel
Antoon Bosselaers,
Erik De
Win 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. |
||||
SHARK-EDesigners:
Vincent Rijmen,
Joan Daemen,
Bart
Preneel
Antoon Bosselaers,
Erik De
Win 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. |
||||
Square[(rounds)]Designers:
Joan Daemen,
Vincent Rijmen |
||||
TEADesigners: David Wheeler,
Roger Needham 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). |
||||
TwofishDesigners:
Bruce Schneier, John Kelsey, Doug Whiting,
David Wagner,
Chris Hall, Niels Ferguson 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. |
||||
CBCDescription: Cipher Block Chaining Mode, as defined in NBS FIPS PUB 81. 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. |
||||
CFB[(feedbackBits)]Description: Cipher Feedback Mode, as defined in NBS FIPS PUB 81, with a
feedback vector of length feedbackBits bits. 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). |
||||
OFBDescription: Output Feedback Mode, as defined in NBS FIPS PUB 81, except that the feedback vector is restricted to be the same size as a block. 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). |
||||
CTSAlias: "CiphertextStealing" 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. |
||||
Keywords: encryption, text encryption, steganography, encryption techniques, secure encryption, powerful encryption, unbreakable encryption, very strong encryption, secret communication, covert transmission, secure transmission, watertight security, secure communication, opaque information transmission |