3 ms·

Thanks for your comment! The basis for the feature is that it makes the generated URLs a few characters shorter – empirically, savings are on the order of 20-25

Thanks for your comment! The basis for the feature is that it makes the generated URLs a few characters shorter – empirically, savings are on the order of 20-25 characters. Minor for most, but I don't purport to know what users will do with the tool, or if this length will make a difference. 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.

sarakayakomzin 6y ago
>it seems hard-coding an IV and giving the user the ability to disable randomization may unnecessarily make unwitting users vulnerable 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-IV_attack https://en.wikipedia.org/wiki/Stream_cipher_attacks#Chosen-I...
tptacek 6y ago
I haven't looked carefully at the design; in fact, I've only read enough of the code to see that there's a flag to disable IV randomization. I'm only here to say that GCM is completely insecure if IVs are ever reused. https://toadstyle.org/cryptopals/63.txt https://toadstyle.org/cryptopals/63.txt
prophesi 6y ago
A hard-coded IV with AES-GCM is bad only if you're encrypting content with the same key. 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.

sarakayakomzin 6y ago

>it seems hard-coding an IV and giving the user the ability to disable randomization may unnecessarily make unwitting users vulnerable 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-IV_attack https://en.wikipedia.org/wiki/Stream_cipher_attacks#Chosen-I...

tptacek 6y ago

I haven't looked carefully at the design; in fact, I've only read enough of the code to see that there's a flag to disable IV randomization. I'm only here to say that GCM is completely insecure if IVs are ever reused. https://toadstyle.org/cryptopals/63.txt https://toadstyle.org/cryptopals/63.txt

prophesi 6y ago

A hard-coded IV with AES-GCM is bad only if you're encrypting content with the same key. 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.