Subject: [IPsec] Issue #33 Is TIGER specified?

From: Tero Kivinen <[email-masked]>
Date: Tue, 23 Sep 2008 17:15:26 +0300

> >  D.5.  Changes from draft -02 to draft -03
> >     PRF_HMAC_TIGER              3         (RFC2104)
> 
> What is unspecified in tiger, does not the rfc 2104 specify how to use
> PRF_HMAC_TIGER?
> 
> ===Not done. The base spec for TIGER is not generally available.

Wikipedia lists following reference:
----------------------------------------------------------------------
Ross Anderson and Eli Biham, Tiger ? A Fast New Hash Function,
proceedings of Fast Software Encryption 3, Cambridge, 1996 

http://www.cs.technion.ac.il/~biham/Reports/Tiger/tiger/tiger.html
----------------------------------------------------------------------
I think that should be generally available enough.
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 23 Sep 2008 09:33:46 -0700

>Wikipedia lists following reference:

Assuming that academic paper in someone's personal directory at their 
current or past employer will always be there, and won't change 
content, is maybe a bit silly.

--Paul Hoffman, Director
--VPN Consortium

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 23 Sep 2008 20:55:50 +0300

Here's a "proper" reference, from a real book printed on real paper:

Ross Anderson, Eli Biham,
Tiger: A Fast New Hash Function,
Fast Software Encryption 3, 1996, LNCS 1039

	Yaron

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Paul Hoffman
Sent: Tuesday, September 23, 2008 19:34
To: Tero Kivinen; [email-masked]
Subject: Re: [IPsec] Issue #33 Is TIGER specified?

--Paul Hoffman, Director
--VPN Consortium

Scanned by Check Point Total Security Gateway.
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 23 Sep 2008 11:32:32 -0700

>Fast Software Encryption 3, 1996, LNCS 1039

The IPsec WG consciously decided to not move TIGER to IKEv2 partially 
because nearly no one had implemented it in IKEv1. Part of the reason 
that few implemented it in IKEv1 is that the spec was hard to get; 
part of the reason was that it was unclear what the advantage was.

Have either of those changed? Is the book readily available? Is there 
any advantage over the current hash functions that outweigh the fact 
that TIGER has gone virtually unstudied in the crypto community 
relative to the hashes we are using?

--Paul Hoffman, Director
--VPN Consortium

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 23 Sep 2008 21:43:17 +0300

Paul, I don't understand. TIGER is in RFC 4306. The debate is only whether
it is specified or not (which it clearly is, the Springer LNCS series is
widely available), not whether it is secure, well-analyzed or anything else.

	Yaron

-----Original Message-----
From: Paul Hoffman [mailto:[email-masked]] 
Sent: Tuesday, September 23, 2008 21:33
To: Yaron Sheffer; Tero Kivinen; [email-masked]
Subject: RE: [IPsec] Issue #33 Is TIGER specified?

--Paul Hoffman, Director
--VPN Consortium

---

From: <[email-masked]>
Date: Tue, 23 Sep 2008 14:01:09 -0500

>relative to the hashes we are using?

I think those are crucial questions.  Crypto doesn't benefit from having lots of choices; it benefits from having a very small number of very well understood choices.  AES and DES, SHA and MD5 -- those are functions that fit this test.  There are a whole bunch of ciphers and hashes in the "probably ok" and "not well known" category.  Having those in the spec isn't doing anyone any favors; there is no reason to believe that doing so improves the security of the system, and significant reason to worry that it might hurt.

Certainly the authors of Tiger are highly qualified cryptographers, and that is a fine start, but it's only a start, and until / unless the additional work happens, I don't see that it has met the threshold for being included in IKE.

	paul

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 23 Sep 2008 22:08:27 +0300

We are not changing IKE in IKEv2-bis. Only clarifying it. So we need an
*extremely* good reason to reopen decisions made in RFC 4306, including
decisions related to the choice of algorithms.

	Yaron

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, September 23, 2008 22:01
To: [email-masked]; Yaron Sheffer; [email-masked]; [email-masked]
Subject: RE: [IPsec] Issue #33 Is TIGER specified?

>relative to the hashes we are using?

I think those are crucial questions.  Crypto doesn't benefit from having
lots of choices; it benefits from having a very small number of very well
understood choices.  AES and DES, SHA and MD5 -- those are functions that
fit this test.  There are a whole bunch of ciphers and hashes in the
"probably ok" and "not well known" category.  Having those in the spec isn't
doing anyone any favors; there is no reason to believe that doing so
improves the security of the system, and significant reason to worry that it
might hurt.

Certainly the authors of Tiger are highly qualified cryptographers, and that
is a fine start, but it's only a start, and until / unless the additional
work happens, I don't see that it has met the threshold for being included
in IKE.

        paul

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 23 Sep 2008 12:40:01 -0700

