note that IBAA64 exists; clarify bad IBAA states a little
OpenBSD: s/RC4/ChaCha20 (todo)
Fixed IA initialization; IA ok on non-32 bits

IA only needs the bits in a word to be >= 2*ALPHA, which is ok
because ALPHA==8 by default and vim guarantees when it is compiled
to pick an integer type that's >= 32 bits wide.

My old misinterpretation that we needed 2*ALPHA bits **set** in the
internal state stuck for so long because it didn't make sense - I
couldn't see where on earth it came from, and it puzzled me, so I failed
to notice that it just wasn't there.
The fact that IA sucks at getting out of "zeroland" made the
misunderstanding look more plausible, as I was focused on IA vs IBAA
("ok, IBAA fails with all zero, but why does IA need 16 bits instead?")

The idea for the proof was suggested by reading the ranrot paper
available at http://www.agner.org/random/theory/chaosran.pdf;
my previous idea was much more complicated.

The naming "IA()", "s:ia()" is confusing.
Note that IA may be meant to generate bytes...

That would explain the "ALPHA-bit terms" comment, and make the
relationship to RC4 clearer, but I still don't care:
- he didn't provide an inizialization routine
- the state is noted to be 32 bits
- it's a perfectly fine PRNG, even in scaled down versions.
The only flaw is recovering from an excess of 0s, which btw is what
got me thinking that maybe he meant IA to be initialized kinda like ARC4
-- but then what do you do to the upper bytes? You __need__ them
for "r[i] = b = m[ind(y>>ALPHA)] + x;" to be considered pseudorandom...
IBAA comments
Added djb's ChaCha20

I'm not knowledgeable enough to appreciate the fine differences between
salsa20 and chacha20, but the papers explaining them are amazingly
useful (and quite readable by any programmer); they do a better job at
explaining the rationale behind the design decisions than even the rc6
paper did, and they're interesting anyway.

And Btw, since Nov2013 I've been trying to indent with eight spaces,
based on a comment by Linus Torvalds saying that it made code look
clearer and bad code smell worse; up to now it's been great in C,
a bit weird in vimscript, keep 4spaces in java/C#/python.
Tabs are evil (unless you specify a tabsize like linux), but eight
spaces were surprisingly comfy.

With that out of the way, a couple of words on a bug that made me waste
a couple of __hours__ yesterday.
I had the chacha code ready last year, and didn't commit because I
didn't want to do so without test vectors, and I was just lazy.
I "knew", by running by hand the first few iterations, that it "worked"
when given key/iv all zero.
The test vectors were part of a big document, so yesterday I set out
to -- finally! -- convert & add them. Bummer.
The results disagreed (well, actually it would agree, then disagree for
a while, then agree again, then....).
I spent ~2h looking at chacha.vim line by line, checking for any stupid
typo or whatever.
Notice that the test vectors in chacha.vim are >1k lines, so I hid them
in a fold -- big mistake! See stackoverflow about C#'s "#region"...
The bug was in the awk script used to convert the testvectors(*),
which dumped the key ("0x00 0x00 0x00...") by
        for(i = 0; i <= NF; i++) {
                printf("%s" $i)
        }

In case you don't speak awk: $i is the i-th field; $0 is the whole line!

It was stupid of me to add the commas in a sed script (thus hiding the
problem); it was stupid of me to doubt chacha.vim (I had just written
the script, why did I assume it just worked?); it was dangerous to hide
the data with those goddam folds -- when I got back to C and printed the
test vectors myself I was doubly puzzled, because they agreed with my
vimscript and made the test vectors look wrong; looking at what was
under the folds I saw the super long lines and realized IMMEDIATELY what
was wrong.
It was also stupid to go on debugging without stopping for a while and
try to, err... rubber-duck-debug?

(*) why convert rather than regenerate? because I thought
    that someone else may be using that format, so I'd only
    have to write the script once.
add chacha to bench.vim
Added sha256() since it's shipped by vim.

Funny thing is that it's usually considered super slow...