I am no kind of crypto expert, but from what I read, there are no known attacks on chacha8 or salsa20/12 better than brute-forcing the key, and distinguishing the stream from random or deducing state would be considered an attack.  There's a summary of the ESTREAM cipher's security here:

http://cr.yp.to/streamciphers/attacks.html

-- be aware it was written by the chacha/salsa author, so may be biased.

> I'm not sure I follow the notes on state size.  Is it 320 bits + 64 bits or is it 512 bits?

Yeah. The state is contained u32[16], so the 512 is sizeof(that).  320 + 64 is the number of states I can see it getting into from the seeds and cycles.  I imagine the discrepancy is a convenience, just as the mt19937 struct uses a few more than 19937 bits.

> With respect to the SIMD optimizations and longlong to double operations, I'm curious to take a look at how it was done yet wonder if there is a provable, portable implementation and also wonder if it is worth it (the speed of generating a random() tends to be dwarfed by surrounding code that actually uses the result -- allocating the python object, etc).

I agree that it is not worth it.  However the dSFMT generator does seem quite portable and fall back to non-SIMD code (which is allegedly still faster), and its distribution is supposedly a bit better -- though not as good as WELL.

The bit magic is quite simple: if you set the top 12 bits to 0x7ff and randomise the other 52, you get a double in the range [1, 2).  So you subtract 1.  It costs one bit relative to the current method, which is equivalent to 53 bit fixed point.  They explain it reasonably well in these slides:

http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/dSFMT-slide-e.pdf