# HG changeset patch
# User Laman
# Date 2022-04-01 13:32:07
# Node ID e2e6fc598575dc4c8703a03e924d629a46fb2f0a
# Parent  ab4439e73394e5251bf1972ec89579ae353c888d

updated readme

diff --git a/readme.md b/readme.md
--- a/readme.md
+++ b/readme.md
@@ -25,3 +25,11 @@ A 32 bytes encryption key is derived fro
 * Implementing a computation heavy function like the PBKDF in unoptimized Javascript code severly hinders its performance. Therefore its protection of weak passwords is rather limited and can't be relied upon. Then again, on my computer it achieves several thousand iterations within the alotted time, which I consider somewhat beneficial.
 * It is necessary to first derive the key before the signature can be checked. Therefore it is trivial to create messages that will take impractically long to reject when injected into genuine communication (by setting a high N). Signing with the plain password to mitigate this would remove the protection of key derivation function against brute forcing. Setting the PBKDF to a fixed number of rounds would unavoidably make it unoptimal on some devices (either high performance or low performance). So I deem the current situation acceptable.
 * 30 bytes header can make very short messages a lot longer. For special purposes it would be possible to remove the signature (16 B) or even the header altogether and rely just on the password (now with the implied condition of using a unique password each time). Acknowledging this, I still consider it wiser to always include the header for a general case.
+
+## Use ##
+
+Install the dependencies with `npm install`.
+
+Then you can test the package with Jasmine: `npm test` and bundle it with Rollup: `npx rollup -c`.
+
+Import with `<script type="text/javascript" src="main.js"></script>` and you can use `cryptoJS.encrypt(plaintext, password)`, `cryptoJS.decrypt(ciphertext, password)` and the rest of objects and functions available from `src/main.js`.