http://permalink.gmane.org/gmane.os.netbsd.devel.crypto hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.os.netbsd.devel.crypto/424 <pre> I'd guess that hoping for that much 'entropy' just after boot is rather wishful thinking. Delaying the generation of the keys to a later time would give a better chance of them being actually random. David </pre> David Laight 2012-09-04T06:48:41 http://permalink.gmane.org/gmane.os.netbsd.devel.crypto/408 <pre> This is very bad idea to execute code as an assert() condition. assert() is optional and if code is compiled with NDEBUG it will be turned into no-op and in your case no random data will be read at all, which makes this change dangerous. </pre> Pawel Jakub Dawidek 2012-03-04T13:20:54 http://permalink.gmane.org/gmane.os.netbsd.devel.crypto/407 <pre> I have no further comment if maintainers (responsible in doc/3RDPARTY) don't mind merge and conflicts, but I'm afraid divergence makes urgent security fixes difficult. --- Izumi Tsutsui </pre> Izumi Tsutsui 2012-03-04T08:53:09 http://permalink.gmane.org/gmane.os.netbsd.devel.crypto/406 <pre> we have way more changes to openssh and/or openssl than this already in tree. i think this case is definately worth it, considering the severity of the problem. .mrg. </pre> matthew green 2012-03-04T07:17:33 http://permalink.gmane.org/gmane.os.netbsd.devel.crypto/405 <pre> I've already started the process of feeding the OpenSSL change back to OpenSSL. I don't anticipate any problem there. I am less sanguine about OpenSSH -- after all, the genesis of the basic issue here is in the strange OpenBSD hack that guts the OpenSSL RNG. But I cannot really see any problem with less than 50 lines of local changes; our in-tree OpenSSH is already far more different than that, and I have not heard any complants about merge difficulty. Really? We have code in src/external that has thousands of lines of diffs, not just a few tens. I can't see I find this reasoning very persuasive. Thor </pre> Thor Lancelot Simon 2012-03-04T05:11:11 http://permalink.gmane.org/gmane.os.netbsd.devel.crypto/402 <pre> I'm not sure what you mean by "requires". Our RNG implementation is conservative enough to warn about the extreme entropy consumption; that does not mean the extreme entropy consumption does not happen on other operating systems, but rather that they do not tell you about it! Using less entropy while providing better security cannot possibly be a bad thing, no matter what platform you're on. And, by the way, what "large changes"? The patch is 6 kilobytes as a unidiff. Thor </pre> Thor Lancelot Simon 2012-03-04T04:57:39 http://permalink.gmane.org/gmane.os.netbsd.devel.crypto/397 <pre>When applied along with revisions 1.10 and 1.11 of libc/gen/arc4random.c, these patches should stop the excessive entropy consumption observed with OpenSSH on current and NetBSD 6-branch systems. I note that the cause of the problem is complex and somewhat amusing. Let's start from this question: why on earth are there calls to arc4random_stir() in unexpected places all over the OpenSSH sources? Before and after every fork, after exec, in the key generation routines -- in places where there are no calls to arc4random() itself and where one would hope there never had been (particularly for key generation!). The reason turns out to be that, at some point, OpenSSL (not OpenSSH) was patched for OpenBSD to make it use libc arc4random() as the source of startup key material for its own RNG. In an application like OpenSSH that does not use the SSL parts of the library and does not call RAND_seed(), that is the *only* key material for the generator. I can only guess this was done because OpenSSL was "using too </pre> Thor Lancelot Simon 2012-03-04T03:49:25 http://permalink.gmane.org/gmane.os.netbsd.devel.crypto/396 <pre> Greg Troxel &lt;gdt&lt; at &gt;ir.bbn.com&gt; writes: It seems that openssl has changed the certificate hash algorithm from md5 to sha1, and the man page even hints at this: http://www.openssl.org/docs/apps/x509.html This is really about openssl and not a NetBSD-specific issue, but people who have symlinks in CA directories will find that on upgrading that validation fails. I can't find this explained in upstream's NEWS or Changelog. </pre> Greg Troxel 2012-02-27T20:32:26 http://permalink.gmane.org/gmane.os.netbsd.devel.crypto/395 <pre> Some colleagues have been finding that "openssl x509 -hash" produces different results on netbsd-5 vs -current (late 2011). The results are consistent between i386/amd64. (The hashes are used as symlinks in a CA directory to allow finding trust anchor CA certs; we are using a private CA.) 1) Is anyone else seeing this? 2) Is there a notion that these hashes are meant to be computed/used on a single machine, or are they meant to be broadly portable? The man page doesn't explain this very well. </pre> Greg Troxel 2012-02-25T14:42:32 http://permalink.gmane.org/gmane.os.netbsd.devel.crypto/393 <pre> Right. Back in the days of the Clipper chip, Dorothy Denning posted a statement on how the escrow keys were generated (search for "chip programming" at http://catless.ncl.ac.uk/Risks/14.52.html). It shocked a lot of people because it was an algorithmic method, rather than a "true" RNG. Denning later retracted those details, possibly because she got some minor details wrong -- or possibly because she got it right. Why would NSA resort to a CSPRNG instead of a "true" RNG? In my opinion (and I suspect the opinion of the folks who wrote the standards Thor mentioned, and remember that the NIST folks who write cryptographic FIPS do talk to NSA), a CSPRNG is more secure. Why? Because we *know* what it does, all the time. "True" RNGs are devilishly hard to get right, and are susceptible to all sorts of environmental perturbations. Imagine what would happen if someone upgraded the disk to a flash disk or one with a large flash cache.... --Steve Bellovin, https://www.cs.columbia.edu/~smb </pre> Steven Bellovin 2011-12-09T22:38:59 http://permalink.gmane.org/gmane.os.netbsd.devel.crypto/391 <pre> (do we need so many lists?) I've read Thor's answer to Alan, that started: and I +1 the explanation and justification. </pre> Michael Richardson 2011-12-09T19:59:42 http://permalink.gmane.org/gmane.os.netbsd.devel.crypto/389 <pre> In fairness to Mouse, I think he's talking about something very different. I will try to address what I think he was talking about below. Let us suppose the construction of an "entropy pool" generator is simply to hash all inputs it has ever received and return the SHA1 hash as the generator's output. Now, let's say the generator's output O at time T is unpredictable -- we do not know any of the generator's inputs. (if we want B output bits such that guessing their value is as hard either as breaking SHA1 or resorting to brute force, it would suffice in fact that we not know B of the inputs; but let's say we don't know any) Now, here our generator is just SHA1. Let's say no more input arrives, but at time T1 we generate an output. It will be the same. Oops. But how to fix this is clear: we make "T" itself an input to the generator. In fact, let's say no more input arrives, ever. Now the generator's output degrades to the SHA1 of the concatenation of O and T1...Tn. It seems reasonable to cons</pre> Thor Lancelot Simon 2011-12-09T20:48:13 http://permalink.gmane.org/gmane.os.netbsd.devel.crypto/388 <pre> That's the problem. They might seem random, but they are not. They weren't designed as true random number generators, so they can't be trusted neither to generate true random numbers nor to be resistant on various attacks. For example how does your sound card handle very loud, continuous noice? Does it generate random numbers then? Does sound card manufacturers test that? No. Sound input on the other hand can be nice, one of many, entropy sources for CSPRNG. </pre> Pawel Jakub Dawidek 2011-12-09T20:18:39 http://permalink.gmane.org/gmane.os.netbsd.devel.crypto/386 <pre> I am not knowledgeable enough to comment on that, so I'll take your word for it. I like that idea. --apb (Alan Barrett) </pre> Alan Barrett 2011-12-09T19:42:29 http://permalink.gmane.org/gmane.os.netbsd.devel.crypto/385 <pre> Actually, practically all computers have true random number generators. The first problem is that neither they nor their interfaces are designed as such, so getting the randomness out of them and into the system is...interesting. The second problem is that nobody really knows just how good the resulting randomness is - that is, while there is true randomness there, nobody knows just how much information content there is in each "random" bit. (The latter is one reason for whitening input bits as they are gathered.) These random number generators are things like the turbulence inside disk drives and the noise in sound input. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmouse&lt; at &gt;rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B </pre> Mouse 2011-12-09T19:33:49 http://permalink.gmane.org/gmane.os.netbsd.devel.crypto/384 <pre>[I'm pulling together multiple mails from tls here. The second-level quotes are from varying people; I've marked their authors according to the info I have.] [Mouse] It came reasonably close. To be certain of it, yes. It should have been done that way, and I would support changing it to be done that way. What it actually was is a hybrid. [Alan Barrett] Only sort of. Not entirely, in two respects: (1) provided you don't draw on the pool for more bits than it has information content, you are in principle getting information out. If the mixing function is good, you will actually be doing so. (2) If you are stirring new randomness into the pool in the meantime, it...complicates things; it is no longer a pure PRNG. To an approximation as good as the mixing function is good, you can draw on the pool as much as you like, provided you never draw enough to reduce the information content to zero. I'm not particularly happy with the old mixing function; see below. I would much prefer to do what you su</pre> Mouse 2011-12-09T19:23:34 http://permalink.gmane.org/gmane.os.netbsd.devel.crypto/383 <pre> You are aware of the fact that 99.99% of computers don't have true random number generators and the bits you claim that are random are not random at all? They try to be unpredictable. CSPRNG have two roles: turn few almost unpredictable bits that your machine can gather into many cryptographically secure pseudo-random bits and to hide those almost unpredictable bits from consumers. Returning gathered entropy directly is very, very risky. For one, CSPRNG output bits generated based on many entropy sources. If one of your entropy source is for example time intervals between interrupts, an attacker could provoke interrupts to occur at very predictable for him intervals. If such entropy would be returned directly to /dev/random consumer, it will be easly compromised. CSPRNG protects you from situations when some of your entropy sources are controlled by an attacker or broken (this is also valid for true random number generators, which can simply break). </pre> Pawel Jakub Dawidek 2011-12-09T17:59:13 http://permalink.gmane.org/gmane.os.netbsd.devel.crypto/379 <pre> Look at the implementation. It *never* worked that way. To cause bits to actually be "taken out", you'd have to maintain two pools, discard the entire contents of one every time any bits were revealed to userspace, and switch to the other. Or something along those lines. And that's just not how it ever worked. Thor </pre> Thor Lancelot Simon 2011-12-09T16:02:35 http://permalink.gmane.org/gmane.os.netbsd.devel.crypto/373 <pre> tls&lt; at &gt;panix.com said: I wasn't thinking of runtime indirection. Just a build time option, let's name it "ARC4RANDOM_IS_OK", and then some #ifdefs where cprng_strong/fast are defined. The strong cprng code could then be pulled in with a !arc4random_is_ok condition in files.*, and the condition for rijndael would be OR'ed with a similar one. best regards Matthias ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------ Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt --------------------------------------------------------------------------------------------</pre> Matthias Drochner 2011-11-09T19:51:35 http://permalink.gmane.org/gmane.os.netbsd.devel.crypto/368 <pre> Well, no. But it is now. Sorry about that. Thor </pre> Thor Lancelot Simon 2011-11-07T17:10:22 http://permalink.gmane.org/gmane.os.netbsd.devel.crypto/364 <pre> There's a new patch at http://www.panix.com/~tls/rnd4.diff which I intend to commit as soon as I find and fix one remaining bug. This version of the patch adds some infrastructure the new random/urandom pseudodevices will need and addresses several nasty race conditions around rekeying by changing the rndpool mutex from IPL_SOFTCLOCK to IPL_VM. It also fixes several miscellaneous bugs (including a severe one in rnd_add_data that has been around for a long time) and addresses KNF issues in my previous patches. There are also a few performance tweaks. The mutex change to IPL_VM should not have much performance impact as it's never held during copy in/out and my next set of changes will eliminate any direct access to the entropy pool (thus any taking of the mutex) by the pseudodevices -- that is, from userspace consumers. The bug which remains is this: * With a LOCKDEBUG, RND_VERBOSE kernel, run the "arandom" test program, which reads as much data with sysctl kern.arandom as it can, in a tight loo</pre> Thor Lancelot Simon 2011-11-07T06:22:42 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.os.netbsd.devel.crypto