3 ms·

Somebody from the security community could shed some light on why this is a good/bad idea.

gruez 11y ago
something something roll your own crypto [1] [1] https://security.stackexchange.com/questions/18197/why-shouldnt-we-roll-our-own https://security.stackexchange.com/questions/18197/why-shoul...
- sarciszewski 11y ago
  See this instead: http://www.cryptofails.com/post/75204435608/write-crypto-code-dont-publish-it http://www.cryptofails.com/post/75204435608/write-crypto-cod...
michaelsbradley 11y ago
With respect to the browser, What’s wrong with in-browser cryptography?[1] and Javascript Cryptography Considered Harmful[2] may still be relevant. [1] http://tonyarcieri.com/whats-wrong-with-webcrypto http://tonyarcieri.com/whats-wrong-with-webcrypto [2] https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2011/august/javascript-cryptography-considered-harmful/ https://www.nccgroup.trust/us/about-us/newsroom-and-events/b...
- explorigin 11y ago
  Both of the articles have some flaws (that Matasano one is really bad/dated actually). Here's a good one about the problems with JS Crypto: http://rdist.root.org/2010/11/29/final-post-on-javascript-crypto/ http://rdist.root.org/2010/11/29/final-post-on-javascript-cr...
  - tedunangst 11y ago
    It's curious that you follow up a "really dated" article from 2011 with an article from... 2010.
    - explorigin 11y ago
      The article that I posted, while older, presents a more realistic and objective look at the JS crypto problem. I chose to criticize the matasano article as "dated" because some of the positions it takes are no longer accurate. The older article does not depend on dated information to make its points.
- istvan__ 11y ago
  This is really good. I am curious if somebody could mitm the https layer with rogue ca and append more JS to the content. The problem I see as a non-expert with dynamic content that it can't be signed. If we use HTTP as it was intended we could just name the content after the sha(content). That way the client could validate the integrity. The problem with shipping computation to the client side that you lost the integrity verification and opened up the platform to all sorts of vulnerabilities. I guess we should just create a brand new protocol that supports stateful clients, it is network efficient and security is part of the design.
- lewisl9029 11y ago
  Thanks for sharing. I've come across the Matasano one before and felt it might have been a bit outdated in light of recent efforts with WebCrypto. So it was interesting to see an article critiquing WebCrypto for once. I'm interested in hearing some thoughts on how well WebCrypto would hold up in a local execution environment like Cordova/nw.js/electron rather than in the browser. It seems to me that many of the article's concerns can be addressed by providing the application code in a verifiable package rather than grabbing it over the browser ad-hoc. Am I missing anything?
