71–80 of 142 posts
Earlier quoted context omitted.
I'm not a programmer. Why can't you just digest or hash the JS?
Just curious : what does a non-programmer come to HN for? Everything seems fairly programming centric to me here...
I'm technically minded though--chip designer. Software is a hobby for me. I guess I more meant that I'm not a JavaScript programmer and don't know the subtleties of that ecosystem.
It's nice to see so many projects attempting to solve this problem. I have a question specific to the documentation on the main page: Private keys are stored on the server in encrypted form. The key derivation function used is as follows: K = scrypt(Passphrase, Username) I'm going to skip the "JS crypto is bad". What I'd like is clarification of the Zero Knowledge section that the keypair is decrypted client-side onl…
Why go through all the trouble of attempting strong client side crypto, only to store the private key secured only by a passphrase on the server?
Earlier quoted context omitted.
Two big questions: 1. How do you revoke a compromised signature comitee certificate embedded in the browser extension? 2. How can you prevent a hostile browser extension from hijacking the validation process?
3. How do you prevent secret agents from looking in your window with binoculars?
If it had just been a technical risk or a financial risk to myself I would have pursued it, but some risks are heavier than others.
Earlier quoted context omitted.
Yeah, I read your Matasano post, "Javascript crypto considered harmful", and I agree-- Javascript crypto is hard! But it's not impossible. The reason I chose that route is because I want to make it as easy as possible for users to try out and adopt. Just testing it out? No installation required. I think that security is at least equal parts a technical problem and an adoption problem. The status quo is that nearly al…
Two big questions: 1. How do you revoke a compromised signature comitee certificate embedded in the browser extension? 2. How can you prevent a hostile browser extension from hijacking the validation process?
1. We could require the signatures to be recent, and if there are any certificates that need to be revoked, we could require that all signers include that information in the data signed. What do you think?
2. If other hostile browser extensions can hijack the validation process, then the only solution is to not have other browser extensions. Paranoid users who need strong security should boot from a fixed image that has a vetted browser with only one browser extension already installed.
requirement 1. message integrity and security
1a. use public-key cryptography
- step 1. Person A writes a letter to Person B.
- step 2. Person A encrypts a message using Person B's public key.
- step 3. Person A sends encrypted message to Person B.
- step 4. Person B receives and decrypts the message using Person B's private key.
requirement 2. clandestine recipients
1a. coded messages
- con: coded messages are usually broken after enough messages pass
1b. steganography
- not difficult to detect if messages sent often
1c. dead drops
- pro/con: MITM has to monitor the drop box to determine recipient
1d. peer-to-peer message passing
- can still determine recipient using statistical analysys
Earlier quoted context omitted.
But doesn't this approach if implemented the best we can , at least blocks dragnet surveillance ? isn't that valuable ?
How are you going to block dragnet surveillance if they can surveil the method of your delivering encrypted messages? NSA can already see, and modify, the JS used to create encrypted messages (because they've owned the HTTPS gateways), so they can see, and modify, the encrypted messages.
As a user, why would I want to delegate my key management to you? Encrypting the email I want to send to a person with their public key is what gives me a sense of trust that what I am sending is encrypted and only readable to that person.
However--as the example of Tormail and others show us--the server cannot be trusted to serve uncompromised client-side code, even if the organization behind it is well intentioned.
So then why am I trusting you with my PGP keys?
Earlier quoted context omitted.
This is also a PGP application that most people can benefit from immediately (compared to using Hotmail), and one that can be used by even the most targeted users if their environment is set up correctly once the extension is out.
You say that because you want it to be true, not because you have any real confidence that it is true.
If you just expose your service as an API then you don't have to worry about users trusting code given to them by the site. Then use a native client app that doesn't suck to interact with the service...all of the encryption is done client side with all of the messages being encrypted end to end. JavaScript encryption just isn't really valid in browsers...the browser runtime is to blame. Its funny that people have to…