Proposal: KeyPair should not use byte[] for the private key

[danielcrenna]

In order to facilitate secure memory solutions, KeyPair:

• should not copy a given private key into a byte array to make it suitable for KeyPair storage (i.e. in factory methods ala Curve25519.GenerateKeyPair
• should not use managed buffer.Clear() to zero out memory on disposal, rather deferring to something like libsodium_free

This is a pre-requisite for enabling secure memory scenarios in this library, and could work for PSKs in the Protocol API methods.

[Zetanova]

danielcrenna's commit 6c5fdb6

[Zetanova]

The nsec.net lib uses libsodium too and has the reverse problem.
See ektrah/nsec#31

[ektrah]

Fwiw, I think it's totally the right way to do (passing keys around as KeyPair instances rather than byte arrays & storing private keys in sodium_malloc'd memory). The "problem" I'm facing with NSec is that API users are consistently undermining this by recreating the KeyPair instances from byte arrays on every single library invocation. I guess this might be less of a problem in a Noise implementation, which will probably more likely expose a "HandshakeState"- or "Connection"-oriented API rather than an "Algorithm"- and "KeyPair"-API.