Software Coupon Codes Directory

BitCrypt antivirus report at download3k.com

BitCrypt

An Ultra-Strong Encryption that's easy to use

 

I'm giving you a software piece of superior quality

Can I trust you to use it for legal purposes only?

                                                                       Moshe Szweizer

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-Way

Designer: Joan Daemen
Published: 1994
Key length: 96 bits
Block size: 12 bytes

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).

 

Blowfish

Designer: Bruce Schneier
Published: 1994
Alias: "OpenPGP.Cipher.4"
Key length: Minimum 32, maximum 448, multiple of 8 bits; default 128 bits.
Block size: 8 bytes.

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

 

Diamond2(rounds)

Designer: Michael Paul Johnson
Published: 1995
Key length: Minimum 8, maximum 65536, multiple of 8 bits; default 128 bits.
Block size: 16 bytes.

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.

 

GOST

Alias:"GOST-28147-89"
Published: 1989
Key length: 256 bits.
Block size: 8 bytes.

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.

 

Rijndael

Designers: Joan Daemen, Vincent Rijmen
Published: November 1998
Description: This is Rijndael with a 128-bit block size. The number of rounds is 6 + max(Nk, Nb), where Nb = 4, and Nk is the number of 32-bit words in the key.
Key length: Minimum 128, maximum 256, multiple of 32 bits; default 128 bits. Block size: 16 bytes.

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
Published: December 1993.
Description: This algorithm refers to the original version of SAFER, designed in 1993.
Key length: 64 or 128 bits; default 128 bits. Block size: 8 bytes.

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
Published: September 1995.
Description: This algorithm refers to the version of SAFER with a strengthened key schedule, designed in 1995 (see SAFER_SK.TXT, cited below).
Alias: "OpenPGP.Cipher.6" for SAFER-SK(13).
Key length: 64 or 128 bits; default 128 bits. Block size: 8 bytes.

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-II

Designer: Michael Paul Johnson
Published: January? 1995
Key length: Minimum 8, maximum 2040, multiple of 8 bits; default 128 bits.

 

SHARK-A

Designers: Vincent Rijmen, Joan Daemen, Bart Preneel Antoon Bosselaers, Erik De Win
Designers: This is the "Affine Transformation" variant of SHARK.
Key length: 128 bits.
Block size: 8 bytes.

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-E

Designers: Vincent Rijmen, Joan Daemen, Bart Preneel Antoon Bosselaers, Erik De Win
Designers: This is the "Exor" variant of SHARK.
Key length: 128 bits.
Block size: 8 bytes.

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
Published: 1997
Key length: 128 bits.
Block size: 16 bytes.

 

TEA

Designers: David Wheeler, Roger Needham
Published: 1994
Key length: 128 bits.
Block size: 8 bytes.

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).

 

Twofish

Designers: Bruce Schneier, John Kelsey, Doug Whiting, David Wagner, Chris Hall, Niels Ferguson
Published: 1998
Alias: "OpenPGP.Cipher.10" [[implies 256-bit key]]
Key length: Minimum 8, maximum 256, multiple of 8 bits; default 128 bits.
Block size: 16 bytes.

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

Symmetric 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.

 

CBC

Description: 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.
Aliases: "CFBn", where n is an integer, can be used as a deprecated alias for "CFB(n)".
The values of n that may need to be supported for backward compatibility are 8 and 64.

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).

 

OFB

Description: 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).

 

CTS

Alias: "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