91–100 of 111 posts
Earlier quoted context omitted.
If you input your encryption passphrase on a keylogged device, your entire encryption userspace falls apart.
not if you do your crypto on a dongle (such as a yubikey), at which point they also need physical access to get the private key. It's perfectly viable for services like protonmail to allow 2FA via a dongle which would not be compromised permanently by a totally pwned userspace.
Earlier quoted context omitted.
Even Phil Zimmermann, PGP's creator, says it's too hard to use: “I hardly ever run PGP. When people send me PGP encrypted mail I have to go through a lot of trouble to decrypt it. If it’s coming from a stranger, I’ll say please re-send this in plain text, which probably raises their eyebrows.“ http://www.forbes.com/sites/parmyolson/2013/08/09/e-mails-bi... I tried the ProtonMail password protection feature today (whi…
"PGP is hard to use" is more memetic than accurate. What makes PGP hard is that it has a million options, and its vocal users (and detractors) seem insistent on availing themselves of as many of them as possible. In reality, 80% of PGP's value (which is more value than you'll get out of any webmail system), you can get with three command lines: gpg -sear recipient@addr document.txt Encrypt and sign a document, ASCII…
A few critical questions: 1) How are spam filters implemented if they can't access the content? 2) How is metadata protected? 3) Also, can I use POP/IMAP and store my mail locally, or must I trust them with my data?
Regarding 3, no, there is no protocol to store mail locally. You have to use webmail or one of their applications. https://protonmail.com/support/knowledge-base/imap-smtp-and-...
Earlier quoted context omitted.
Disclosure Note: I'm with ProtonMail. Please note that I don't officially speak for the company. But, I'm a crypto guy and this is Hackernews so... 1. While historically advertising a hosting location was a bit of a red flag for snake oil, the Snowden disclosures changed things for SaaS providers. Jurisdictional arbitrage is indeed a security feature of the service. I think you're missing the point a bit in that it g…
> I contend that these are the same vulnerabilities someone faces downloading GnuPG from it's distribution sites, downloading Firefox/Chrome/IE, or even applying Windows/Linux updates. If you had in mind the typical Windows user who downloads programs from the internet without any security check, then you're right, but the typical Linux user doesn't do this and instead installs software via the package system provide…
Ideally, you should be able to use the WoT (Web of Trust) to validate the public key that comes with the ISO (validating that the copy of GnuPG, glibc, or the Kernel has not be modified to mess with the signature validation is much harde). But, have you ever looked at the signatures on the public keys that most distributions use to validate their software releases? There are usually no signatures at all. They keys have no WoT links at all. They don't even use it. One example of this is RedHat Linux.
I actually wrote a document that describes how to do Strong Software Distribution with PGP: https://cryptnet.net/fdp/crypto/strong_distro.html Unfortunately, no one really does it.
Earlier quoted context omitted.
> 2. This is true. However, it's true about every web service. It is also true about any software that is either distributed over the web/TLS or has security updates distributed over the web/TLS. While some may say that non-web apps have code signing or application signing keys, the fact is that most of either the signing or verification keys for those application code signature schemes are distributed over TLS. If y…
> If you install Debian you have to make sure that the ISO was not compromised. You can do that by calling a third-party and compare the published checksums or any out-of-band solution. Once this base of trust is established you are good to go. In fact updates are fetched over plain HTTP because all the updates are signed using GPG. It's hard to take this seriously - do you really call a third-party every-time you re…
So while in principle the threat model is similar, the practicalities of the two situations are vastly different, questioning the whole "we want to provide practical security" mantra.
Earlier quoted context omitted.
> If you install Debian you have to make sure that the ISO was not compromised. You can do that by calling a third-party and compare the published checksums or any out-of-band solution. Once this base of trust is established you are good to go. In fact updates are fetched over plain HTTP because all the updates are signed using GPG. It's hard to take this seriously - do you really call a third-party every-time you re…
There's really no comparison between the two scenarios. Hacking the MIT server or distros to replace the GPG code is an incredibly noisy attack, which will leave an evidence trail the size of Utah, home state of NSA. It's a risky attack because you don't have selectors (don't know to whom to provide the trojanized code) so you will necessarily infect more targets than necessary. There are also multiple manual and aut…
What percentage of the packages you use in a production deployment are GPG signed? I think the minority.
> On the other hand, forcing an email provider to colaborate is standard legal practice (Lavabit), you have a perfect selector (the email address of the target), there is no tripwire, and getting the key will permit you to decrypt al past and future communication. Once the user closes the browser, the evidence is gone. Easy as pie.
This is totally irrelevant to the current conversation. As it was discussed protonmail uses client-side crypto with PGP signed messages -- meaning the only thing they store is your encrypted keys.
Yes, if Protonmail could be forced to serve passphrase stealing javascript then your encrypted keys would be vulnerable - but so would you if Debian was forced to serve a keylogger as a kernel module. btw I do agree that SSL is a much higher-risk factor than a linux-system with a local mail-server using PGP - but I don't see a better alternative than something like protonmail for the majority of consumers.
Can you search your emails? If so, how is the search index stored? Is it local or stored at ProtonMail?
You could have multiple megabyte sized indexes, for example each covering a certain timespan. The default search action would be to search, say, the preloaded index for the last month, and the user will expect an "All time" search to take a bit more as more indexes are downloaded. (Patent pending)
Earlier quoted context omitted.
There's really no comparison between the two scenarios. Hacking the MIT server or distros to replace the GPG code is an incredibly noisy attack, which will leave an evidence trail the size of Utah, home state of NSA. It's a risky attack because you don't have selectors (don't know to whom to provide the trojanized code) so you will necessarily infect more targets than necessary. There are also multiple manual and aut…
> There's really no comparison between the two scenarios. Hacking the MIT server or distros to replace the GPG code is an incredibly noisy attack.. What percentage of the packages you use in a production deployment are GPG signed? I think the minority. > On the other hand, forcing an email provider to colaborate is standard legal practice (Lavabit), you have a perfect selector (the email address of the target), there…
That's exactly what I'm saying, the situations are not remotely comparable, reasons as stated.
Earlier quoted context omitted.
> 2. This is true. However, it's true about every web service. It is also true about any software that is either distributed over the web/TLS or has security updates distributed over the web/TLS. While some may say that non-web apps have code signing or application signing keys, the fact is that most of either the signing or verification keys for those application code signature schemes are distributed over TLS. If y…
> If you install Debian you have to make sure that the ISO was not compromised. You can do that by calling a third-party and compare the published checksums or any out-of-band solution. Once this base of trust is established you are good to go. In fact updates are fetched over plain HTTP because all the updates are signed using GPG. It's hard to take this seriously - do you really call a third-party every-time you re…
If an attacked wants to compromise that chain he has to be present from the start and re-sign the packages trough MITM all the time. If I switch Internet connections and fetch an update I will get a signature mismatch.
Now compare to protonmail's webmail. At any point, if an attacker is able to MITM SSL then the user is compromised. Game over. The client won't even have the chance to see a signature mismatch and take appropriate actions after the fact.
I'm not saying that protonmail is a bad idea but "web crypto" definitely is in my book. It doesn't mean you can't implement another client for the desktop like you did for Android and iOS. Distributing the software and the data on different channels really makes the attacks more difficult.
Earlier quoted context omitted.
Disclosure Note: I'm with ProtonMail. Please note that I don't officially speak for the company. But, I'm a crypto guy and this is Hackernews so... 1. While historically advertising a hosting location was a bit of a red flag for snake oil, the Snowden disclosures changed things for SaaS providers. Jurisdictional arbitrage is indeed a security feature of the service. I think you're missing the point a bit in that it g…
I have a simple maybe stupid question. Why is is necessary to have 2 passcodes for ProtonMail? Wouldn't it theoretically provide the same level of security if the password used to access the email would be also used for encrypting the messages?