From mboxrd@z Thu Jan 1 00:00:00 1970 From: Leo Famulari Subject: Re: /dev/urandom Date: Tue, 10 Jul 2018 18:40:20 -0400 Message-ID: <20180710224020.GA32066@jasmine.lan> References: <20180710182211.75442f8b@scratchpost.org> <20180710182809.GA13244@jasmine.lan> <20180710205843.68793bed@scratchpost.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="DocE+STaALJfprDB" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:42780) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fd1J5-0000LB-8m for guix-devel@gnu.org; Tue, 10 Jul 2018 18:40:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fd1J1-0001YG-Un for guix-devel@gnu.org; Tue, 10 Jul 2018 18:40:27 -0400 Received: from out1-smtp.messagingengine.com ([66.111.4.25]:51703) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fd1J1-0001Y1-QC for guix-devel@gnu.org; Tue, 10 Jul 2018 18:40:23 -0400 Content-Disposition: inline In-Reply-To: <20180710205843.68793bed@scratchpost.org> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Danny Milosavljevic Cc: guix-devel@gnu.org --DocE+STaALJfprDB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Jul 10, 2018 at 08:58:43PM +0200, Danny Milosavljevic wrote: > It writes an image file. Since that image is later written to flash storage > (by the user), the program randomizes the data in order to increase longevity. > Then it stores the random data used as well. I see. Like Ludo and Mark, I think we should avoid doing tricky things with urandom. Could /dev/zero work here? Does it use urandom once, to get a seed, or does it read urandom repeatedly, expecting different values each time? Also, I wonder if Guix users would want reproducibility here instead of longer-lived NAND storage. --DocE+STaALJfprDB Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEsFFZSPHn08G5gDigJkb6MLrKfwgFAltFNdEACgkQJkb6MLrK fwgb0w/+Kqa33qkpd+zN0ZnI4obQmCFQ3Rw1Lp+1Wcqcg2AUvHoe9VRwT3m5ByCU 9SMqx4y92hablmh496BVlr+QO4j7zAMEf+Kzb9TgyH0lUlcXFd7FvIuvQWa1VHkH +Bx/HgW9kExNEYsQobkLtScUwcRWmMct+SkamPrVOxBPW34BnJ/4jOMghgKh0tKb K1fcq4jQX5BT4Op2qWKybSYKPCO3Wzlgusqt5ov+JUHRNLxmxivzT3S2uRFrMtQb 04n6kg3QBthWKVdky9V6dJMoGJtjhTn8coPQI9mlQxg7nqYw5CzU2hwIoJmJj77k 1Wokb9fn3pr85hPY2fScU5VxDTxhR8dYvwRW/qY4yqbcjnYEg7iH9WTrvg5+FST2 YOzUwO4QSBVmrIJgC8ey8UBiAEKiuU36IQ8CLYr4IPTBmkowf7RwjUjG72mtyAIJ A/ro8Q2abnjbiSNtgdTs9ci9iP36g4ydneirO0WzkiBcaR2hgomj4P9cKDOccH8C oQXcUhpy0nYDgZiFuAepckrns0ZJGJn5onk3cK+ivFH4Kk4O2yPiouQ/dAvr5JIg gF0DtwZlUKL1VhZMg1+GoNYEmqRDqRpYQyx2X7y4FvCY1UOOoS4LPtSjmU37xE06 bIYXrMVU44hMBwtU3owDUaf6BDdsuZFKCsEW8/kcUQy/jYX6GIk= =2Biz -----END PGP SIGNATURE----- --DocE+STaALJfprDB--