Naming conventions

[silkeh]

As golint helpfully points out:

func name will be used as randombytes.RandomBytesSeedBytes by other packages, and that stutters; consider calling this SeedBytes

It gets especially cumbersome with functions like: cryptoaead.CryptoAEADAES256GCMEncrypt.

Additionally, overlap in naming with with crypto/nacl could result in making this library a drop-in replacement.

I think the most convenient way to structure the packages would be crypto/box, crypto/aead/aes256gcm and crypto/stream/xsalsa20.

Renaming, however, does break backward compatibility in a major way.

[redragonx]

There are two sides to this, ideally this should follow Go idioms. However, there are a few projects that rely on this library. Most notably, SpiderOak's Semaphor.

At some point we should rename the folders though, perhaps a new branch for a 2.0 version? But Go does not support different versions of the same library very easy.

#23

[silkeh]

It is not necessary to rename existing files immediately because the package names do not clash. They can exist side by side and they could be deprecated at some later date.

I noticed it eases development greatly to change the naming scheme. Especially because the tests are more portable. I have wrapped all crypto_aead functions in separate packages in a branch as an example. (This branch also makes other backward-breaking changes like returning bool instead of int.)

[redragonx]

I merged #31 but we should write something about the new structure, otherwise people may try to use both sets of the AEAD functions.

I may create a version with just the new AEAD structure.