Talk:Tiger (hash function)

	This article is within the scope of WikiProject Cryptography, a collaborative effort to improve the coverage of Cryptography on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.CryptographyWikipedia:WikiProject CryptographyTemplate:WikiProject CryptographyCryptography articles
???	This article has not yet received a rating on the importance scale.
	This article is supported by WikiProject Computer science.

Untitled[edit]

Noticed that the checksums for the empty test vector appear to be wrong for both straight Tiger and Tiger2. However, I'm not by any means an experienced wikipedia dude, so I'll leave fixing them for someone better versed -- messing around with test vectors in an article on which actual people presumably rely is something I'm not going to make a decision on with this lack of experience.

The correct result for Tiger(""), according to the authors' web site, is 24F0130C63AC9332 16166E76B1BB925F F373DE2D49584E7A. When I generated the hash for Tiger("The quick brown fox jumps over the lazy dog") with an implementation that produces correct results for all the test vectors on the main Tiger web page, I got f044e6721ea4126d 624cb4f7e2f0b617 75b0c5d2d56df085. The s/dog/cog/ input gives d7a001720f4bf0a8 315b52269d1c1028 8f45d8fc93344a76. The implementation used was libgcrypt 1.2.2. I have no equivalent results for the Tiger2 algorithm.

I should note that a C# implementation ("Ivs.Tiger") produces the exact same hashes as are presented in the article, which for the empty input deviate from "official" test vectors.

Ksandstr 00:49, 1 November 2005 (UTC)[reply]

I don't think your assumption is correct: You probably looked on the page http://www.cs.technion.ac.il/~biham/Reports/Tiger/testresults.html, where it is explicitly stated that the output is differently formatted than the real output of Tiger. Each of the 8-byte words ist byte-swapped. If you look at the bytes more closely, you find them all appearing, just byte-swapped. If you look at the page http://www.cs.technion.ac.il/~biham/Reports/Tiger/test-vectors-nessie-format.dat, you see the correct output, which is exactly what you see here. The correct result for the text vector ("") in fact is 3293AC630C13F0245F92BBB1766E16167A4E58492DDE73F3, which is produced by many implementations I've been using.

According to this the "disputed section" should be removed.

Green Yogi Jr. 09:37, 9 November 2005 (UTC)[reply]

Ksandstr, have a look at the note of the Perl implementation: http://search.cpan.org/~clintdw/Digest-Tiger-0.02/Tiger.pm#NOTE The print order issue was brought up by Gordon Mohr; Eli Biham clarifies with: "The testtiger.c was intended to allow easy testing of the code, rather than to define any particular print order. ...using a standard printing method, like the one for MD5 or SHA-1, the DD should probably should be printed first".

This make sense, otherwise you also need to attach the print order/platform information to the hash output.

See also http://www.cs.technion.ac.il/~biham/Reports/Tiger/testresults.html "Test Results of testtiger: All 64-bit numbers are hexadecimal representations of unsigned integers. Their binary representation is as three 64-bit words. On little-endian processors each word can be viewed as an eight-byte array printed below in the order w[7] w[6] w[5] w[4] w[3] w[2] w[1] w[0]. Thus the 192-bit hash values are represented below in the byte order 7 6 5 4 3 2 1 0 space 15 14 13 12 11 10 9 8 space 23 22 21 20 19 18 17 16. The values printed here do NOT define the way the output of Tiger is printed!!!"

=> The "disputed section" should be removed.

Jonelo 18:48, 9 November 2005 (UTC)[reply]

I have removed the disputed section, but I have also added a few additional words to avoid confusion with the output of the testprogram at the author's homepage.

Jonelo 20:14, 13 November 2005 (UTC)[reply]

RIAA data corruption on Gnutella/etc[edit]

It's to my understanding the RIAA and related groups are reported to offer corrupted files, or taint them by exploiting a weakness in the way the hash/fingerprint etc is published. Does anyone have comments on this? Supaplex 07:41, 26 January 2006 (UTC)[reply]

That's nonsense. You probably confuse Kaaza with Gnutella. Kaaza and Napster use a checksum algorithm which uses only some data of the file apparently to decrease the time necessary to calculate the checksums. So that means you can inject arbitary data into parts of the file not covered by the checksum. Gnutella and likely any other modern file-sharing networks use cryptographic hashsums like SHA-1, Tiger or others which cover the complete file data. Of course, anybody can still offer a file claiming it has a certain hashsum X whereas it's really Y and then you have wasted a couple of time and traffic. --16:05, 1 April 2007 (UTC)

Message padding[edit]

Quote:

Tiger2 is a variant of Tiger which uses the same message-end padding as MD5 and SHA, rather than the slightly different padding used in MD4.

MD4 and MD5 have the same padding procedure. It's MD2 that's the oddball.

QZ 14:53, 12 May 2007 (UTC)[reply]

Correct. And also, the padding procedures of MD5 and SHA are different: bitlength sizes are in little endian and big endian format respectively.

Tiger Security[edit]

Although Tiger has only 3 passes in it, those 3 passes execute 8 full rounds, each of which updates the entire 192-bit state with 3 64-bit sub-rounds similar to 6 32-bit subrounds (not even counting the additional s-box look-ups). This is nothing like MD5's or SHA-1's 16 primitive sub-rounds per block. It is comparable to 144 rounds of SHA-1 not even counting Tiger's much stronger key schedule or its 4 large 8x64-bit S-boxes. Whoever stated that Tiger has only 3 rounds per word of input, obviously did not know the structure of the Tiger round function well enough. An attack that can find pseudo-near-collisions even in full Tiger also does not necessarily suggest that more rounds are required, although it may suggest that structural improvements are required. It sounded misleading, so I removed it. If my comparison is not entirely correct, please fix it, but 3 passes of 8 full rounds updating the entire 192-bit state with 64-bit operations and large S-box look-ups cannot be described there as being "less" than 4-5 passes of 16 rounds updating only one 32-bit word of the state each. Check out the key schedule, see how well it diffuses each input word throughout all 8 subkeys for each pass. Ruptor (talk) 17:12, 6 June 2008 (UTC)[reply]

I would like to point out that the reliance on S-boxes is not universally considered an improvement (like your edit suggests) due to cache timing attacks on general-purpose CPUs. -- intgr [talk] 20:41, 7 June 2008 (UTC)[reply]

Issue with example[edit]

Don't have the knowledge to fix this, but this section doesn't make sense:

Even a small change in the message will (with overwhelming probability) result in a completely different hash, e.g. changing d to c:

Tiger("The quick brown fox jumps over the lazy dog") = a8f04b0f7201a0d728101c9d26525b31764a3493fcd8458f

Tiger2("The quick brown fox jumps over the lazy cog") = 09c11330283a27efb51930aa7dc1ec624ff738a8d9bdd3df

The message changed but so did the hash from Tiger to Tiger2. Seems it should be different message with the same hash in order to illustrate the point correctly. — Preceding unsigned comment added by 205.170.132.51 (talk) 22:39, 1 September 2011 (UTC)[reply]

That doesn't even make sense; the whole point of this algorithm is to make finding two messages with the same hash (nearly) impossible. The first was actually just a typo that's now been corrected. Also, Tiger and Tiger2 are different and will always produce different output; it would be more clear to separate them into different sections. Foxyshadis^(talk) 02:58, 22 September 2011 (UTC)[reply]