For messages that are specified as octet strings (or a multiple of 8 bits), a left-justified algorithm that employs the "one and zeroes" padding method can be implemented by appending the byte value 0x80 to the message. In the same circumstances a right-justified algorithm can be implemented by appending the byte value 0x01 to the message.
Note that the bit-endianness and byte-endianness of an algorithm are not necessarily the same (for example MD4 and MD5 are big-bit-endian, but little-byte-endian). The most consistent choice for left or right justification is that a big-bit-endian algorithm be left-justified, and a little-bit-endian algorithm be right-justified; all of the SCAN algorithms that have been defined so far follow this rule.
split(D) = D split into a sequence of n >= 1 blocks
H_{D, 0} = initial state
H_{D, i} = compress(H_{D, i-1}, split(D)_{i}), for i = 1..n-1
H_{D, n} = compress(H_{D, n-1}, pad(split(D)_{n}))
digest(D) = final(H_{D, n})
The representation of the state always uses the same byte order convention as the rest of the algorithm, and chaining variables are represented in the same order as they are numbered or lettered.
Some algorithms, such as GOST-Hash or Panama, are not classified as Block MessageDigests even though it would technically be possible to describe them in the form given above, because the representation of the state is complicated or has not been standardised.
? BRS-H1(cipher)...BRS-H20(cipher) | 20 Block MessageDigest Constructions |
Let B be the cipher block size in bytes. The initial value h_{0} is the first block of the binary expansion of the fractional part of , i.e. h_{0} = I2OSP_{B}(floor(( - 3) × 256^{B})). The first 32 bytes of this are:
<243F6A8885A308D313198A2E03707344
A4093822299F31D0082EFA98EC4E6C89>
(The BRS paper suggests a zero block for h_{0}, but this may have unfortunate consequences for the constructions that use h_{0} as a key, if the zero block is a weak key for the cipher.)
The fixed block v used by BRS-H{13,15,16,19} is the first block of the binary expansion of the fractional part of e (the base of natural logarithms), i.e. v = I2OSP_{B}(floor((e - 2) × 256^{B})). The first 32 bytes of this are [[TBD]].
The MD-strengthening is done in the same way as SHA-1. That is:
The block size, B bytes, MUST also be a valid key size for the cipher. (For BRS-H5 and BRS-H15, this constraint is not absolutely required by the definitions of the constructions, but the general case of BRS-H{5,15} where the message can be processed in blocks corresponding to any valid key size is not currently included in SCAN.)
String cipher
[creation/read, no default] - the name of
the cipher on which this MessageDigest is to be based. This MUST be
an available symmetric block cipher, of block size B >= 8 bytes.
An implementation MAY also require B <= 32 bytes.
GOST-Hash | MessageDigest |
? HAS-V[(digestLength)] | Block MessageDigest |
Integer digestLength
[creation/read, default 40] - the
length of the output in bytes (minimum 16, maximum 40, multiple of 4)
digestLength
parameter (in bytes).
HAVAL[(digestLength[,passes])] | Block MessageDigest |
Integer digestLength
[creation/read, default 32] - the
length of the output in bytes (minimum 16, maximum 32, multiple of 4)
Integer passes
[creation/read, default 5] - the number of
passes to be performed (minimum 3, maximum 5)
digestLength
parameter (in bytes).
passes
parameter has been changed from 3
to 5 since SCAN 1.0.9, which is a backward-incompatible change.
Note that the beginning of section 2 of the HAVAL specification
(haval.ps
)
appears to say that HAVAL is big-bit-endian, big-byte-endian and
left-justified -- at least if the "left" of a bit or byte string is
interpreted as being first. However, the C reference code and test
vectors contradict this. We take the test vectors from the files
haval.cert
and cert.data
in the April 1997
version of haval.tar.Z
(which are written in the usual
left-to-right order) as being definitive.
MD2 | Block MessageDigest |
[C]aution requires that MD2 be no longer recommended for new applications where collision-resistance is required. Questions about the continuing suitability of MD2 for existing applications remain open. [... O]ur recommendation would be to upgrade applications away from MD2 whenever it is practical.
MD4 | Block MessageDigest |
[I]t has been shown that collisions for MD4 can be found in about a minute on a typical PC. [...] MD4 [...] should not be used.
MD5 | Block MessageDigest |
Note that a transcription error was found in the original MD5 draft RFC. The corrected algorithm should be called MD5a, though some people refer to it as MD5.This is wrong; the corrected algorithm should be called MD5, and is in practice never referred to as MD5a.
Given the surprising speed with which techniques on MD4 were extended to MD5 we feel that it is only prudent to draw a cautious conclusion and to expect that collisions for the entire hash function might soon be found.
In addition, the 128-bit output is arguably not long enough to make generating collisions using a birthday attack infeasible.
Panama | MessageDigest |
panavecs.txt
, use
an unconventional byte order when printing test vectors (the order of
bytes is reversed across the whole block).
For reference, the first and last test vectors in the last section of
panavecs.txt
(input "The quick brown fox jumps over the lazy dog" represented in
US-ASCII and truncated to various lengths), written using the usual
left-to-right convention, are:
input = "T" output = <049D698307D8541F22870DFA0A551099 D3D02BC6D57C610A06A4585ED8D35FF8> input = "The quick brown fox jumps over the lazy dog" output = <5F5CA355B90AC622B0AA7E654EF5F27E 9E75111415B48B8AFE3ADD1C6B89CBA1>
RIPEMD-128 | Block MessageDigest |
RIPEMD-160 | Block MessageDigest |
RIPEMD-256 | Block MessageDigest |
RIPEMD-320 | Block MessageDigest |
SHA-0 | Block MessageDigest |
SHA-1 | Block MessageDigest |
SHA-256 | Block MessageDigest |
SHA-384 | Block MessageDigest |
SHA-512 | Block MessageDigest |
Snefru-2[(digestLength[,passes])] | Block MessageDigest |
The difference between Snefru-1 and Snefru-2 is that Snefru-2 uses a different set of initial S-boxes, derived from the Rand Corporation's list of random digits.
Integer digestLength
[creation/read, default 32] - the
length of the output in bytes (16 or 32)
Integer passes
[creation/read, default 8] - the number of
passes to be performed (4 or 8)
digestLength
parameter (in bytes).
In the author [Ralph Merkle]'s opinion, further security analysis of Snefru is required before it can be considered for production use.
Tiger[(digestLength[,passes])] | Block MessageDigest |
Integer digestLength
[creation/read, default 24] - the
length of the output in bytes (16, 20 or 24)
Integer passes
[creation/read, default 3] - the number of
passes to be performed (minimum 3)
digestLength
parameter (in bytes).
However, it is stated on the Tiger home page that the first byte of padding is intended to be 0x01 (i.e. little-bit-endian, little-byte-endian and right-justified), and that is the interpretation used for the definition of this algorithm, despite the fact that it is apparently not consistent with the original paper.
To confuse matters further, an old copy of the Tiger reference implementation, dated February 1996, was available from Ross Anderson's web site until October 2002. That version should not be used; instead refer to the reference implementation and test vectors at the Tiger home page.
Finally, note that the test vectors use a non-standard convention for the order of bytes in the output. For reference, the first two test vectors written using the usual left-to-right convention are:
input = <> output = <3293AC630C13F0245F92BBB1766E16167A4E58492DDE73F3> input = <616263> output = <2AAB1484E8C158F2BFB8C5FF41B57A525129131C957B5F93>
Whirlpool-0 | Block MessageDigest |
? Whirlpool | Block MessageDigest |
× MGF1(digest) | MessageDigest Construction |
MGF1(digest)(input) =The maximum output length is (2^{32} - 1) × (output length of digest).
digest(input || I2OSP_{4}(0)) ||
digest(input || I2OSP_{4}(1)) ||
digest(input || I2OSP_{4}(2)) || ...
This is the same as the definition given in PKCS #1 v2.0.
See the comments below concerning compatibility with IEEE P1363a.
String digest
[creation/read, no default] - the name
of the message digest on which this PRF is to be based.
However, P1363a only defines MGF1 for a specific set of message digest functions: SHA-1, SHA-{256,384,512}, and RIPEMD-160. All of these are big-bit-endian, and so there is no incompatibility in practice. It is likely that if some future amendment of IEEE Std 1363 allowed any little-bit-endian digest functions, it would correct this bit order problem.
The classification of MGF1 as a message digest is incompatible with versions of SCAN before 1.0.18. If a PRF is required, use an algorithm designed for that purpose, such as HMAC-PRF.
Parallel(digestNames+) | MessageDigest Construction |
String[] digestNames
[creation/read, no default] - the list of
component digest algorithm names. Reading this property MUST return an
unaliased array; changing the array will not affect the algorithm.
Copyright and trademarks |