You are currently using the pbkdf2 algorithm for derive the encryption key (obviously for encrypt the message/token). PBKDF2 is a key derivartion function designed for use when the master key is not Cryptographically secure, such as passwords. Using it implies a lot of overhead in message encryption in a use case of this library. My recommendation is switch to other policy of deriving a encryption key.
This is my proposal:
General notes for master key management:
Add a master key validator for ensure that user sets a truly cryptographically secure master key (50-100 chars of random strings as example).
Derive a master key (string) to bytes using some hash function: sha512 or sha3-512 or arbitrary length hash functions like skein.
Use HKDF as key derivation function (instead of PBKDF2)
One time (per message) key derivation procedure:
Generate 32 or 64 bytes salt using CSRNG (using SecureRandom in java).
Create an instance of HKDF with your master key and the secure random salt previously generated.
Derive a 256bits (32bytes) encryption key.
Derive 128bits (16bytes) IV.
Encrypt the message using the previously derived encryption key and iv.
Build the final message with encrypted message and salt (the rest of information can be derived from master key and salt, so, iv can be simple omitted from final concatenation step making the message slightly shorter)
We can speak in the office about this if something is not clear.
You are currently using the pbkdf2 algorithm for derive the encryption key (obviously for encrypt the message/token). PBKDF2 is a key derivartion function designed for use when the master key is not Cryptographically secure, such as passwords. Using it implies a lot of overhead in message encryption in a use case of this library. My recommendation is switch to other policy of deriving a encryption key.
This is my proposal:
General notes for master key management:
One time (per message) key derivation procedure:
We can speak in the office about this if something is not clear.