Subject: [Cfrg] Any update on GOST or more generally?

From: Stephen Farrell <[email-masked]>
Date: Sun, 21 Oct 2012 22:08:24 +0100

Hiya,

Someone asked me about [1] and whether the IETF ought make
any changes as a result.

My initial reaction was that 2^172 is still more than 3DES
but its probably worth asking here.

Any CFRG thoughts on this development or more generally if
there are changes with other cryptographic functions
are welcome.

No need for an I-D, some mail is fine and we could take it
from there if there's something to do.

Thanks,
S.

[1] http://eprint.iacr.org/2012/138

---

From: Jon Callas <[email-masked]>
Date: Sun, 21 Oct 2012 16:19:35 -0700

> [1] http://eprint.iacr.org/2012/138

What sort of changes?

2^172 on a 256-bit cipher is eyebrow-raising. I feel obligated to say blah, blah, attacks only get worse, not better, blah, before someone else does.

I think it's a reason to select something other than GOST. But you could also make the argument that it's as good or better than AES (128 definitely, discussions of 256 get complex). I'd make the argument that you should use AES over 3DES, so yeah, GOST is better than 3DES.

But that's almost not the point. Many ciphers are used because they're part of a national system. If you want to be doing things in Japan, you need to use Camellia. If you're working in Korea, you need to use SEED. If you're working in Russia, you need to use GOST. Ditto for AES in the US. If you don't have any national interoperability requirements, then you use whatever your own opinions take you towards, which could be any of the previous or something else.

The IETF makes standards, but they're *protocol* standards, not *usage* standards. If the Russians require GOST, it almost doesn't matter what we say. If the Russians move away from GOST, it similarly doesn't really matter what we say.

Courtois's abstract says:

Until 2010 researchers unanimously agreed that: “despite considerable cryptanalytic efforts spent in the past 20 years, GOST is still not broken”...

which isn't strictly true; the OpenPGP working group considered putting GOST into OpenPGP and couldn't get consensus on it. Thus goes "unanimous." But lots of people have always worried about GOST because its S-boxes can be a parameter. Some sets of S-boxes were always suspect, and the *standard* GOST is the one that the Russian Central Bank used.

Courtois also notes that there's been a lot of cryptanalysis on it since 2010.  If you felt that GOST was dodgy, you now have more reasons. If you want it as an alternative to AES, you can quote <http://eprint.iacr.org/2009/374> which has a 2^119 complexity attack against AES-256, making it arguably weaker than AES-128. (Interestingly, the same paper gives an attack against AES-192 with 2^176 complexity and the same reasoning would have it stronger than either GOST or other AES key sizes). The arguments for using GOST as an alternative to AES still stand, if that's what floats your boat. And as I noted above, if you are doing business in Russia, this is all irrelevant as you just have to use GOST.

All of this is reason for us in the IETF to take note and just keep paying attention. If we're going to use this as a reason to advise for or against GOST, we really need to consider the BDKKS attack on large-key AES. None of these attacks are practical, though, and anything with a real 128 bits of security is likely good for the next couple-three decades. Most of us pick ciphers by a combination of security SWAG and fiat. This might change one's SWAG, but it doesn't change the fiat.

	Jon

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 22 Oct 2012 00:41:32 +0100

Hi Jon,

See below...

>> [1] http://eprint.iacr.org/2012/138

Dunno. Depends on what's the right thing to do.

I guess that could vary from 'do nothing' up to 'write an
I-D saying "<foo> considered harmful" that also deprecates
some code points in various IANA registries.'

[...good stuff snipped, though more is welcome...]

> Courtois also notes that there's been a lot of cryptanalysis on it since 2010.  If you felt that GOST was dodgy, you now have more reasons. If you want it as an alternative to AES, you can quote <h…

I'd love to know if someone's actually measured how much
these national/vanity ciphersuites are actually used in
IETF protocols.

S.

