[dsfjdssdfsd] Remove ref to DSS RNG

Dan Brown <dbrown@certicom.com> Fri, 14 March 2014 17:07 UTC

Return-Path: <dbrown@certicom.com>
X-Original-To: dsfjdssdfsd@ietfa.amsl.com
Delivered-To: dsfjdssdfsd@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 956CB1A0164 for <dsfjdssdfsd@ietfa.amsl.com>; Fri, 14 Mar 2014 10:07:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zzO0AXp0Dl_Y for <dsfjdssdfsd@ietfa.amsl.com>; Fri, 14 Mar 2014 10:07:56 -0700 (PDT)
Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) by ietfa.amsl.com (Postfix) with ESMTP id E17BA1A00F1 for <dsfjdssdfsd@ietf.org>; Fri, 14 Mar 2014 10:07:55 -0700 (PDT)
Received: from xct102cnc.rim.net ([10.65.161.202]) by mhs210cnc.rim.net with ESMTP/TLS/AES128-SHA; 14 Mar 2014 13:07:44 -0400
Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT102CNC.rim.net ([fe80::2066:5d4f:8c45:af55%17]) with mapi id 14.03.0174.001; Fri, 14 Mar 2014 13:07:43 -0400
From: Dan Brown <dbrown@certicom.com>
To: "dsfjdssdfsd@ietf.org" <dsfjdssdfsd@ietf.org>
Thread-Topic: Remove ref to DSS RNG
Thread-Index: Ac8/oeDqAvPuqchjQj+uruz0cI95dQ==
Date: Fri, 14 Mar 2014 17:07:43 +0000
Message-ID: <810C31990B57ED40B2062BA10D43FBF5C575A7@XMB116CNC.rim.net>
Accept-Language: en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.65.160.249]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_001B_01CF3F86.62A805E0"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dsfjdssdfsd/uBMIX2NRR0ozOKTGTivYZhpgDdc
Subject: [dsfjdssdfsd] Remove ref to DSS RNG
X-BeenThere: dsfjdssdfsd@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "The dsfjdssdfsd list provides a venue for discussion of randomness in IETF protocols, for example related to updating RFC 4086." <dsfjdssdfsd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dsfjdssdfsd>, <mailto:dsfjdssdfsd-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dsfjdssdfsd/>
List-Post: <mailto:dsfjdssdfsd@ietf.org>
List-Help: <mailto:dsfjdssdfsd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dsfjdssdfsd>, <mailto:dsfjdssdfsd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Mar 2014 17:07:58 -0000

Hi,

 

I think that the RFC 4086 sequel should drop the reference in its Section
7.2.3 to DSS RNG, or deprecate it.

 

The main reason, as I vaguely recall, is that it suffers from some form of
backtracking attack (found by somebody other than me).  Hence X9.62-2005
dropped this RNG..

 

I wonder if the following weak attack is the attack I'm trying to remember:

 

An adversary who sees the latest output X_j and compromises the current
state XKEY_(j+1) should, ideally, not be able to distinguish X_j from a
uniformly random bit string.  The idea is that current secret state reveals
nothing about past states.

 

But in the DSS RNG, an adversary can easily confirm the match by testing
that

 

X_j == G(t, XKEY_(j+1) - 1 - X_j) 

 

Assuming that (optional user input) == 0.

 

Hmm, maybe I'm wrong and just missing something obvious.  

 

I think newer DRBGs, e.g. in X9.82-3 and SP 800-90A, try to resist such
attacks.

 

Best regards,

 


Daniel Brown


Research In Motion Limited