8 ms·

Cryptico.js - strong encryption system utilizing RSA and AES for javascript

77 points by genieyclo 15y ago

pwpwp 15y ago
I'm collecting JS cryptography tools here: http://www.delicious.com/manuel/javascript+crypto http://www.delicious.com/manuel/javascript+crypto
losethos 15y ago
10 i = i + 1 15 IF i > 99999 THEN i = 0 20 IF LEN(INKEY$) = 0 THEN PRINT ".";: GOTO 10 30 PRINT "King James Bible, Line:", i how can we know the way? 14:6 Jesus saith unto him, I am the way, the truth, and the life: no man cometh unto the Father, but by me. 14:7 If ye had known me, ye should have known my Father also: and from henceforth ye know him, and have seen him. 14:8 Philip saith unto him, Lord, shew us the Father, and it sufficeth us. 14:9 Jesus saith unto him, Have I been so long time with you, and yet hast thou not known me, Philip? he that hath seen me hath seen the Father; and how sayest thou then, Shew us the Father? 14:10 Believest thou not that I am in the Father, and the Father in me? the words that I speak unto you I speak not of myself: but the Father that dwelleth in me, he doeth the works.
nbpoole 15y ago
I managed to dig up a recent comment thread by tptacek that explains why JS crypto is a bad idea: http://news.ycombinator.com/item?id=2855556 http://news.ycombinator.com/item?id=2855556
- dan_manges 15y ago
  Here's an in depth blog post from Nate Lawson explaining why JS crypto is a bad idea: http://rdist.root.org/2010/11/29/final-post-on-javascript-crypto/ http://rdist.root.org/2010/11/29/final-post-on-javascript-cr...
  - thinner 15y ago
    A comment from that post: "actually, i think an honest look at the security/privacy mechanisms provided by today’s tools precisely describes a case where ‘a little better than awful’ would be preferred. my mother emailed me some bank account information just last week. there isn’t any exploit required there. security software experts have failed horribly to provide tools that actual living breathing human beings might use and this is why most of them have just given up and use hotmail. i personally find it astounding that the kind of people who will deny this probably have an actual brand new credit card sitting in their unlocked mailbox and feel perfectly comfortable with this fact. your information’s security is only as strong as it’s weakest link. this includes the locks on your home, your mailbox, and the granularity you shred your trash with."
    - tptacek 15y ago
      This sentiment falls victim to the fallacy that something is secure because it should be secure. The commenter is right that the "security software experts" have failed to protect his mom. But Javascript cryptography doesn't care. It's still insecure. Engineering is a spectacular douchebag, but it is in charge nonetheless.
      - thinner 15y ago
        Given the option between his mom sending it unencrypted, and encrypting it with an easy-to-use extension he set up for her, why not encrypt it? Surely it can't _hurt_ an already horrible situation?
        tptacek 15y ago
        Both of these options are worse than not mailing banking information at all. Both of them are worse than encrypting properly, which, in this mom's case, means installing PGP. Yes, in this case, bad crypto can make a bad situation worse: it can create a false sense of security. And in the general case, bad crypto does much worse things than that. Logging in without a password. Flipping bits in a cookie to become any user on the system. Gaining admin privileges. Spoofing authorities to collect secrets from users. Bad crypto does not care how horrible your mom has it. Engineering says, bad crypto is going to be bad no matter how hurt your feelings are.
