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

End-To-End – OpenPGP Chrome extension from Google

code.google.com

Post reply on HN
Print view View original

161–170 of 173 posts

Re: End-To-End – OpenPGP Chrome extension from Google

#161

Post by rca »

brianmwaters_hn wrote: post #124
makomk wrote: post #55

"Please note that EC support was added to GnuPG 2.1 beta in 2010, but it hasn’t been released as a stable version yet. To communicate with other people that don't use End-To-End, you will need to either generate a key in GnuPG and then import it, or build GnuPG 2.1 yourself." So basically, out the box this doesn't interoperate well with non-beta versions of GnuPG which are what everyone else is using for end-to-end e…

This is a huge problem that's akin to "replacing HTML/JS." It's a non backward-compatible change that make the plugin nearly 100% useless for current PGP users. Obviously folks can generate new EC keys, but they will be reluctant to abandon keys they've had for years that contain valuable third-party signatures. I think this will be a huge hindrance to adoption, and it would be imperative for the community to impleme…

Their workaround of "To communicate with other people that don't use End-To-End, you will need to either generate a key in GnuPG and then import it" wouldn't make much sense if ETE wasn't able to import and interop with RSA keys already. You can also find an rsa implementation in the repo (https://code.google.com/p/end-to-end/source/browse/javascrip...) that would indicate that they do support RSA encrypt/decrypt. However I can't find any DSA implementation, I think there could indeed be issues with people using DSA/ElGamal keys. (which is weird because there is an implementation of ElGamal, probably the DSA implementation is still being worked on)

Re: End-To-End – OpenPGP Chrome extension from Google

#162

Post by cryptbe »

tanx wrote: post #138
cryptbe wrote: post #102

Earlier quoted context omitted.

Not a stupid question at all. We actually considered this option, but OpenPGP.js looked pretty bad back then. Security-wise the library wasn't in good shape. One of our cryptographers would "classify [OpenPGP.js] as trash". It has been audited recently, but the result doesn't look very good either [1]. I don't know the current status though. OpenPGP.js didn't actually implement most of the ciphers - it just imported…

I'm a contributor to OpenPGP.js. I understand your choice as the code was indeed in quite bad shape several months ago. I do want to point out though, that the code has gone through a big refactoring an cleanup since then: https://github.com/openpgpjs/openpgpjs/releases We also fixed all critical, high and medium issue: https://github.com/openpgpjs/openpgpjs/wiki/Cure53-security-... Having said that, a consistent rew…

Thanks for the update on OpenPGP.js.

> What are your plans in regards to web crypto?

The plan is to use WebCrypto if it's available. We've moved RSA to WebCrypto, and the next targets are ECDH and ECDSA.

> Also what is the predicted timeline for getting End-to-End into a production ready state? We would be quite interested in using it as a standalone library in our Chrome Packaged App: https://whiteout.io

I can't tell you about our timeline for the extension. But if you just want to use the crypto library, you may want to wait for a couple of weeks, just to make sure none discovers any serious vulnerabilities.

I like WhiteOut. It's a great product in the right direction. We really want and will support the usage of the library in products like yours.

Re: End-To-End – OpenPGP Chrome extension from Google

#163

Post by cryptbe »

indutny wrote: post #153
cryptbe wrote: post #126

Earlier quoted context omitted.

Oh we haven't. Looks like it's a nice library. One question: it seems that you use the message directly, instead of its hash, in ECDSA? [1]. [1] https://github.com/indutny/elliptic/blob/master/lib/elliptic... PS: were you the guy that won the CloudFlare's HeartBleed challenge? great work :-).

I do expect users to hash the message before passing it to ECDSA, this way you could use any hashing library with it. Though, elliptic.js does actually depends on hash.js to seed it's PRNG. Thank you!

> I do expect users to hash the message before passing it to ECDSA, this way you could use any hashing library with it. Though, elliptic.js does actually depends on hash.js to seed it's PRNG.

I think this isn't a good design because most people won't know that they must hash the message before passing it to the ECDSA. People will misuse it, and open themselves to attacks.

What you can do instead is to pick the right hash based on the curve, like what we did in End-To-End: https://code.google.com/p/end-to-end/source/browse/javascrip....

Re: End-To-End – OpenPGP Chrome extension from Google

#164

Post by cryptbe »

rca wrote: post #161
brianmwaters_hn wrote: post #124

Earlier quoted context omitted.

This is a huge problem that's akin to "replacing HTML/JS." It's a non backward-compatible change that make the plugin nearly 100% useless for current PGP users. Obviously folks can generate new EC keys, but they will be reluctant to abandon keys they've had for years that contain valuable third-party signatures. I think this will be a huge hindrance to adoption, and it would be imperative for the community to impleme…

Their workaround of "To communicate with other people that don't use End-To-End, you will need to either generate a key in GnuPG and then import it" wouldn't make much sense if ETE wasn't able to import and interop with RSA keys already. You can also find an rsa implementation in the repo ( https://code.google.com/p/end-to-end/source/browse/javascrip... ) that would indicate that they do support RSA encrypt/decrypt.…

DSA: https://code.google.com/p/end-to-end/source/browse/javascrip....

Re: End-To-End – OpenPGP Chrome extension from Google

#165

Post by jorde »

cryptbe wrote: post #92
dfc wrote: post #79

Earlier quoted context omitted.

I had a slightly different reaction to the "high standard" bit. I always thought Prof. Boneh was a high standard. Does anyone know if there were any obvious reasons to exclude SJCL?

Disclaimer: I contribute to the core crypto library in Google End-To-End. I was also a student of Prof. Boneh. I took his CS255, and became a TA for his infamous's Crypto I class on Coursera. So I guess at the end of the day it's still Boneh's teaching that has helped my colleagues and me create this library ;-). SJCL is a great library, but it didn't quite work for us because: * It isn't a Closure library. We want t…

In the long term, could you extract the underlying crypto library and make it available for others to use in easy form? Crypto.js is pretty difficult to use and I keep seeing people including the files into their projects because of this. I'm mainly looking for:

* Officially hosted on GitHub (or at least official mirror)

* Bower and NPM packet management

* Common.js modules for Node

Re: End-To-End – OpenPGP Chrome extension from Google

#166

Post by Sephr »

letstryagain wrote: post #121
DSingularity wrote: post #120

Earlier quoted context omitted.

Why do you say this? I dont think all side channel attack surfaces require local access to the machine.

Can you give me an example that would be relevant here?

Here's a timing side channel attack in JavaScript that implements navigator.hardwareConcurrency: http://wg.oftn.org/projects/core-estimator/demo/

Re: End-To-End – OpenPGP Chrome extension from Google

#167

Post by tanx »

cryptbe wrote: post #162
tanx wrote: post #138

Earlier quoted context omitted.

I'm a contributor to OpenPGP.js. I understand your choice as the code was indeed in quite bad shape several months ago. I do want to point out though, that the code has gone through a big refactoring an cleanup since then: https://github.com/openpgpjs/openpgpjs/releases We also fixed all critical, high and medium issue: https://github.com/openpgpjs/openpgpjs/wiki/Cure53-security-... Having said that, a consistent rew…

Thanks for the update on OpenPGP.js. > What are your plans in regards to web crypto? The plan is to use WebCrypto if it's available. We've moved RSA to WebCrypto, and the next targets are ECDH and ECDSA. > Also what is the predicted timeline for getting End-to-End into a production ready state? We would be quite interested in using it as a standalone library in our Chrome Packaged App: https://whiteout.io I can't tel…

Thanks for for reply. I'm wondering if you know if it's possible to use the AES-CFB mode from the Web Crypto Apis, since the OpenPGP CFB (resync) mode seems to have special requirements?

> I like WhiteOut. It's a great product in the right direction. We really want and will support the usage of the library in products like yours.

Thanks! Is there a guide somewhere that explains how to build the standalone lib?

Re: End-To-End – OpenPGP Chrome extension from Google

#168

Post by cryptbe »

tanx wrote: post #167
cryptbe wrote: post #162

Earlier quoted context omitted.

Thanks for the update on OpenPGP.js. > What are your plans in regards to web crypto? The plan is to use WebCrypto if it's available. We've moved RSA to WebCrypto, and the next targets are ECDH and ECDSA. > Also what is the predicted timeline for getting End-to-End into a production ready state? We would be quite interested in using it as a standalone library in our Chrome Packaged App: https://whiteout.io I can't tel…

Thanks for for reply. I'm wondering if you know if it's possible to use the AES-CFB mode from the Web Crypto Apis, since the OpenPGP CFB (resync) mode seems to have special requirements? > I like WhiteOut. It's a great product in the right direction. We really want and will support the usage of the library in products like yours. Thanks! Is there a guide somewhere that explains how to build the standalone lib?

> Thanks for for reply. I'm wondering if you know if it's possible to use the AES-CFB mode from the Web Crypto Apis, since the OpenPGP CFB (resync) mode seems to have special requirements?

I haven't looked into it.

> Thanks! Is there a guide somewhere that explains how to build the standalone lib?

No, there isn't. But can you file a bug with us? I'll make sure we have something for you.

PS: how can I contact you?

Re: End-To-End – OpenPGP Chrome extension from Google

#169

Post by cryptbe »

jorde wrote: post #165
cryptbe wrote: post #92

Earlier quoted context omitted.

Disclaimer: I contribute to the core crypto library in Google End-To-End. I was also a student of Prof. Boneh. I took his CS255, and became a TA for his infamous's Crypto I class on Coursera. So I guess at the end of the day it's still Boneh's teaching that has helped my colleagues and me create this library ;-). SJCL is a great library, but it didn't quite work for us because: * It isn't a Closure library. We want t…

In the long term, could you extract the underlying crypto library and make it available for others to use in easy form? Crypto.js is pretty difficult to use and I keep seeing people including the files into their projects because of this. I'm mainly looking for: * Officially hosted on GitHub (or at least official mirror) * Bower and NPM packet management * Common.js modules for Node

Yes. This is something we or at least I would do in a few months.

Re: End-To-End – OpenPGP Chrome extension from Google

#170

Post by indutny »

cryptbe wrote: post #163
indutny wrote: post #153

Earlier quoted context omitted.

I do expect users to hash the message before passing it to ECDSA, this way you could use any hashing library with it. Though, elliptic.js does actually depends on hash.js to seed it's PRNG. Thank you!

> I do expect users to hash the message before passing it to ECDSA, this way you could use any hashing library with it. Though, elliptic.js does actually depends on hash.js to seed it's PRNG. I think this isn't a good design because most people won't know that they must hash the message before passing it to the ECDSA. People will misuse it, and open themselves to attacks. What you can do instead is to pick the right…

I actually already have a hash in `elliptic.curves` presets, but thanks for the idea!
Post reply on HN