Under the hood, once encryption is performed, the version number, encrypted data, salt and IV (if randomly-generated), and hint (if given) are JSON-stringified and base64-encoded for storage in the URL fragment. There is a hard-coded default salt and IV if the user chooses not to randomize, which means they don't need to be encoded in the object that is eventually stored in the URL, thus making the generated URL shorter.
Based on your comment, it seems hard-coding an IV and giving the user the ability to disable randomization may unnecessarily make unwitting users vulnerable. Would you recommend I remove the ability for users to disable randomization moving forward? Do you think I should just add a big warning if they try to uncheck the box instead? I'm open to suggestions.
In general, I'm very interested in all recommendations for best-practices, as the tool is under active development, and is a learning opportunity for me.
Yes. There's not a great reason to disable the randomization here. You're safe if each link uses a new key, but if it was possible for a user to use the same key and IV for a different link, an attacker with access to the first link could now use it to access the second.
https://en.wikipedia.org/wiki/Stream_cipher_attacks#Chosen-I...
Since you're deriving keys via a password, that would mean that two Link-Lock URL's protected with the same password _and_ using the same hard-coded IV would be vulnerable.
It's likely an infeasible attack, but definitely worth giving a warning to those who really want to cut back on those 20-25 characters.
Though since the URL fragment has _encrypted_ content, I think the users should understand up-front that the URL's will be long; it's impossible not to.