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

Jon Callas <jon@callas.org> Sun, 21 October 2012 23:19 UTC

Return-Path: <jon@callas.org>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DD9221F8A3C for <cfrg@ietfa.amsl.com>; Sun, 21 Oct 2012 16:19:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.669
X-Spam-Level:
X-Spam-Status: No, score=-1.669 tagged_above=-999 required=5 tests=[AWL=-0.930, BAYES_20=-0.74, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FzIUZ8UBZse7 for <cfrg@ietfa.amsl.com>; Sun, 21 Oct 2012 16:19:38 -0700 (PDT)
Received: from mail.merrymeet.com (merrymeet.com [173.164.244.100]) by ietfa.amsl.com (Postfix) with ESMTP id F2DDD21F8A3B for <cfrg@irtf.org>; Sun, 21 Oct 2012 16:19:37 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.merrymeet.com (Postfix) with ESMTP id 07C0A1205A45 for <cfrg@irtf.org>; Sun, 21 Oct 2012 16:19:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at merrymeet.com
Received: from mail.merrymeet.com ([127.0.0.1]) by localhost (merrymeet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3vWW0sV-fGN6 for <cfrg@irtf.org>; Sun, 21 Oct 2012 16:19:35 -0700 (PDT)
Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) by mail.merrymeet.com (Postfix) with ESMTPSA id E26921205A2C for <cfrg@irtf.org>; Sun, 21 Oct 2012 16:19:35 -0700 (PDT)
Received: from [10.0.23.14] ([173.164.244.98]) by keys.merrymeet.com (PGP Universal service); Sun, 21 Oct 2012 16:19:35 -0700
X-PGP-Universal: processed; by keys.merrymeet.com on Sun, 21 Oct 2012 16:19:35 -0700
From: Jon Callas <jon@callas.org>
Message-Id: <787855B1-9135-4075-82AC-8FC4DE76B340@callas.org>
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
Date: Sun, 21 Oct 2012 16:19:35 -0700
References: <50846448.4030608@cs.tcd.ie>
To: cfrg@irtf.org
In-Reply-To: <50846448.4030608@cs.tcd.ie>
X-Mailer: Apple Mail (2.1499)
X-PGP-Encoding-Format: MIME
X-PGP-Encoding-Version: 2.0.2
Content-Type: multipart/signed; boundary="PGP_Universal_01FFBA2B_22CE36A8_5A5E8FEF_D8CE02AE"; protocol="application/pgp-signature"; micalg="pgp-sha1"
Subject: Re: [Cfrg] Any update on GOST or more generally?
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Sun, 21 Oct 2012 23:19:39 -0000

On Oct 21, 2012, at 2:08 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:

> 
> 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

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