Perl 6 - the future is here, just unevenly distributed

IRC log for #rosettacode, 2012-02-22

| Channels | #rosettacode index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:53 Coderjoe_ joined #rosettacode
00:54 Coderjoe_ joined #rosettacode
01:05 chuey_ joined #rosettacode
02:22 tyrok left #rosettacode
02:41 mwn3d_phone joined #rosettacode
04:39 Coderjoe_ joined #rosettacode
05:29 mikemol server now has 4GB of RAM. squid, mysql, memcache and apache have been configured to use more resources.
05:29 mikemol Well, more memory resources. Primarily for caching.
05:31 mikemol At this point, the only thing that should be really slowing down page loads is a lack of server entropy, but I've got ideas which involve grabbing blocks of data from random.org and feeding them to rngd, tail first.
05:31 fedaykin "RANDOM.ORG - True Random Number Service"
05:40 eMBee which aspect of the site makes the random number generator a bottleneck?
05:42 sorear 07:50 <@mikemol> sorear: Entropy gets sucked up by anything requiring random  numbers. Off the top of my head, for us, that'll include  address space layout and UDP and TCP source port randomization  for things like DNS queries.
05:42 sorear 16:17 <@mikemol> Actually, it looks like ASLR directly reads from /dev/random.
05:42 sorear 16:18 <@mikemol> Third comment:
05:42 sorear http://strugglers.net/~andy/blog/2010/06/07/adventures-in-entropy-part-2/
05:42 fedaykin "The ongoing struggle >> Blog Archive >> Adventures in entropy, part 2" http://rldn.net/ETY
05:47 eMBee address space layout?
05:51 eMBee i don't quite buy this. there is nothing in the service itself (rosetta code content) except for https that may need lots of random numbers. the rest is just normal server operation. if normal server operation leads to a bottleneck in random number generation then every server out there should have this problem
05:55 eMBee of course everyone else could just be ignoring the problem, but relying on a service like random.org for normal server operation doesn't look like something that could scale
05:55 fedaykin "RANDOM.ORG - True Random Number Service"
05:58 mwn3d_phone We could also use their coil flip service to decide arguments :p
05:58 mwn3d_phone Coin*
06:00 eMBee lol
06:03 sorear eMBee: I think many (high-traffic https, virtual) servers are seeing this problem - read the link
06:51 eMBee i don't see anything in the post that suggests that there is not enough entropy to run aserver. the author states that he is in the position of providing entropy to others and not the one in need of itC[C[C[C[C[C[C
07:46 Coderjoe_ eMBee: address space randomization was added to linux systems a while ago. It makes it more difficult to exploit various security vulnerabilities because the program and all dynamic libraries are loaded at different random addresses each time they load
07:48 Coderjoe_ and the problem with rosetta code is that it runs in a VM, so it doesn't get the UI interaction to help with seeding the rng. and sometime during the 2.6 cycle, they removed a flag from many drivers that was adding to the rng pool
07:48 Coderjoe and then you have any SSL connections also needing random numbers
07:49 Coderjoe as well as SSH
07:49 * eMBee nods
07:49 Coderjoe dedicated host servers tend to have more stuff adding to the entropy pool than VMs do
07:50 eMBee still, at the end of the day a server should be able to satisfy this, otherwise everyone is in trouble
07:50 Coderjoe everyone is in trouble, but just in the form of slowdowns while more random numbers are generated
07:51 Coderjoe physical servers not nearly as much as vms
07:51 Coderjoe and the impact depends on the workload
07:51 eMBee 'hust'? i think slowdown is the only trouble that matters
07:51 eMBee erm 'just'
07:53 Coderjoe but if you use the watch command to spawn a couple processes every 0.1s, you should notice your pool drain quickly
07:56 Coderjoe i wonder if prgmr.com might be willing to set up one or more entropy servers like the guy in that strugglers.net blog did for his VPS customers
07:56 fedaykin "Linux and NetBSD Xen VPS hosting." "Main Page - Strugglers"
08:11 eMBee that would certainly be a better solution than using random.org
08:11 fedaykin "RANDOM.ORG - True Random Number Service"
08:13 maustin joined #rosettacode
08:52 Coderjoe yeah, the entropy count is chronically low right now
08:59 Coderjoe mmm
08:59 Coderjoe big entropy plunge again
09:26 mwn3d_phone1 joined #rosettacode
10:52 ttmrichter joined #rosettacode
11:45 mikemol Coderjoe: prgmr.com is very aware of and interested in the VM entropy problem. How soon they can get around to implementing a solution is anyone's guess.
11:45 fedaykin "Linux and NetBSD Xen VPS hosting."
11:46 mikemol Coderjoe: And servers aren't just in trouble in terms of slowdowns, but in terms of the quality of random numbers being used for cryptographic purposes. The recent attacks against RSA and SSL are based in entropy starvation on the hosts usesd to generate the public/private key pairs.
11:46 mikemol *used
11:59 Util joined #rosettacode
12:37 p6eval joined #rosettacode
12:43 mwn3d_phone joined #rosettacode
12:50 mwn3d_phone1 joined #rosettacode
13:59 robbrit joined #rosettacode
14:39 mwn3d_phone joined #rosettacode
16:30 eMBee joined #rosettacode
17:38 mischi joined #rosettacode
17:53 Coderjoe but if the supplier of the entropy blocks until it can supply more quality entropy, then there shouldn't be any cryptographic problems with entropy starvation other than the generation system slows down.
17:54 mikemol Except the programs generating keys are pulling from /dev/urandom, not /dev/random.
17:54 mikemol I don't know if you hear, but a whole crapton of SSL keys were found to have primes in common, severely weakening their effectiveness.
17:54 mikemol A similar attack against RSA was announced a couple days earlier.
17:56 mikemol https://plus.google.com/108080062547354628132/posts/JAQmQz42BQ2
17:58 eMBee according to an article i read today, all of those bad keys came from embedded networking equipment which didn't have good entropy sources or bad rsa implementations
17:58 eMBee http://lxer.com/module/newswire/ext_link.php?rid=162750
17:58 fedaykin "Experts: RSA weak keys flaw restricted to network devices • The Register" http://rldn.net/AbX
18:00 mikemol FTFA --> "firewalls, routers, VPN devices, remote server administration devices, printers, projectors, and VOIP phones" from over 30 manufacturers.
18:00 mikemol Lovely.
18:01 eMBee and of course those are the hardest to fix or upgrade...
18:02 mikemol I don't see that they've done the same bulk test on public gpg keystores.
18:03 mikemol That would be interesting.
18:03 Coderjoe mikemol: well, that (urandom rather than random) is a design stupidity
18:04 mikemol Never said it wasn't.
18:05 Coderjoe i must admit, it is rather interesting watching the entropy count bounce up and down on a busy web server
18:06 mikemol http://rosettacode.org/cdc3/bin/index.cgi?hostname=prgmr2.rosettacode.org&amp;plugin=entropy&amp;timespan=86400&amp;action=show_selection&amp;ok_button=OK
18:06 fedaykin "collection.cgi, Version 3" http://rldn.net/2ix
18:06 Coderjoe it would be cool to set up a graph with a data collection time of 5 seconds or so (because it changes so much over 5 minutes)
18:06 mikemol That help? ^^
18:07 Coderjoe I also find it interesting that it never managed to get up to 4096
18:07 Coderjoe highest I think I saw it go was 3589
18:08 mikemol Highest it's been in the last week was 3612.
18:09 mikemol That's probably an artifact of the amount of entropy consumed as collected spawns something to gather data.
18:12 Coderjoe if anyone is interested in watching it on their own systems, here is a very basic tool to watch the entropy size without incurring the entropy usage from spawning processes to look at the proc file: https://gist.github.com/1886409
18:14 Coderjoe I was thinking about possibly using this to stream the counts into an rrd or something, with a higher sample rate
18:36 Coderjoe I saw this awhile back: http://spectrum.ieee.org/computing/hardware/behind-intels-new-randomnumber-generator/0
18:36 fedaykin "Behind Intel's New Random-Number Generator - IEEE Spectrum" http://rldn.net/2US
18:36 Coderjoe I wonder if virtualization systems running on chips with that hardware will expose it in the VMs
18:45 eMBee quoting: "Lavarand. It got its numbers from the pictures a computer took of the waxy blobs"
18:45 eMBee does that mean i can use my photoalbum as a source for entropy?
18:47 eMBee or use photosites? you just need to make sure to use each photo only once...
18:48 mikemol eMBee: The video input types take a sequence of frames and diff them, using the diff as an entropy source.
18:49 mikemol You don't even need a lavalamp; you just cover the camera with black tape and use sensor noise.
18:49 * eMBee nods
18:50 eMBee same for a microphone i guess
18:50 mikemol Dunno. You could treat it that way if you took in N samples as a scanline, and M scanlines.
18:51 mikemol It'd still be vulnerable to harmonics, though.
18:51 mwn3d_phone joined #rosettacode
18:51 eMBee ahh, youtube, there is enough video material...
18:51 mikemol Yeah, if you need random data, load any given video of a kitten...
18:52 mikemol If you use a video source of a weeping angel for entropy, do your RSA keys become angels?
18:52 Coderjoe there are sites that put a webcam in a sealed box and use the random sensor noise as input, which they hopefully vet with some means, like the entropykey does
18:53 eMBee please don't talk of weeping angles, the scariest characters on dr who that i have come across...
18:53 mikemol Coderjoe: Check out rngd(8) from the rng-tools package.
18:54 mikemol In general, the various tools vet potential entropy with a FIPS test, sometimes before or after shoving it blockwise through a cryptographic hash.
18:55 mikemol Not sure whether the hash does any real good; a determistic process on deterministic input is still deterministic.
18:57 eMBee wouldn't the cryptographic hash need entropy itseld? thus reducing output?
18:57 eMBee itself
18:57 mikemol No; the hash is deterministic.
18:57 mikemol The same input through the same algorithm will always produce the same output.
18:57 mikemol That's why you can use cryptographic hashes to store passwords; you can't get the password back out, but you can take a password and compare it to the hashed form.
18:59 eMBee ok, true
19:08 opticron oh god...the weeping angels
19:10 mikemol They're so fun to bring up...
19:18 kpreid joined #rosettacode
19:38 GlitchMr joined #rosettacode
19:40 mwn3d_phone joined #rosettacode
20:45 saschakb joined #rosettacode
21:01 robbrit left #rosettacode
21:51 mischi joined #rosettacode
22:50 mwn3d_phone joined #rosettacode
23:35 k1o joined #rosettacode
23:35 ko1 joined #rosettacode

| Channels | #rosettacode index | Today | | Search | Google Search | Plain-Text | summary