Date: Mon, 17 Apr 2017 00:35:10 -0400 From: Xin Li <delphij@delphij.net> To: rgrimes@freebsd.org, Mark R V Murray <markm@freebsd.org> Cc: d@delphij.net, src-committers <src-committers@freebsd.org>, 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 Message-ID: <ffd26fa4-a497-7708-f106-b56f1f2ef8f5@delphij.net> In-Reply-To: <201704161230.v3GCUujl016578@pdx.rh.CN85.dnsmgr.net> References: <201704161230.v3GCUujl016578@pdx.rh.CN85.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --dTuQLg0JkVfFFEBSOEmOpKLbQJRxxq7SF Content-Type: multipart/mixed; boundary="bwRDKMbUGeHxcAG2WQ4Tu8b8LqcgqABN1"; protected-headers="v1" From: Xin Li <delphij@delphij.net> To: rgrimes@freebsd.org, Mark R V Murray <markm@freebsd.org> Cc: d@delphij.net, src-committers <src-committers@freebsd.org>, svn-src-all@freebsd.org, svn-src-head@freebsd.org Message-ID: <ffd26fa4-a497-7708-f106-b56f1f2ef8f5@delphij.net> 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 <freebsd@pdx.rh.CN85.dnsmg= r.net> 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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ffd26fa4-a497-7708-f106-b56f1f2ef8f5>