>decisions related to the choice of algorithms.

My apologies. I got two issues mixed up. RFC 4306 points to RFC 2104 
for the definition of PRF_HMAC_TIGER. However, RFC 2104 doesn't 
mention Tiger, that is why I took off the pointer in IKEv2bis. I now 
see that I should have left it there because RFC 2104 says that it 
works with any interative hash function.

We discussed in the IPsec WG getting rid of Tiger *as a hash 
function*, and I think there was agreement to do so. But that's 
irrelevant to this discussion.

I'll revert the reference in the next version of the draft.

--Paul Hoffman, Director
--VPN Consortium

---

From: Bart Preneel <[email-masked]>
Date: Tue, 23 Sep 2008 23:51:14 +0200 (CEST)

> Certainly the authors of Tiger are highly qualified cryptographers, and that is a fine start, but it's only a start, and until / unless the additional work happens, I don't see that it has met the…

Tiger (designed in 1996) was intended to offer a security level
against collision attacks that is substantially higher than SHA-1
and RIPEMD-160 (2**96 rather than 2**80).   While there is no
shortcut collision attack on Tiger today, there exist certificational
attacks that suggest that the security margin of the Tiger design is
small (details below); a collision attack in 2**80 seems within
reach but would require more research (remember the progress that
has been made in attacking MD4 and MD5 over a decade).  However,
there will be little interest in the cryptanalytic community to try
to improve the current attacks on Tiger given that NIST's AHS competition
will break loose 6 weeks from now.

--Bart

-------------------------------------------------------------------------
Florian Mendel, Vincent Rijmen: Cryptanalysis of the Tiger Hash
Function. ASIACRYPT 2007: 536-550

Abstract. Tiger is a cryptographic hash function with a 192-bit hash
value. It was proposed by Anderson and Biham in 1996. Recently,
weaknesses have been shown in round-reduced variants of the Tiger hash
function. First, at FSE 2006, Kelsey and Lucks presented a collision
attack on Tiger reduced to 16 and 17 (out of 24) rounds with a
complexity of about 2**44 and a pseudo-near-collision for Tiger reduced
to 20 rounds. Later, Mendel et al. extended this attack to a collision
attack on Tiger reduced to 19 rounds with a complexity of about 2**62.
Furthermore, they show a pseudo-near-collision for Tiger reduced to
22 rounds with a complexity of about 244. No attack is known for the
full Tiger hash function.  In this article, we show a
pseudo-near-collision for the full Tiger hash function with a complexity
of about 2**47 hash computations and a pseudocollision
(free-start-collision) for Tiger reduced to 23 rounds with the same
complexity.
-------------------------------------------------------------------------

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

---

From: <[email-masked]>
Date: Wed, 24 Sep 2008 11:56:42 +0300

> Fast Software Encryption 3, 1996, LNCS 1039

This reference does *not* actually include enough details to
implemented Tiger (it omits the "S box tables" t1/t2/t3/t4); 
AFAIK these are only available on the author's home page.

Best regards,
Pasi

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 24 Sep 2008 12:13:19 +0300

> content, is maybe a bit silly.

Maybe, but it is much more likely to be there, than in any commercial
companies www-servers. At least there most likely will not be complete
change of the web site just to provide new look and feel as is very
common in the company environments.

It is also available in other places, but that was just the easiest to
read and find. For example
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.44.3445 offers
downloading pdf and ps versions of the actual paper, and it is of
course available in the printed proceedings too.

Here is a refence to the printed proceedings:

Ross J. Anderson and Eli Biham. TIGER: A Fast New Hash Function.
In Dieter Gollmann, editor, Fast Software Encryption,
Third International Workshop Proceedings, volume 1039 of
Lecture Notes in Computer Science, pages 89?97. Springer, February 1996.
ISBN: 3-540-60865-6
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 24 Sep 2008 12:24:36 +0300

> part of the reason was that it was unclear what the advantage was.

We have had tiger implemented for both IKEv1 and IKEv2 for long time.
It has not really been that much in use, as there has not been that
many others to implement it and currently I think it is disabled from
all our distributions.

> Have either of those changed? Is the book readily available?

I wanted to get the paper reference information for the paper, so I
called Tatu and he could find that preceedings from his library within
the minute and he gave me the reference information for the paper. I
would guess those proceedings should be in computer science libraries
around the world, or at least in those which are interested in
cryptography. 

> Is there any advantage over the current hash functions that outweigh
> the fact that TIGER has gone virtually unstudied in the crypto
> community relative to the hashes we are using?

I donot know about that, but at it is yet another hash function and
can be used as backup hash function for SHA1/2 family (in addition to
the PRF_AES128_CBC, and PRF_AES128_CMAC).

It is already defined in the IKEv2 document and numbers are in the
IANA registry, so I see no point of removing it. 
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec