Comments URL: https://news.ycombinator.com/item?id=39201287

Points: 3

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=38994685

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=38629770

Points: 3

# Comments: 0

Here's one way to think about _why_ it sounds wrong. "Physically based" would mean that "physically" is the answer to the question "How is it based?" To a native English speaker, that question sounds odd. A more natural question is "What is it based on?" To answer that question, you need a noun: "It's based on physics." Hence the construct "physics-based," like "evidence-based medicine" or "merit-based scholarships."

Comments URL: https://news.ycombinator.com/item?id=37786838

Points: 2

# Comments: 2

Comments URL: https://news.ycombinator.com/item?id=31573282

Points: 619

# Comments: 112

They don't. They have your encrypted private key, but there's no need to keep that secret. (The decryption key is derived from your password, so the password needs to be strong and secret.)

> Such agency can force PM to modify login process to derive password from submitted form, or to just switch private keys for non-encrypred ones, because the user won't even notice it.

Yes, definitely. It's hard to trust self-updating software (like JavaScript in the browser), particularly if you're concerned about targeted attacks. But creating your own private keys and then entering them in the browser wouldn't help you at all against that sort of attack. You would instead need a different type of client that could be trusted somehow not to leak your private key.

It's not uncommon for services like this to offer a downloadable version of the web client so you can pin a version and audit the code as needed. I think maybe https://github.com/ProtonMail/WebClient is that for ProtonMail? If so, you should be able to verify that code and then use that. The fact that an encrypted copy of your private key will live on ProtonMail's servers shouldn't bother you.

> Your ProtonMail private key is generated in your browser. Before sending the private key to the server for storage, we encrypt it with your password (or mailbox password if you use two-password mode). This ensures that you and only you can use your private key.

So the only remaining question is whether ProtonMail has access to your password. If they do, they can decrypt your private key and then decrypt your emails. Often, passwords are sent in plaintext to a server for authentication. But ProtonMail uses the Secure Remote Password (SRP) protocol so they never see your password: https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco.... (source: https://protonmail.com/blog/encrypted_email_authentication/)

Of course, there are other threats to worry about, such as ProtonMail changing their client-side JavaScript to exfiltrate your password. But the system as they've documented it does not appear to have any way to decrypt your email server-side short of guessing your password.

Comments URL: https://news.ycombinator.com/item?id=26378142

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=18871636

Points: 2

# Comments: 1

They also failed to verify source code for the contract: https://etherscan.io/address/0x3c7767011C443EfeF2187cf1F2a4c..., and the source code on GitHub is missing a file ("Ownable.sol"), making it difficult for anyone else to verify what source code is actually running.

I suppose the lack of verified source code doesn't matter, given my first point. People who are buying are placing a lot of trust in the "Fuel Bros Innovation Team."

Assuming the 128-bit IV is indeed randomly chosen, after encrypting a trillion blocks, you would have roughly a 1.5E-15 (on the order of a quadrillionth) chance of hitting a collision.

Unless I'm mistaken, even if you hit that one-in-a-quadrillion lottery, the result is that the two blocks encrypted with the same IV are more crackable (because you can XOR them together), not that the key itself is easier to obtain, right? (My understanding is that AES is resistant to known-plaintext attacks.)

Anyone who doesn't know what a zero-knowledge proof is will give you positive feedback, because they had an easy time understanding the example you presented.

People who do know what a zero-knowledge proof is will correctly point out that the thing you described is not a zero-knowledge proof.

I think this explains the gap you're seeing between the feedback here and the feedback in "less technical forums." It's difficult to come up with real-world examples of zero-knowledge proofs, but there are two good examples on Wikipedia and one here (the "Where's Waldo?" example).

See the updated page here: https://www.dropbox.com/plans?trigger=nr.

The API at https://www.dropbox.com/developers works for all account types. (Note that there are endpoints specific to team accounts when the functionality only makes sense there, like methods to add or remove members from a team, etc.)

See https://www.dropbox.com/help/363 for more information.