Date: Sun, 16 Apr 2017 09:04:36 -0700 (PDT) From: "Rodney W. Grimes" <freebsd@pdx.rh.CN85.dnsmgr.net> To: Mark R V Murray <markm@FreeBSD.org> Cc: rgrimes@FreeBSD.org, 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: <201704161604.v3GG4aoq017437@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <D72BDB55-A5E0-4E6B-89C5-1ABAB00CACAC@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > On 16 Apr 2017, at 15:21, Rodney W. Grimes <freebsd@pdx.rh.CN85.dnsmgr.net> wrote: > >>>> RC4 has been standard for many years. > >>> Probably another rapid mode of design rather than a thoughful mode, we > >>> have a chance to correct this here, and imho, should. > >> > >> Fix it, sure. What's wrong with doing that as a next step? Why does this > >> change need to be held to ransom? > > > > Thats a fair point, let me counter, why do I want this change at all? > > RC4 is broken cryptographically. FreeBSD was lagging behind in still using it. > > > Is it just the new kid on the block and everyone wants to play with the > > new toy, or does it bring the users some wonderful star bright feature > > that they just can not live without? Is arc4random(9) some how fundementaly > > broken without chacha? > > Most folks won't notice a darn thing. Crap random numbers are very often > hard to tell apart from good ones, and if you are not depending on them in a > relevant way you won't notice anything. > > The big deal is that the attack vector for folks counting on (broken) > RC4 is now gone. For most FreeBSD users this is theoretical interest only. > > > Your code in and working now? > > Yes. > > > We just have 2 implementations of chacha, correct? > > Correct. > > > One in your static compiled in kernel section, and one as an LKM? > > Correct. The latter startled me when it arrived. So you can understand me being started when any of this arrived? I am on several of the mailling list, and I think -security is probably one of them. > >>>> Up until now, arc4random worked with unconditional RC4. > >>> > >>> And your wanting to just replace unconditional RC4 for unconditional chacha? > >>> Or actuall, aleady did? > >> > >> Correct. Both counts. It was up on Phabricator for weeks, BTW. > > > > We are having what I believe is a very serious disjoint in project communications > > caused by phabricator. How are the developers notified of new things going > > up in phabricator? I get bugzilla reports, but I get zip from phabriactor unless > > I go ask it for stuff. I get #network stuff cause I saw that in a commit that > > I would of liked to been aware of early and added into that project, but overall > > I think we need to work on this communcations too. > > True. I promised SO@ that I would get all my CSPRNG stuff reviewed in Phabricator > before committing it. All the folks who in the past have cared about my work now > are on the relevant watch-list. Apart from spamming everyone, what do you suggest? Yellow paint? Allan Jude informs me I have used all the blue paint. I wish I had a simple answer for that, but from looking at reviews post commit I notice we are getting more feedback on the commit list than we are getting pre commit in the review process, this leads me to believe I need some more Yellow paint so we can build a bike shed around how do we attract pre commit review activity? What watch list is this? And do we have a watch list that is just "New Phabricator created" so we can make just that incident go to some mailling list so people stop getting caught off guard by commits that have been reviews that they wish they had even known there was a review? We just need a way for being allerted there is a new review that we *might* be interested, or care to participate in without being on all the watch lists. And to add my hidden Blue Paint, we need to stop fearing the bike shed, the project seems to have stifled the communications process to the point it is becoming a closed door shop with everyone working in secret then dumping a commit in once they are done. Yes, bike sheds are a bit time consuming, but so is duplicate work cause you had no idea someone else was working in the same area (your LKM suprize is an excellent example). We must stop working in vacuums and start to communicate, and if that means we have a few bike sheds... well.. paints on me (though I reserve the blue for personal use!) -- Rod Grimes rgrimes@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201704161604.v3GG4aoq017437>