OpenPGPjs v3.0 • Hacker News Board

Re: OpenPGPjs v3.0

#41

Post by jlgaddis » Sat, Mar 10, 2018, 8:27 PM UTC

zahllos wrote: post #13

dsacco wrote: post #7

Earlier quoted context omitted.

> In case anyone that doesn't follow the development of the library closely missed it, the main improvement in this version is the introduction of ECC support. Wow...I'm sort of shocked that wasn't a v1.0 consideration. > ECC tends to be able to provide equivalent levels of security as traditional "big prime" cryptography (like RSA) with less computationally intensive operations. This is especially important in a lib…

> Wow...I'm sort of shocked that wasn't a v1.0 consideration. Given that you need to pass --expert to gpg 2.1 as of right now to even generate an ECC keypair for PGP use (nor use one on an OpenPGP smartcard or yubikey), I can sort of forgive the lack of ECC in 1.0. I don't think it sees wide usage for PGP keys (some clients don't support it, also). However, as of the last time I tried Protonmail (about 10 minutes ago…

I don't use ProtoMail but it sounds like they are "managing" users' private keys!? Am I understanding this correctly? ProtonMail has access to their users' private keys? And they are using web-based encryption, delivered via JavaScript?

And people trust them!?

Re: OpenPGPjs v3.0

#42

Post by jlgaddis » Sat, Mar 10, 2018, 8:31 PM UTC

bartbutler wrote: post #22

dmos62 wrote: post #17

Earlier quoted context omitted.

I've been looking for gmail alternatives and this is my conclusion. Protonmail plays the part of the secure and private email provider, but, technologically, can't provide that. The only concrete thing their users have going is the superior legal environment of Switzerland. A less-than-concrete comforter is that if we believe that the people behind Protonmail believe in privacy, we'll tend to think they're more likel…

So, that's a conclusion but no reasoning behind it, therefore it's impossible to evaluate critically.

Apparently you missed the reasoning. ProtonMail has the capability to access either the plaintext and/or private keys.

(FYI: It is customary here on HN to disclose any affiliations when commenting.)

Re: OpenPGPjs v3.0

#43

Post by e12e » Sat, Mar 10, 2018, 11:50 PM UTC

crispyporkbites wrote: post #11

dfabulich wrote: post #9

What is the threat model for PGP in JS? Like, is there an Alice, Bob, Carol, Eve story under which PGP in JS makes sense? The canonical example that IMO doesn't make sense is when Alice and Bob want to communicate privately using Eve as an webmail provider who wants to snoop in on the communications. Alice and Bob can't just trust Eve to provide a copy of OpenPGPjs in a tag on EveMail.com, because then they're trusti…

Subresource integrity means you could trust Eve in some cases. Also if Eve provides a script tag from a trusted CDN it could work. You would have to check it every time though. What might help is a browser extension that tracks changes and allows you to “lock” into a version of a website.

Technically Sri only reduces the amount of trusted data you need to keep around; you'd need an index.html that loads gpg.js and a js client that talks to a server (eg: jmap or a bespoke jsonapi that allows getting/sending mail).

This is pretty much what browser extensions do; bottle up some hypertext resources, signed and versioned.

You still have three obvious threats: local superuser can read application memory etc; your local user can read your memory and any browser compromise/bug can likely read your browser/session data.

The real question is if the browser sandbox is ever likely to be good enough that you don't have to worry about a font file from a compromised website about kittens reading your email in another tab.

Re: OpenPGPjs v3.0

#44

Post by e12e » Sat, Mar 10, 2018, 11:56 PM UTC

bartbutler wrote: post #15

pzduniak wrote: post #10

Earlier quoted context omitted.

You mean the library that you've been using from the beginning of the proper web client? This is not an answer. Kudos for finally doing ECC though.

For internal use we had all RSA keys so it was fine. For external use we have to support what everyone uses, and there is a variety as you know. Saying "hey, you can use PGP but all your friends have to have RSA keys" is not a recipe for a good user experience.

This is great to hear! If/when protonmail transitions to be mail host that support open standards in a wider sense, I'd more seriously consider becoming a customer :-)

Fwiw, while I'm not that interested in the current project - I actually think it's great to build a walled garden on open standards - especially for secure services. Makes it easier to evaluate, and opens the door fore secure interop in the future.

Re: OpenPGPjs v3.0

#45

Post by Shoothe » Sun, Mar 11, 2018, 2:23 PM UTC

woranl wrote: post #33

Why not use webcrypto instead?

They are probably using it underneath. Webcrypto by itself is just a set of primitives, you need a higher level abstractions to do anything useful in real world.

Re: OpenPGPjs v3.0

#46

Post by emj » Mon, Mar 12, 2018, 1:26 PM UTC

dane-pgp wrote: post #40

emj wrote: post #34

Earlier quoted context omitted.

> [Alice knows] no one (other than Eve) can spoof Bob's identity If Carol or Chuck can spoof Eves "identity" they can spoof Bobs identity. This can be done in a multitude of technical or social ways. Is it better to have this than nothing? The problem is that you have to trust your whole infrastructure if you want to do this kind of client side encrypting.

If your threat model says that Eve's webmail servers can be spoofed, then Alice can't use webmail at all, or possibly any websites. At that point, the security of PGP in JS is pretty much irrelevant.

I think that is one of the most obvious things that can happen, but no it only affects JS PGP that is integrated on a site you use. PGP in JS is still relevant because it makes it easier to download, verify and execute Javascript "anywhere", not as an integrated solution served by a third party. Sadly.