quadhome 15y ago
I'll wait for the cryptographers to weigh in; but, it's in Javascript.. already a language that's going to be hard to Do It Right in. (The first third of the code is a BigInteger implementation) Then, I looked to see if the standard constant-time comparisons were in there to resist timing attacks. No dice there. So... cool. He put a nice wrapper on JSAES[1], jsSHA2[2] by way of webtoolkit.info[3], RSA and ECC in Javascript by Tom Wu[4], and seedrandom.js by David Bau[5]. But then then says it's "New BSD license"[6] when it should be GPL[7]. I didn't start this comment sound negative. But, I think a few things are important: * Credit authors. * Respect their licenses. * Put a big fucking notice on top of your slick webpage: "FOR DEMONSTRATION PURPOSES ONLY-- NOT REAL CRYPTO" [1] http://point-at-infinity.org/jsaes/ http://point-at-infinity.org/jsaes/ [2] http://anmar.eu.org/projects/jssha2/ http://anmar.eu.org/projects/jssha2/ [3] http://www.webtoolkit.info/javascript-sha256.html http://www.webtoolkit.info/javascript-sha256.html [4] http://www-cs-students.stanford.edu/~tjw/jsbn/ http://www-cs-students.stanford.edu/~tjw/jsbn/ [5] http://davidbau.com/archives/2010/01/30/random_seeds_coded_hints_and_quintillions.html http://davidbau.com/archives/2010/01/30/random_seeds_coded_h... [6] http://code.google.com/p/cryptico/ http://code.google.com/p/cryptico/ [7] http://code.google.com/p/cryptico/source/browse/trunk/aes.js http://code.google.com/p/cryptico/source/browse/trunk/aes.js
- etrain 15y ago
  He credits the authors in his doc, but agreed on the warning - I am not a cryptographer, but my knowledge of side-channel attacks has me pretty worried that the RSA implementation is not safe.
- thinner 15y ago
  Does anything qualify as 'real crypto'? Every implementation will always and forever have weaknesses. I don't have a problem with someone putting together a package that makes it easy to do crypto stronger than rot13 - isn't that a step forward? We'd all like GPG/PGP easy in the browser with native code, but until then, what's wrong with an intermediate step that appears to be at least pretty good and fairly easy to use? Maybe it's not enough for organizing a coup, but for keeping your fantasy football strategies a secret - why not?
mkup 15y ago
This thing won't replace https anyway, because if transferred over http, Javascript code could be intercepted and modified by adversary before it reaches client browser and before it is actually executed. And if this JS code is transferred over https, what's the point of it? Don't we already have crypto in this case?
- macmac 15y ago
  Couldn't the client verify the integrity of the code against a published hash?
  - mkup 15y ago
    yes, but hash comparison operator will be executed on client side only if it wasn't stripped away along the path
    - macmac 15y ago
      I was thinking of a manual check, which would be a hassle, but would only have to be done when the script was changed.
    - dagw 15y ago
      I suppose it could be combined with some sort of grease monkey type component, where the user supplies their own hash operator code.
      - sneak 15y ago
        At that point, why bother implementing crypto in JavaScript anyway? You might as well just use a proper clientside app (a halfassed version of which is your suggestion).
  - tptacek 15y ago
    No! Very common misconception! You cannot verify the integrity of a browser Javascript cryptosystem by checking a SHA2 hash of the Javascript file containing the crypto. That's because any other piece of content, from Ajax requests and whatnot to, in many browsers, the CSS files, some of them cached and some of them loaded on the spot... any other piece of content that contributed to the page that hosts the crypto code can alter the runtime to trivially intercept secrets or fix keys. Until browsers provide a primitive to verify the whole runtime, cryptographic hashes won't do anything to ensure integrity for Javascript.