jpalomaki 11y ago
A good blog entry on the topic: http://blog.cryptographyengineering.com/2012/02/multiple-encryption.html http://blog.cryptographyengineering.com/2012/02/multiple-enc...
tyho 11y ago
If you are going to the trouble of layering encryption like that you may as well using a MAC with similar construction. It is poorly thought out. I would also be much more worried about scrypt than AES in the future, it has had much less review yet is not layered in the same way. Also the go reference implementation is not idiomatic, It does not conform to the interface of other encryption functions in the standard library. EDIT: I was wrong, they do double up on MAC's but do not on the KDF.
Mutjake 11y ago
Roughly the upside is that (in theory) the attacker needs to defeat each cipher separately (barring that the combination offers some shortcuts where one cipher interacts with another so that some computational complexity can be eliminated). Downside is that the performance takes a hit (processor/bandwidth [if blocksizes don't match, dunno if this is an existing risk]), which might not be trivial. Disclaimer: I assume that existing, proven implementations are used and out from one cipher is handed over to another as input, keys and IVs and other crypto mumbo jumbo are not recycled and that the implementation does not offer new side-channel attacks somehow etc etc. Personally I'd wait for a while to allow more competent people to analyze the library. In the meanwhile one can do performance profiling to roughly calculate how much beefier servers are needed in a real-world scenario due to extra crypting and decrypting :-)
istvan__ 11y ago
Thanks everybody, much value as usual!

gruez 11y ago

something something roll your own crypto [1] [1] https://security.stackexchange.com/questions/18197/why-shouldnt-we-roll-our-own https://security.stackexchange.com/questions/18197/why-shoul...

sarciszewski 11y ago
See this instead: http://www.cryptofails.com/post/75204435608/write-crypto-code-dont-publish-it http://www.cryptofails.com/post/75204435608/write-crypto-cod...

michaelsbradley 11y ago

With respect to the browser, What’s wrong with in-browser cryptography?[1] and Javascript Cryptography Considered Harmful[2] may still be relevant. [1] http://tonyarcieri.com/whats-wrong-with-webcrypto http://tonyarcieri.com/whats-wrong-with-webcrypto [2] https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2011/august/javascript-cryptography-considered-harmful/ https://www.nccgroup.trust/us/about-us/newsroom-and-events/b...

explorigin 11y ago
Both of the articles have some flaws (that Matasano one is really bad/dated actually). Here's a good one about the problems with JS Crypto: http://rdist.root.org/2010/11/29/final-post-on-javascript-crypto/ http://rdist.root.org/2010/11/29/final-post-on-javascript-cr...
- tedunangst 11y ago
  It's curious that you follow up a "really dated" article from 2011 with an article from... 2010.
  - explorigin 11y ago
    The article that I posted, while older, presents a more realistic and objective look at the JS crypto problem. I chose to criticize the matasano article as "dated" because some of the positions it takes are no longer accurate. The older article does not depend on dated information to make its points.
istvan__ 11y ago
This is really good. I am curious if somebody could mitm the https layer with rogue ca and append more JS to the content. The problem I see as a non-expert with dynamic content that it can't be signed. If we use HTTP as it was intended we could just name the content after the sha(content). That way the client could validate the integrity. The problem with shipping computation to the client side that you lost the integrity verification and opened up the platform to all sorts of vulnerabilities. I guess we should just create a brand new protocol that supports stateful clients, it is network efficient and security is part of the design.
lewisl9029 11y ago
Thanks for sharing. I've come across the Matasano one before and felt it might have been a bit outdated in light of recent efforts with WebCrypto. So it was interesting to see an article critiquing WebCrypto for once. I'm interested in hearing some thoughts on how well WebCrypto would hold up in a local execution environment like Cordova/nw.js/electron rather than in the browser. It seems to me that many of the article's concerns can be addressed by providing the application code in a verifiable package rather than grabbing it over the browser ad-hoc. Am I missing anything?

jpalomaki 11y ago

A good blog entry on the topic: http://blog.cryptographyengineering.com/2012/02/multiple-encryption.html http://blog.cryptographyengineering.com/2012/02/multiple-enc...

tyho 11y ago

If you are going to the trouble of layering encryption like that you may as well using a MAC with similar construction. It is poorly thought out. I would also be much more worried about scrypt than AES in the future, it has had much less review yet is not layered in the same way. Also the go reference implementation is not idiomatic, It does not conform to the interface of other encryption functions in the standard library. EDIT: I was wrong, they do double up on MAC's but do not on the KDF.

Mutjake 11y ago

Roughly the upside is that (in theory) the attacker needs to defeat each cipher separately (barring that the combination offers some shortcuts where one cipher interacts with another so that some computational complexity can be eliminated). Downside is that the performance takes a hit (processor/bandwidth [if blocksizes don't match, dunno if this is an existing risk]), which might not be trivial. Disclaimer: I assume that existing, proven implementations are used and out from one cipher is handed over to another as input, keys and IVs and other crypto mumbo jumbo are not recycled and that the implementation does not offer new side-channel attacks somehow etc etc. Personally I'd wait for a while to allow more competent people to analyze the library. In the meanwhile one can do performance profiling to roughly calculate how much beefier servers are needed in a real-world scenario due to extra crypting and decrypting :-)

istvan__ 11y ago

Thanks everybody, much value as usual!