4 ms·

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 infamo

by cryptbe 12y ago

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 to use Closure because it supports types, which in turn make it easier and less error-prone to develop crypto code. * It doesn't support typed arrays. We don't have typed arrays in End-To-End yet, but we're working on that. * It doesn't support all the curves we want, and it seems that the main developer isn't interested in adding new curves, e.g., Curve25519. * It doesn't have ciphers or signature schemes that we need such as RSA, Ed25519, deterministic ECDSA, etc.

runn1ng 12y ago
Hello, maybe a stupid question, but any reason why not use OpenPGP.js? Is it even worse for your case than SJCL?
- cryptbe 12y ago
  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 them from various sources. This made the library inconsistent, i.e., some functions expect string, while others expect byte array, which in turn made it harder to use correctly in a language like Javascript. If we chose OpenPGP.js, we needed to change these ciphers anyway, so we thought it's just better to write them from scratch. [1] https://cure53.de/pentest-report_openpgpjs.pdf https://cure53.de/pentest-report_openpgpjs.pdf.
  - runn1ng 12y ago
    Thanks. I considered using OpenPGP.js in one project, I didn't go so deep though. Thanks for the information.
  - tanx 12y ago
    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 https://github.com/openpgpjs/openpgpjs/releases We also fixed all critical, high and medium issue: https://github.com/openpgpjs/openpgpjs/wiki/Cure53-security-audit https://github.com/openpgpjs/openpgpjs/wiki/Cure53-security-... Having said that, a consistent rewrite using typed array and native web crypto apis under the hood does indeed sound very reasonable. I saw that native web crypto is not used throughout. What are your plans in regards to web crypto? 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 https://whiteout.io Thanks
    - cryptbe 12y ago
      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 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.
      - tanx 12y ago
        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?
  - mike-cardwell 12y ago
    IIRC, openpgp.js is what both Lavaboom and Protonmail use.
indutny 12y ago
Have you guys took a look at https://github.com/indutny/elliptic https://github.com/indutny/elliptic ?
- cryptbe 12y ago
  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/ec/index.js#L110 https://github.com/indutny/elliptic/blob/master/lib/elliptic... PS: were you the guy that won the CloudFlare's HeartBleed challenge? great work :-).
  - indutny 12y ago
    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!
    - cryptbe 12y ago
      > 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/javascript/crypto/e2e/ecc/ecdsa.js#43 https://code.google.com/p/end-to-end/source/browse/javascrip....
      - indutny 12y ago
        I actually already have a hash in `elliptic.curves` presets, but thanks for the idea!
      - indutny 12y ago
cryptbe 12y ago
> his infamous's Crypto I class s/infamous/famous.
jorde 12y ago
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
- cryptbe 12y ago
  Yes. This is something we or at least I would do in a few months.

by cryptbe 12y ago

runn1ng 12y ago

Hello, maybe a stupid question, but any reason why not use OpenPGP.js? Is it even worse for your case than SJCL?

cryptbe 12y ago
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 them from various sources. This made the library inconsistent, i.e., some functions expect string, while others expect byte array, which in turn made it harder to use correctly in a language like Javascript. If we chose OpenPGP.js, we needed to change these ciphers anyway, so we thought it's just better to write them from scratch. [1] https://cure53.de/pentest-report_openpgpjs.pdf https://cure53.de/pentest-report_openpgpjs.pdf.
- runn1ng 12y ago
  Thanks. I considered using OpenPGP.js in one project, I didn't go so deep though. Thanks for the information.
- tanx 12y ago
  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 https://github.com/openpgpjs/openpgpjs/releases We also fixed all critical, high and medium issue: https://github.com/openpgpjs/openpgpjs/wiki/Cure53-security-audit https://github.com/openpgpjs/openpgpjs/wiki/Cure53-security-... Having said that, a consistent rewrite using typed array and native web crypto apis under the hood does indeed sound very reasonable. I saw that native web crypto is not used throughout. What are your plans in regards to web crypto? 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 https://whiteout.io Thanks
  - cryptbe 12y ago
    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 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.
    - tanx 12y ago
      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?
- mike-cardwell 12y ago
  IIRC, openpgp.js is what both Lavaboom and Protonmail use.

indutny 12y ago

Have you guys took a look at https://github.com/indutny/elliptic https://github.com/indutny/elliptic ?

cryptbe 12y ago
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/ec/index.js#L110 https://github.com/indutny/elliptic/blob/master/lib/elliptic... PS: were you the guy that won the CloudFlare's HeartBleed challenge? great work :-).
- indutny 12y ago
  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!
  - cryptbe 12y ago
    > 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/javascript/crypto/e2e/ecc/ecdsa.js#43 https://code.google.com/p/end-to-end/source/browse/javascrip....
    - indutny 12y ago
      I actually already have a hash in `elliptic.curves` presets, but thanks for the idea!
    - indutny 12y ago

cryptbe 12y ago

> his infamous's Crypto I class s/infamous/famous.

jorde 12y ago

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

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