sneak 15y ago
From the source: // For best results, put code like // <body onClick='rng_seed_time();' onKeyPress='rng_seed_time();'> // in your main HTML document. And if one doesn't...
- tptacek 15y ago
  I like the phrasing "for best results". "Cryptography. For best results, use random numbers." (Ping me [see profile] if you want a sticker for finding that issue. They're neat!)
ctz 15y ago
An entertaining and original way of removing PKCS#1 signature padding: var hDigestInfo = biDecryptedSig.toString(16).replace(/^1f+00/, ''); (Just a pity the signature verification function is broken by it.)
moxie 15y ago
There's an interesting problem that is still unsolved in this space. Most people want JS crypto so that webapps can provide "end to end" encryption, relieving participants from having to trust the webapp service with their plaintext. The problem is that trusting you get the correct JS from the webapp for every message you'd like to send is reducible to trusting the webapp with your plaintext. I think there are probably some novel solutions to this problem, but it would require work to be done by the browsers.
- tptacek 15y ago
  We seem to be on a track now such that in 5 years, all the mainstream browsers will support a set of crypto primitives built into the browser, implemented in C, and exposed via Javascript bindings. And that's fine. But it means that we're not going to have end-to-end crypto in web applications for another ten years, because these schemes don't degrade gracefully; the majority of users will have to upgrade before they become useful.
  - moxie 15y ago
    And I'm not sure that this would be enough, either. Crypto primitives are nice, but you still have to trust the webapp to deliver JS which calls those primitives every time you visit the webapp. I believe that this is again reducible to trusting the webapp with your plaintext, since the webapp could selectively intercept any message it chooses.
    - tptacek 15y ago
      A bigger related problem: the argument that browser crypto extensions should be high-level (autogenerating secure keys, automatically MAC'ing ciphertexts, picking the block cipher mode for you) is not winning the day. So what we're going to end up with is an OpenSSL-style interface: x = new Cipher("AES"); x.blockmode = "CBC"; // defaults to all zeroes // x.iv = "ABCDABCDABCDABCD"; x.key = "YELLOW SUBMARINE"; x.encrypt << "This is my plaintext"; In a sense, this is great news for me, because it means I get another 5-10 years of crypto vulnerabilities to get paid to eradicate. But if you're hoping for simple, usable cryptographically strong security in common web apps... well, keep hoping.
tptacek 15y ago
Even if this wasn't browser Javascript and thus totally boned, it think it would still be pretty boned. I'll send a neat looking laptop decal to anyone here who spots any of the flaws in this cryptosystem. But it is written as browser Javascript and is thus totally boned. Here's my attempt to be exhaustive about why: http://www.matasano.com/articles/javascript-cryptography/ http://www.matasano.com/articles/javascript-cryptography/
- nbpoole 15y ago
  OK, I'm having a lot of fun reading this. One little nitpick: > What systems programming functionality does Javascript lack? Here's a starting point: a secure random number generator. Chrome has actually implemented one (http://blog.chromium.org/2011/06/new-chromium-security-features-june.html http://blog.chromium.org/2011/06/new-chromium-security-featu...). It's a part of WebKit (http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-February/030394.html http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-Feb...). Firefox has an unimplemented (as of Firefox 6) secure RNG API (https://developer.mozilla.org/en/JavaScript_crypto https://developer.mozilla.org/en/JavaScript_crypto, https://bugzilla.mozilla.org/show_bug.cgi?id=440046 https://bugzilla.mozilla.org/show_bug.cgi?id=440046).
- JoshTriplett 15y ago
  Off the top of my head, reasons why this appears broken even if it didn't use Javascript: The passphrase almost certainly doesn't have 1024 bits of entropy in it, and since they describe it as "used to repeatably generate this RSA key", they can't have introduced any additional entropy. And indeed, they just use the SHA256 of the passphrase to seed a PRNG. They claim that a PublicKeyID "can be used to uniquely identify Sam's public key". Fingerprints help identify keys more easily, but certainly not "uniquely" since they don't have as many bits as the key; pigeonhole principle. Worse, the PublicKeyID uses MD5. They use a public exponent of 3, rather than the usual 65537 or larger. It looks like they might protect against small-exponent attacks, but I don't have enough expertise to know that for certain, and in any case this seems like a bad idea. Neither cryptico nor the rsa-sign library they use mentions anything about HMACs; I haven't dug into the code to figure out if they actually use one or just use a hash directly. Probably piles more, but I stopped there. :)
peterbraden 15y ago
Some thoughts: - Writing crypto systems in dynamic languages is hard/impossible - There is a need for browser based crypto - The browser manufacturers are moving too slowly in this regard
- tptacek 15y ago
  Writing crypto in dynamic languages is hard but not impossible. Writing crypto in dynamic languages with content-controlled code is probably impossible.
- papaf 15y ago
  There is a need for browser based crypto I would love to see reasonably secure browser based crypto. You could submit things to a website without the website being able to see what they are. Imagine a social network that was opaque to the people hosting the social network.

77 points by genieyclo 15y ago

pwpwp 15y ago

I'm collecting JS cryptography tools here: http://www.delicious.com/manuel/javascript+crypto http://www.delicious.com/manuel/javascript+crypto

losethos 15y ago

10 i = i + 1 15 IF i > 99999 THEN i = 0 20 IF LEN(INKEY$) = 0 THEN PRINT ".";: GOTO 10 30 PRINT "King James Bible, Line:", i how can we know the way? 14:6 Jesus saith unto him, I am the way, the truth, and the life: no man cometh unto the Father, but by me. 14:7 If ye had known me, ye should have known my Father also: and from henceforth ye know him, and have seen him. 14:8 Philip saith unto him, Lord, shew us the Father, and it sufficeth us. 14:9 Jesus saith unto him, Have I been so long time with you, and yet hast thou not known me, Philip? he that hath seen me hath seen the Father; and how sayest thou then, Shew us the Father? 14:10 Believest thou not that I am in the Father, and the Father in me? the words that I speak unto you I speak not of myself: but the Father that dwelleth in me, he doeth the works.

nbpoole 15y ago

I managed to dig up a recent comment thread by tptacek that explains why JS crypto is a bad idea: http://news.ycombinator.com/item?id=2855556 http://news.ycombinator.com/item?id=2855556

dan_manges 15y ago
Here's an in depth blog post from Nate Lawson explaining why JS crypto is a bad idea: http://rdist.root.org/2010/11/29/final-post-on-javascript-crypto/ http://rdist.root.org/2010/11/29/final-post-on-javascript-cr...
- thinner 15y ago
  A comment from that post: "actually, i think an honest look at the security/privacy mechanisms provided by today’s tools precisely describes a case where ‘a little better than awful’ would be preferred. my mother emailed me some bank account information just last week. there isn’t any exploit required there. security software experts have failed horribly to provide tools that actual living breathing human beings might use and this is why most of them have just given up and use hotmail. i personally find it astounding that the kind of people who will deny this probably have an actual brand new credit card sitting in their unlocked mailbox and feel perfectly comfortable with this fact. your information’s security is only as strong as it’s weakest link. this includes the locks on your home, your mailbox, and the granularity you shred your trash with."
  - tptacek 15y ago
    This sentiment falls victim to the fallacy that something is secure because it should be secure. The commenter is right that the "security software experts" have failed to protect his mom. But Javascript cryptography doesn't care. It's still insecure. Engineering is a spectacular douchebag, but it is in charge nonetheless.
    - thinner 15y ago
      Given the option between his mom sending it unencrypted, and encrypting it with an easy-to-use extension he set up for her, why not encrypt it? Surely it can't _hurt_ an already horrible situation?
      - tptacek 15y ago
        Both of these options are worse than not mailing banking information at all. Both of them are worse than encrypting properly, which, in this mom's case, means installing PGP. Yes, in this case, bad crypto can make a bad situation worse: it can create a false sense of security. And in the general case, bad crypto does much worse things than that. Logging in without a password. Flipping bits in a cookie to become any user on the system. Gaining admin privileges. Spoofing authorities to collect secrets from users. Bad crypto does not care how horrible your mom has it. Engineering says, bad crypto is going to be bad no matter how hurt your feelings are.

quadhome 15y ago

I'll wait for the cryptographers to weigh in; but, it's in Javascript.. already a language that's going to be hard to Do It Right in. (The first third of the code is a BigInteger implementation) Then, I looked to see if the standard constant-time comparisons were in there to resist timing attacks. No dice there. So... cool. He put a nice wrapper on JSAES[1], jsSHA2[2] by way of webtoolkit.info[3], RSA and ECC in Javascript by Tom Wu[4], and seedrandom.js by David Bau[5]. But then then says it's "New BSD license"[6] when it should be GPL[7]. I didn't start this comment sound negative. But, I think a few things are important: * Credit authors. * Respect their licenses. * Put a big fucking notice on top of your slick webpage: "FOR DEMONSTRATION PURPOSES ONLY-- NOT REAL CRYPTO" [1] http://point-at-infinity.org/jsaes/ http://point-at-infinity.org/jsaes/ [2] http://anmar.eu.org/projects/jssha2/ http://anmar.eu.org/projects/jssha2/ [3] http://www.webtoolkit.info/javascript-sha256.html http://www.webtoolkit.info/javascript-sha256.html [4] http://www-cs-students.stanford.edu/~tjw/jsbn/ http://www-cs-students.stanford.edu/~tjw/jsbn/ [5] http://davidbau.com/archives/2010/01/30/random_seeds_coded_hints_and_quintillions.html http://davidbau.com/archives/2010/01/30/random_seeds_coded_h... [6] http://code.google.com/p/cryptico/ http://code.google.com/p/cryptico/ [7] http://code.google.com/p/cryptico/source/browse/trunk/aes.js http://code.google.com/p/cryptico/source/browse/trunk/aes.js

etrain 15y ago
He credits the authors in his doc, but agreed on the warning - I am not a cryptographer, but my knowledge of side-channel attacks has me pretty worried that the RSA implementation is not safe.
thinner 15y ago
Does anything qualify as 'real crypto'? Every implementation will always and forever have weaknesses. I don't have a problem with someone putting together a package that makes it easy to do crypto stronger than rot13 - isn't that a step forward? We'd all like GPG/PGP easy in the browser with native code, but until then, what's wrong with an intermediate step that appears to be at least pretty good and fairly easy to use? Maybe it's not enough for organizing a coup, but for keeping your fantasy football strategies a secret - why not?

mkup 15y ago

This thing won't replace https anyway, because if transferred over http, Javascript code could be intercepted and modified by adversary before it reaches client browser and before it is actually executed. And if this JS code is transferred over https, what's the point of it? Don't we already have crypto in this case?

macmac 15y ago
Couldn't the client verify the integrity of the code against a published hash?
- mkup 15y ago
  yes, but hash comparison operator will be executed on client side only if it wasn't stripped away along the path
  - macmac 15y ago
    I was thinking of a manual check, which would be a hassle, but would only have to be done when the script was changed.
  - dagw 15y ago
    I suppose it could be combined with some sort of grease monkey type component, where the user supplies their own hash operator code.
    - sneak 15y ago
      At that point, why bother implementing crypto in JavaScript anyway? You might as well just use a proper clientside app (a halfassed version of which is your suggestion).
- tptacek 15y ago
  No! Very common misconception! You cannot verify the integrity of a browser Javascript cryptosystem by checking a SHA2 hash of the Javascript file containing the crypto. That's because any other piece of content, from Ajax requests and whatnot to, in many browsers, the CSS files, some of them cached and some of them loaded on the spot... any other piece of content that contributed to the page that hosts the crypto code can alter the runtime to trivially intercept secrets or fix keys. Until browsers provide a primitive to verify the whole runtime, cryptographic hashes won't do anything to ensure integrity for Javascript.

sneak 15y ago

From the source: // For best results, put code like // <body onClick='rng_seed_time();' onKeyPress='rng_seed_time();'> // in your main HTML document. And if one doesn't...

tptacek 15y ago
I like the phrasing "for best results". "Cryptography. For best results, use random numbers." (Ping me [see profile] if you want a sticker for finding that issue. They're neat!)

ctz 15y ago

An entertaining and original way of removing PKCS#1 signature padding: var hDigestInfo = biDecryptedSig.toString(16).replace(/^1f+00/, ''); (Just a pity the signature verification function is broken by it.)

moxie 15y ago

There's an interesting problem that is still unsolved in this space. Most people want JS crypto so that webapps can provide "end to end" encryption, relieving participants from having to trust the webapp service with their plaintext. The problem is that trusting you get the correct JS from the webapp for every message you'd like to send is reducible to trusting the webapp with your plaintext. I think there are probably some novel solutions to this problem, but it would require work to be done by the browsers.

tptacek 15y ago
We seem to be on a track now such that in 5 years, all the mainstream browsers will support a set of crypto primitives built into the browser, implemented in C, and exposed via Javascript bindings. And that's fine. But it means that we're not going to have end-to-end crypto in web applications for another ten years, because these schemes don't degrade gracefully; the majority of users will have to upgrade before they become useful.
- moxie 15y ago
  And I'm not sure that this would be enough, either. Crypto primitives are nice, but you still have to trust the webapp to deliver JS which calls those primitives every time you visit the webapp. I believe that this is again reducible to trusting the webapp with your plaintext, since the webapp could selectively intercept any message it chooses.
  - tptacek 15y ago
    A bigger related problem: the argument that browser crypto extensions should be high-level (autogenerating secure keys, automatically MAC'ing ciphertexts, picking the block cipher mode for you) is not winning the day. So what we're going to end up with is an OpenSSL-style interface: x = new Cipher("AES"); x.blockmode = "CBC"; // defaults to all zeroes // x.iv = "ABCDABCDABCDABCD"; x.key = "YELLOW SUBMARINE"; x.encrypt << "This is my plaintext"; In a sense, this is great news for me, because it means I get another 5-10 years of crypto vulnerabilities to get paid to eradicate. But if you're hoping for simple, usable cryptographically strong security in common web apps... well, keep hoping.

tptacek 15y ago

Even if this wasn't browser Javascript and thus totally boned, it think it would still be pretty boned. I'll send a neat looking laptop decal to anyone here who spots any of the flaws in this cryptosystem. But it is written as browser Javascript and is thus totally boned. Here's my attempt to be exhaustive about why: http://www.matasano.com/articles/javascript-cryptography/ http://www.matasano.com/articles/javascript-cryptography/

nbpoole 15y ago
OK, I'm having a lot of fun reading this. One little nitpick: > What systems programming functionality does Javascript lack? Here's a starting point: a secure random number generator. Chrome has actually implemented one (http://blog.chromium.org/2011/06/new-chromium-security-features-june.html http://blog.chromium.org/2011/06/new-chromium-security-featu...). It's a part of WebKit (http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-February/030394.html http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-Feb...). Firefox has an unimplemented (as of Firefox 6) secure RNG API (https://developer.mozilla.org/en/JavaScript_crypto https://developer.mozilla.org/en/JavaScript_crypto, https://bugzilla.mozilla.org/show_bug.cgi?id=440046 https://bugzilla.mozilla.org/show_bug.cgi?id=440046).
JoshTriplett 15y ago
Off the top of my head, reasons why this appears broken even if it didn't use Javascript: The passphrase almost certainly doesn't have 1024 bits of entropy in it, and since they describe it as "used to repeatably generate this RSA key", they can't have introduced any additional entropy. And indeed, they just use the SHA256 of the passphrase to seed a PRNG. They claim that a PublicKeyID "can be used to uniquely identify Sam's public key". Fingerprints help identify keys more easily, but certainly not "uniquely" since they don't have as many bits as the key; pigeonhole principle. Worse, the PublicKeyID uses MD5. They use a public exponent of 3, rather than the usual 65537 or larger. It looks like they might protect against small-exponent attacks, but I don't have enough expertise to know that for certain, and in any case this seems like a bad idea. Neither cryptico nor the rsa-sign library they use mentions anything about HMACs; I haven't dug into the code to figure out if they actually use one or just use a hash directly. Probably piles more, but I stopped there. :)

peterbraden 15y ago

Some thoughts: - Writing crypto systems in dynamic languages is hard/impossible - There is a need for browser based crypto - The browser manufacturers are moving too slowly in this regard

tptacek 15y ago
Writing crypto in dynamic languages is hard but not impossible. Writing crypto in dynamic languages with content-controlled code is probably impossible.
papaf 15y ago
There is a need for browser based crypto I would love to see reasonably secure browser based crypto. You could submit things to a website without the website being able to see what they are. Imagine a social network that was opaque to the people hosting the social network.