I've now implemented folder encryption. If you encrypt folder 'foo', you get the file 'foo.encrypted'. When you decrypt it using the same tool, you get file 'foo.zip' which you download and uncompress into a folder 'foo'.
The check digits solve the MITM problem. You should compare them by another channel than email, such as text message. This is called "Short Authentication String" (SAS).
I've improved the encrypt/decrypt form. Now the textareas expand, and there's a copy to clipboard button in order to copy the output. It makes it much easier to use on the phone.
Yes, just do not write (mod p), as it can be misleading to the reader. A mathematician doesn't care, but in RFCs they call the (mod p) groups a "prime group" to differentiate it from the Elliptic Curve group. (In fact, I think they call them "prime fields", not merely groups).
I think the keys can be smaller because every random coordinate is a valid value (valid key), but in the case of RSA, valid values are more sparse.
The only way is to use another channel for the Short Authentication String (SAS) (check digits in my case). I recommend that people SMS them the check digits, and exchange the DH offers by email.
There's no difference for the MITM how I pick the Short Authentication String (SAS) (the check digits).
But there's a difference in terms of strength of the encryption key, if you are planning to use the full password as input to Key Derivation Function (KDF). If you make public the first 5 letters of a 44 letter password, you've just made lost some of the entropy.
By the way, based on a comment in this thread, I added a SHA-256 stage. I now hash the full password, and sum the bytes of the hash to generate the check digits.
I've simplified the page by creating two modes: "simple" and "advanced". By default "simple" is shown, and it's what you'd need if you are the recipient, rather than an initiator would would be normally more technical.
I've simplified the page by creating two modes: "simple" and "advanced". By default "simple" is shown, and it's what you'd need if you are the recipient, rather than initiator.
Do yourselves a favor, and read Ayn Rand. Monopolies are created by governments, and are impossible in laissez-faire. Apple has created the App store when MS was seen as a "monopoly" that no one could move. Innovations beats anyone who dominates the market. Google did the same to a Alta Vista and Lycos, just by being better.
I've made a new addition: now the operating system of the other party is also sent as part of the exchange. This info helps decide what software to use for further encryption. e.g. DMG or BitLocker? And, I managed to do it without making the string longer. I stuffed it in the unused bits of the compressed coordinate.
You are right about YouTube embed. The sw.js is sending stuff, and I don't want that. I'm going to put the YouTube into an overlay, and will remove it from DOM after it's watched. EDIT: it's done.
Note that I'm using the Elliptic Curve Diffie-Hellman (ECDH) exchaneg, which is an additive group. That's how I can get the shared keys down to a small size.
I didn't roll my own. I'm using built-in browser functionality, available under crypto.subtle object of the browser. You can review the code in my WebUtil library on Github @borisreitman. It's just a light wrapper on top of browser's functionality.
Good idea. I will change it, should be live in 1 hour. I am going to SHA-256 hash it, then add the bytes of the hash and mod by 10000. It's better than just taking the first two bytes, because I want a 4 digit number.
I'm the author. No data is sent after dependencies have loaded. The "init()" function in the page runs right after. So you can use the Network debugger to see that nothing is sent anywhere.
I just don't think an ugly page can be useful for the layman. It has to be a nice and user friendly page, which means it would have a lot of design loaded as well. Use the "_bare" page if you want to customize it for your needs.