DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:message-id:date:to:from:subject:mime-version
	:content-type; q=dns; s=default; b=KveTp7zNI4bXhS8iqwkKtQQrdmfBw
	Yj8CbQMRyr9vYCws4A07vsikAi7Bjg51n9vs62FjP1kHw3NA3gC/K/OtqUrej4km
	Yrj/JrtQDWnCbSvwOtBepTFe70kfgHhuE94Zic8I2N6Y+ANG5m2sp0p0LyQnL+PI
	0y2t6e+serZlac=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Message-Id: <6.2.5.6.2.20130918150156.03a25770@binnacle.cx>
Date: Wed, 18 Sep 2013 15:02:41 -0400
To: cygwin AT cygwin DOT com
From: starlight DOT 2013z3 AT binnacle DOT cx
Subject: /dev/random does not block, emits poor entropy
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Received-SPF: pass (mx.binnacle.cx: 172.29.87.10 is whitelisted by SPF-milter whitelist entry)

I see that CryptGenRandom() does not appear
to have parameters to detect or control
the quality of entropy.

So possibly the correct solution to this
issue would be to eliminate

    /dev/random

and just leave

    /dev/urandom

in place.  'openssl' apparently uses /dev/urandom.

If someone needs to fake /dev/random they
can create a symbolic link for it,
knowing the risks they might be taking.


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple