[dsfjdssdfsd] what not to do...

=JeffH <Jeff.Hodges@KingsMountain.com> Tue, 01 April 2014 17:48 UTC

Return-Path: <Jeff.Hodges@kingsmountain.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 53CA01A098F for <dsfjdssdfsd@ietfa.amsl.com>; Tue, 1 Apr 2014 10:48:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.002
X-Spam-Level: *
X-Spam-Status: No, score=1.002 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id fWHMCk6UsDzH for <dsfjdssdfsd@ietfa.amsl.com>; Tue, 1 Apr 2014 10:48:21 -0700 (PDT)
Received: from gproxy3-pub.mail.unifiedlayer.com (gproxy3-pub.mail.unifiedlayer.com []) by ietfa.amsl.com (Postfix) with SMTP id 353721A09A8 for <dsfjdssdfsd@ietf.org>; Tue, 1 Apr 2014 10:48:21 -0700 (PDT)
Received: (qmail 19996 invoked by uid 0); 1 Apr 2014 17:48:14 -0000
Received: from unknown (HELO cmgw2) ( by gproxy3.mail.unifiedlayer.com with SMTP; 1 Apr 2014 17:48:14 -0000
Received: from box514.bluehost.com ([]) by cmgw2 with id kho81n0112UhLwi01hoB0c; Tue, 01 Apr 2014 11:48:13 -0600
X-Authority-Analysis: v=2.1 cv=QsvNgzCd c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=4eyjf-e663kA:10 a=RqnEE4ZEFZYA:10 a=3NT3xRclEPMA:10 a=N659UExz7-8A:10 a=ieNpE_y6AAAA:8 a=XYUc-DgfXtMA:10 a=1XWaLZrsAAAA:8 a=UFTA8MH_AAAA:8 a=yhGuWPCGAAAA:8 a=xEDnGs-QEFyvGJ_s3msA:9 a=Updc-xldkNicgAMX:21 a=j9M9n1rsvv-VUa6F:21 a=pILNOxqGKmIA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=HB/8/fxIJDI+Q4nv0ERI4RX+JWrzHbolMxpvHg26d+U=; b=iXrm4wyG1I3WU49z0L364H101FUs8MJ34ExW2rx/LGJfMrhEveOSbUGsLIjsd4qQju4wpWzcgnc4k6qvnzW7KYtvsb6Vbn4EkhPscZM8gcSeFRw/j/yrP9l42/Bgd85Z;
Received: from [] (port=24971 helo=[]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from <Jeff.Hodges@KingsMountain.com>) id 1WV2nB-0005N3-LV for dsfjdssdfsd@ietf.org; Tue, 01 Apr 2014 11:48:09 -0600
Message-ID: <533AFBD6.5050609@KingsMountain.com>
Date: Tue, 01 Apr 2014 10:48:06 -0700
From: =JeffH <Jeff.Hodges@KingsMountain.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130330 Thunderbird/17.0.5
MIME-Version: 1.0
To: IETF Pseudorandom Number Generator PRNG discussion list <dsfjdssdfsd@ietf.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth authed with jeff.hodges+kingsmountain.com}
Archived-At: http://mailarchive.ietf.org/arch/msg/dsfjdssdfsd/_JH-jVRkM2tb8Nisgad2gaEgUhc
Subject: [dsfjdssdfsd] what not to do...
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: Tue, 01 Apr 2014 17:48:22 -0000

 > Looking at the traffic on this list I wondered if it'd
 > be an idea to try document the things implementers should
 > not do with (P)RNGs or to generate random (sets of:-)
 > numbers.
 > It seems like there's a lot of knowledge on that spread
 > about and if there was someone was willing and able maybe
 > an informational RFC about mistakes that have been made
 > and how implementers can avoid 'em might be useful.
 > Whatcha think?
 > Or maybe that'd just generate endless debate and offer
 > no useful guidance?
 > Or maybe there's a survey paper out there somewhere
 > or thesis that already has a load of that material?

well, here's some searches...

"prng random number generator secure implementation survey"

"prng random number generator survey"

..some cherry-picked items from first few pages of results (I havent 
examined them, ymmv)...

Desai, Anand, Alejandro Hevia, and Yiqun Lisa Yin. "A practice-oriented 
treatment of pseudorandom number generators." In Advances in 
Cryptology—EUROCRYPT 2002, pp. 368-383. Springer Berlin Heidelberg, 2002.

Matsumoto, Makoto, Mutsuo Saito, Hiroshi Haramoto, and Takuji Nishimura. 
"Pseudorandom Number Generation: Impossibility and Compromise." J. UCS 12, 
no. 6 (2006): 672-690.

Schoo, Marcus, Krzysztof Pawlikowski, and Donald C. McNickle. A survey and 
empirical comparison of modern pseudo-random number generators for 
distributed stochastic simulations. Department of Computer Science and 
Software Development, University of Canterbury, 2005.