From owner-svn-src-head@freebsd.org Mon Apr 17 04:35:15 2017 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 67714D41DC9; Mon, 17 Apr 2017 04:35:15 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "anubis.delphij.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 445D4195D; Mon, 17 Apr 2017 04:35:15 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from Xins-MacBook-Pro.local (ip-64-134-178-180.public.wayport.net [64.134.178.180]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by anubis.delphij.net (Postfix) with ESMTPSA id 784EA2E10E; Sun, 16 Apr 2017 21:35:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1492403715; x=1492418115; bh=aRJiT37hLvsYFVitlMiJC94pIHA6Fyb/eRtVJYOyf+s=; h=Cc:Subject:To:References:From:Date:In-Reply-To; b=A1Od69+ZTVJF/7xJOabbdYIoLE7/mV+DO4LBb4jwHzxelkaDpa28u5nXEH5XTCd1h UuSYJltxw2e3+MQyvG+6TzBPQ/lm1nbo/wNAxI+B4PnQJk11gPhBFs7pumVIM4U87p JJrRcl+2fq1xIjp9n38FYoCdya2xSU40Gs+ibPkU= Cc: d@delphij.net, src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r317015 - in head/sys: boot/forth conf crypto/chacha20 dev/random libkern sys To: rgrimes@freebsd.org, Mark R V Murray References: <201704161230.v3GCUujl016578@pdx.rh.CN85.dnsmgr.net> From: Xin Li Message-ID: Date: Mon, 17 Apr 2017 00:35:10 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 In-Reply-To: <201704161230.v3GCUujl016578@pdx.rh.CN85.dnsmgr.net> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="dTuQLg0JkVfFFEBSOEmOpKLbQJRxxq7SF" X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 04:35:15 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --dTuQLg0JkVfFFEBSOEmOpKLbQJRxxq7SF Content-Type: multipart/mixed; boundary="bwRDKMbUGeHxcAG2WQ4Tu8b8LqcgqABN1"; protected-headers="v1" From: Xin Li To: rgrimes@freebsd.org, Mark R V Murray Cc: d@delphij.net, src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org Message-ID: Subject: Re: svn commit: r317015 - in head/sys: boot/forth conf crypto/chacha20 dev/random libkern sys References: <201704161230.v3GCUujl016578@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <201704161230.v3GCUujl016578@pdx.rh.CN85.dnsmgr.net> --bwRDKMbUGeHxcAG2WQ4Tu8b8LqcgqABN1 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 4/16/17 08:30, Rodney W. Grimes wrote: >> >>> On 16 Apr 2017, at 13:07, Rodney W. Grimes wrote: >>> >>>>> From replacing the rc4 algorithm with chacha20, this chalice has no= w >>>> become poisoned with the job of redesigning the entire structure of >>>> kernel random-number generation. >>>> >>>> This may take a while, and I'm already behind on RNG jobs. >>> >>> I do not see how this is a complete redesign of RNG, and if it is >>> such a heart ache to change algorithms in this code then it probably >>> should be redesigned? >> >> The RC4 algorithm is standard. Making the alogorithm pluggable means m= ore >> code, more testing and more time (time which I am rather short of). >=20 > I would rather see a proper implementation later, than a poor design > decision today. I don't see how not supporting pluggable algorithm for the kernel arc4andom() a poor design decision. We are supposed to make good algorithm choices, making it pluggable would only make the code much more bloated (to make the load/unload PRNG seeding right), less efficient (to allow caller to safely call the interfaces) for something that system administrators should never fiddle with. Cheers, --bwRDKMbUGeHxcAG2WQ4Tu8b8LqcgqABN1-- --dTuQLg0JkVfFFEBSOEmOpKLbQJRxxq7SF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJY9EYBAAoJEJW2GBstM+ns4vUP/jj025mSLy1zEdkdJQcrRsSv 5mfbfk1u9JLD5aFl2o876hLebe6d5xUwRZWYHL0JUSTO6SpoWODp/Qs66A93ZGbg GL7gnX3JD7A9hd1U1f5sY6uGCm3wOc2Y26gZIBk2PaO8MEe2ulBnWnAuQ8EiYVlx l4dE1pkXltRJVwujllFGJIhYnCbrpwz0nSFlRcWz5skbA5ALuTEpEgfkG4qhb63i zmKouALnpuN+XtJMTJc6044+8BCHKNyP6oxfqKcNB4AV709TRIpa61uQh1BhyYSl 1ucbHYH0WsJmVTMaXLzSZ1tjkdwIlwbCLbauduSW25VruEWTUqRA+/QBcRgtKTcI 71uhiUK4RSv/g35FeKOVVYYaXDx38uEuJ1cvlY5217RUk4jpfyk+ytw/k2+5b6X3 hI3+05MEQAYgSJeWwtNVEd3QsR3WNLDD/zdQ0o39eq08Rms7KklfixDp08mYDTRT 8ljKeCwFvtMkGC3NzviCX81JC0YpfgNkIPYqpLPQODRqPk4vNMc2ga1fbmWl1fJm m4eeg5Q1P9E586tZYx0UcHeBkOWIXLX0d/6y3HZz1c9EpDOzwsPB8aksguSEXzLS MNVQ333/2I9bmSrTGheYng/9jkCVfe+v2DQ/gD7TM5FrQtz+KfvERoVX5iHloL/L Y925PzaPBdRG3BF9jZsm =v3CT -----END PGP SIGNATURE----- --dTuQLg0JkVfFFEBSOEmOpKLbQJRxxq7SF--