> _______________________________________________
> Cfrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/cfrg
>

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 21 Oct 2012 16:57:44 -0700

On Oct 21, 2012, at 4:19 PM, Jon Callas <[email-masked]> wrote:

> If you want to be doing things in Japan, you need to use Camellia. 

Are you sure of that? I ask because a few years ago, I had a discussion with the Camellia authors about some new work, and their slides made me question "how much of a national standard is this?" Their answer was extremely non-commital, and they never followed up.

I ask this not to poke at Camellia or the authors, but to find out if CFRG needs to group Camellia/Japan with GOST/Russia.

--Paul Hoffman

---

From: Jon Callas <[email-masked]>
Date: Sun, 21 Oct 2012 18:24:48 -0700

> I ask this not to poke at Camellia or the authors, but to find out if CFRG needs to group Camellia/Japan with GOST/Russia.

In the case of Japan, they're a lot softer than most countries that push their own national standards. In Russia, you *must* use GOST to work with banking, etc. There are places in Korea where you definitely need to use SEED. In Japan, they have a Cryptographic Module Verification Program (JCMVP) similar to the US/Canada CMVP we call FIPS 140. See 

<http://www.ipa.go.jp/security/jcmvp/jcmvp_e/algorithm.html>

for details. It was developed with the help of the US and Canada. It has the FIPS 140 algorithms with additions of Camellia, CIPHERUNICORN, MISTY, and others.

It's possible to get through JCMVP with only the US/Canada ones, but it's very polite to use some of the Japanese ones. Politeness scores lots of points in Japan. They feel like that means you're committed to them. They buy your stuff if you're committed to them. This is a typical issue in exporting to Japan that they're bad at saying no and you have to learn the proper level of politeness to be accepted. In crypto, that means you need to use some of their ciphers.

	Jon

---

From: Yoav Nir <[email-masked]>
Date: Mon, 22 Oct 2012 08:14:01 +0200

> I ask this not to poke at Camellia or the authors, but to find out if CFRG needs to group Camellia/Japan with GOST/Russia.

[vendor hat on]

My company sells IPsec and TLS VPN products all over the world, including Russia, Japan, Korea, and China. The main version of our product supports "western" ciphers - AES, 3DES, RC4. The only customers who have ever asked for a product that supports their national cipher are from Russia. We've never been asked to implement Camelia or SEED.

So our product sells all around the world with just two versions: regular and GOST.

Yoav

---

From: Thomas Hardjono <[email-masked]>
Date: Mon, 22 Oct 2012 14:40:41 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of
> Yoav Nir
> Sent: Monday, October 22, 2012 2:14 AM
> To: Paul Hoffman
> Cc: [email-masked]; Jon Callas
> Subject: Re: [Cfrg] Camellia as an Japanese national cipher
>
>
> > Are you sure of that? I ask because a few years ago, I had a
> discussion with the Camellia authors about some new work, and their
> slides made me question "how much of a national standard is this?"
> Their answer was extremely non-commital, and they never followed up.
> >
> > I ask this not to poke at Camellia or the authors, but to find out 
> > if
> CFRG needs to group Camellia/Japan with GOST/Russia.
>
> [vendor hat on]
>
> My company sells IPsec and TLS VPN products all over the world,
> including Russia, Japan, Korea, and China. The main version of our
> product supports "western" ciphers - AES, 3DES, RC4. The only 
> customers
> who have ever asked for a product that supports their national cipher
> are from Russia. We've never been asked to implement Camelia or SEED.
>

+1 Agree with statement about needing Camellia for Japan market.

FYI the MIT Kerberos code-base has already implemented Camellia as
of Kerberos5 Release 1.9 (a couple of years ago).
This was a joint effort with NTT Japan.

If you have any questions, please feel free to contact me offline.

/thomas/

__________________________________________
Thomas Hardjono
MIT Kerberos Consortium
email:  hardjono[at]mit.edu
__________________________________________