Spike the overall implementation for our encryption future-proofing

[gkc]

Is your feature request related to a problem? Please describe.

See #786 and high-level design document

• encrypted values
  • additional encrypted value metadata
    • key name used
    • cipher mode used
    • IV
    • nonce
  • value encryption and setting of metadata
  • value decryption, referring to metadata if present
• symmetric keys
  • symmetric key metadata
  • symmetric key creation
  • ability to create multiple symmetric keys and choose which one to use when encrypting data
  • symmetric key encryption and storage
  • symmetric key retrieval and decryption (support current just-the-key structure and new, json, structure)
  • symmetric key exchange
• asymmetric keys
  • asymmetric key metadata (RSA / ECC, what algorithm / cipher mode / curve / etc)
  • ability to create multiple asymmetric keys and choose which one to use when signing, or when encrypting symmetric keys for key exchange
  • ability to look up multiple public keys for a given atSign

[gkc]

Spiked changes in at_server, at_commons, at_lookup, at_client. No significant design oversights discovered, no major blockers. Spend about 2 days on this. During PR51 will focus on writing the tests to clearly specify and verify the behaviour in detail.