Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OpenPGPjs has passed an independent security audit

protonmail.com

Post reply on HN
Print view View original

91–100 of 128 posts

Re: OpenPGPjs has passed an independent security audit

#91

Post by hahahihi »

pera wrote: post #60
tlrobinson wrote: post #15

Earlier quoted context omitted.

This (rightfully) comes up every time some browser-based encryption tool is posted. It seems like the desire for such tools isn’t going to go away. Is anyone working on solutions for making distribution of JavaScript applications more secure? There’s a range of assurances you could try to provide, e.x. signatures from the author (or even 3rd parties), prompting for updates, etc. It would likely require support from b…

A browser add-on that is manually installed (which I believe would stop any potential insecure/unintended automatic update) could check a digital signature embedded in a formatted comment inside the JS file. That is relatively easy to implement, but you will also want some sort of PKI for key distribution and revocation.

Let the uri be the signature?

Re: OpenPGPjs has passed an independent security audit

#92

Post by dane-pgp »

SahAssar wrote: post #78
eganist wrote: post #74

Earlier quoted context omitted.

cyph.com

Thanks!

It's worth noting that Cyph came up in an earlier discussion about HPKP being removed from Chrome:

https://news.ycombinator.com/item?id=15572888

As far as I'm aware that means their approach no longer works (across browsers), and, though it was a fantastic idea, it did require you to trust that they really were throwing their keys away (a trust model slightly weaker than TOFU).

Re: OpenPGPjs has passed an independent security audit

#93

Post by xyzzy123 »

jrruethe wrote: post #63
Sir_Cmpwn wrote: post #4

Not that it matters. They could silently replace it with a backdoored script and your browser would never tell you it happened. And to preempt the ProtonMail rep who is probably going to respond to this comment, I know that you can run the web app on localhost. But that doesn't mean that users who don't are any more secure.

These concepts are interesting: https://codegolf.stackexchange.com/questions/18217/javascrip... https://bitbucket.org/geraintluff/caution.js/ The idea is that a long data-uri containing hashes and a small loader function are bookmarked. The loader won't load the corresponding javascript unless the hashes match. The user only needs to verify the javascript once, then they can rely on their bookmark containing the hash…

You might also like substack’s work on hyperboot.

Re: OpenPGPjs has passed an independent security audit

#94

Post by bigiain »

peterwwillis wrote: post #47
woranl wrote: post #14

Earlier quoted context omitted.

The same can be said for any software that auto update (i.e. Chrome), no?

Attack vectors for replacing Chrome: - Hack Google Attack vectors for replacing OpenPGPjs: - Hack the servers hosting OpenPGPjs - Hack the browser to inject or replace content across domains, sandboxes, other security barriers It's a subtle difference, but delivering applications dynamically via web browsing is much more precarious than natively hosted applications. Another way to think of it is if your entire Linux…

> Attack vectors for replacing Chrome:

> - Hack Google

  - NSL Google
(If you're a high-enough value target and your adversary is the US Government. But in _that_ case you've probably already lost - you might just not know it yet. I wonder if Snowden uses Chrome or lets it autoupdate?)

Re: OpenPGPjs has passed an independent security audit

#95

Post by dane-pgp »

hahahihi wrote: post #91
pera wrote: post #60

Earlier quoted context omitted.

A browser add-on that is manually installed (which I believe would stop any potential insecure/unintended automatic update) could check a digital signature embedded in a formatted comment inside the JS file. That is relatively easy to implement, but you will also want some sort of PKI for key distribution and revocation.

Let the uri be the signature?

The idea came to my mind that people could create websites on domains of the form [some SHA hash].example.com and reference from the root HTML page a file with the name [the same SHA hash].js and this could trigger a special mode in the browser where it checked that the JavaScript file hashed to the given value, and then refused to load any other scripts.

The bootstrap JavaScript file could contain the code needed to download more files, and to download a digitally signed list of file hashes, which it could check against a hardcoded public key. Also the browser would have to remember a flag for that domain to require this same bootstrapping process every time, to stop downgrade attacks.

Re: OpenPGPjs has passed an independent security audit

#96

Post by bigiain »

digianarchist wrote: post #8
Sir_Cmpwn wrote: post #4

