This functionality moved in to readShareFromBucket

We need a lot of type conversions and we'd like to be more principled than
`fromIntegral`.

We use `isolate` so we know exactly how far we've advanced, we can trivially
compute the correct position.

instead of confusing it with the segment length sometimes, which includes
padding bytes

The trick is that we don't use the IV to initialize CTR mode, we only use it
to derive the data encryption key and then use the zero IV to initialize CTR
mode.  (So is it an IV?  Not really I guess.)

The failure is due to incorrect handling of padding somewhere so we get extra
bytes on the recovered ciphertext/plaintext.

It doesn't have an assert but it prints the wrong output

Add simple SDMF capability representation

See merge request !6

Add a Keys module with types and derivation functions

Closes #6

See merge request !5

* Add direct tests for signature key serialization/deserialization
* Fix the RSA Private Key serializer to use PKCS8 like Tahoe-LAFS expects.
* Fix the key generator to emit keys in this format.
* Fix the key generator to generate 2048 bit keys.
* Fix the derivation functions to make the key values internally consistent.

The previous keys were not serialized as x509 Private-Key Info structures
which is the format Tahoe-LAFS expects us to operate on.

Standardize on cryptonite

See merge request !4

The test suite fails, though.

This is probably better than pulling in three different crypto libraries for
each of the difference pieces we need.  It's certainly simpler to figure out
how to make the pieces play nicely together since we avoid having multiple
kinds of AES128 key defined, multiple types named IV and PublicKey, and even
multiple implementations of the same module.

need to move the key stuff to a new branch and finish it on its own probably