5 ms·

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 rea

by dfc 12y ago

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?

1345 12y ago
SJCL does not support all of the primitives needed for OpenPGP.
- dfc 12y ago
  I guess I should have been more clear. Why not add the primitives to SJCL and leverage an existing code base--a code base authored by someone who is considered to set a very high standard in crypto--instead of reinventing everything? Setting a higher standard than Prof. Boneh seems like a tough thing to do. Why not stand on Boneh et. al's shoulders?
  - declan 12y ago
    It would be useful to have someone from Google elaborate on the summary they posted today. But I do recall that at least one of Prof. Boneh's postdocs mentioned in the original 2009 SJCL whitepaper is now at Google working on encryption... [edit: Looks like that elaboration did happen elsewhere in the discussion -- just noticed it now.]
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

by dfc 12y ago

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?

1345 12y ago

SJCL does not support all of the primitives needed for OpenPGP.

dfc 12y ago
I guess I should have been more clear. Why not add the primitives to SJCL and leverage an existing code base--a code base authored by someone who is considered to set a very high standard in crypto--instead of reinventing everything? Setting a higher standard than Prof. Boneh seems like a tough thing to do. Why not stand on Boneh et. al's shoulders?
- declan 12y ago
  It would be useful to have someone from Google elaborate on the summary they posted today. But I do recall that at least one of Prof. Boneh's postdocs mentioned in the original 2009 SJCL whitepaper is now at Google working on encryption... [edit: Looks like that elaboration did happen elsewhere in the discussion -- just noticed it now.]

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