Document thread safety.

README.md

@@ -59,6 +59,9 @@ Crystal bindings for the [libsodium API](https://libsodium.gitbook.io/doc/)
   - [x] All SecretKey's held in libsodium guarded memory.
   - [x] No heap allocations after #initialize when possible.
   - [x] Fast.  Benchmarks available in `benchmarks`.
+  - [x] [Most classes are safe to share between threads.](THREAD_SAFETY.md)
+    - [x] Tested with real crystal threads and will continue to work when crystal officially supports threading.
+  - [x] Most classes are safe to share between threads.  Even
   - [ ] Controlled memory wiping (by calling `.close`)
 
 ☑ Indicate specs are compared against test vectors from another source.

THREAD_SAFETY.md

@@ -0,0 +1,36 @@
+### Tested and provably thread safe.
+
+* Sodium::CryptoBox::*
+* Sodium::Cipher::Aead::XChaCha20Poly1305Ietf 
+* Sodium::SecretBox
+* Sodium::Sign::*
+
+Notes:
+* Only uses stack allocation.  Keys are stored in readonly memory.
+
+
+### Thread safe when hashing, deriving or creating keys **after** setting parameters.
+
+* Sodium::Password::Hash
+* Sodium::Password::Key
+* Sodium::Password::Key::Create
+
+Notes:
+* Don't change parameters between threads without a `Mutex`.
+
+### Keeps state.  
+* Sodium::Cipher::Chalsa subclasses.
+* Sodium::Cipher::SecretStream
+* Sodium::Digest::Blake2b
+* Sodium::Kdf
+
+Notes:
+* Use one instance per thread or wrap in a `Mutex`.
+
+### Not thread safe.  
+* Sodium::Nonce
+
+Notes:
+* Use `Nonce.random` with multiple threads or let the API provide the nonce's for you.
+* #increment isn't safe, not even when wrapped in a mutex unless you also wrap #encrypt/#decrypt within
+the same #synchronize call.