Talk:Tiger (hash function)

message: 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)
thread_title: Untitled

message: 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)
replies: text: 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)
thread_title:  RIAA data corruption on Gnutella/etc 

message: 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)
thread_title:  Message padding 

message: 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)
replies: text: 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)
thread_title:  Tiger Security 

message: 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)
replies: text: 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)
thread_title:  Issue with example