Not that it matters. They could silently replace it with a backdoored script and your browser would never tell you it happened. And to preempt the ProtonMail rep who is probably going to respond to this comment, I know that you can run the web app on localhost. But that doesn't mean that users who don't are any more secure.

Remember when Hushmail backdoored their client-side applet to capture unencrypted emails and passwords?

I remember when Lavabit didn't...

Re: OpenPGPjs has passed an independent security audit

#97

Post by buu700 »

dane-pgp wrote: post #92
SahAssar wrote: post #78

Earlier quoted context omitted.

Thanks!

It's worth noting that Cyph came up in an earlier discussion about HPKP being removed from Chrome: https://news.ycombinator.com/item?id=15572888 As far as I'm aware that means their approach no longer works (across browsers), and, though it was a fantastic idea, it did require you to trust that they really were throwing their keys away (a trust model slightly weaker than TOFU).

We (Cyph) have been pretty disappointed in the Chrome team's decision to kill HPKP.

Paraphrasing, but IIRC the reasoning pretty much boiled down to "it's a pain to maintain and Expect-CT is kind of similar anyway" — which I think is a really weak justification for harming end user security and breaking established APIs that people depend on in production. Fingers crossed that Firefox keeps it alive!

That said, it doesn't entirely break WebSign in Chrome, just weakens a bit further below strict TOFU. https://www.cyph.com/websign goes into detail, but WebSign has some client-side logic to validate its own hash against a signed whitelist. The major downsides to relying on this are:

1. It depends on a caching layer, not a security feature. This means that any guarantees are potentially out the window if a browser vendor decides to do something crazy for performance reasons or whatever.

2. It opens up an attack vector where it can be forcibly unpinned by filling up the user's disk and making the browser evict the cached WebSign instance.

All in all I think it's still basically fine, but shipping an optional browser extension for hardening WebSign is now a higher priority because of this.

Re: OpenPGPjs has passed an independent security audit

#98

Post by dane-pgp »

makmanalp wrote: post #81
bartbutler wrote: post #33

Earlier quoted context omitted.

You are confusing crypto primitives with a high-level spec like OpenPGP. OpenPGPjs used WebCrypto and node crypto libraries when available for primitives. You still need a library for the OpenPGP stuff.

Whoops, I see my mistake, thanks.

I think you're right to pick up on this "side channel resistance or reliable constant time operations" wording, actually. If the OpenPGPjs library is using WebCrypto for the primitives, then what are the non-constant time operations and JavaScript-specific side channels that have security implications? Such a claim should really be accompanied by a specific threat model.

Is the supposed threat actor a MitM that can use the timing of the packets your browser sends to work out when you stopped typing your email and when the email was sent to the server, allowing them to calculate the time taken by the encryption operation and thus infer something about the plaintext of the email?

Alternatively, is the threat actor someone running JavaScript code in another tab of the same browser, who can infer how much CPU the browser is using at any given time, with enough accuracy to reveal bits of the private key?

Perhaps they are imagining an attacker who could do both, and it would be very interesting to see a practical attack along these lines, but I still think that a decent WebCrypto implementation should make it close to impossible for an attacker to extract any useful information unless the user is sending billions of emails through the ProtonMail web client.

Re: OpenPGPjs has passed an independent security audit

#99

Post by yacn »

rasengan wrote: post #84
yacn wrote: post #79

Earlier quoted context omitted.

Well one things certain: I'll never use Private Internet Access after this ridiculous comment from you[0] not even three months ago. [0] https://news.ycombinator.com/item?id=17261149 -- need to have "showdead" enabled in profile

I stand by that statement.

And I stand by mine that I'll never use or recommend Private Internet Access.

Re: OpenPGPjs has passed an independent security audit

#100

Post by bartbutler »

dane-pgp wrote: post #98
makmanalp wrote: post #81

Earlier quoted context omitted.

Whoops, I see my mistake, thanks.

I think you're right to pick up on this "side channel resistance or reliable constant time operations" wording, actually. If the OpenPGPjs library is using WebCrypto for the primitives, then what are the non-constant time operations and JavaScript-specific side channels that have security implications? Such a claim should really be accompanied by a specific threat model. Is the supposed threat actor a MitM that can u…

I also think exploiting it would be extremely difficult. IIRC, it was NIST ECC curves which are hard to make constant time and do not have WebCrypto primitives. We are still going to see what we can do to address this.
Post reply on HN