[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 []) 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-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 ([]) by localhost (ietfa.amsl.com []) (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 []) 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 ([]) 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-originating-ip: []
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



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


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


Best regards,


Daniel Brown

Research In Motion Limited