JCryption - JavaScript data encryption

http://www.jcryption.org/

by Oompa • 17 years ago

37 39 17 years ago

dryicerx2• 17 years ago

There is no way to validate the public key the data is encrypted against, so a man in the middle is possible by injecting a new public key and intercepting the cypher-text on its way back.

Just my though, if this type of security is needed, why forego SSL?

brown9-2• 17 years ago

The author claims SSL is neither supported by every webhost nor it’s easy to install/apply sometimes.

Not sure if I totally buy that - if you are collecting data you want to protect, surely it's worth it for you to use a host that's capable of installing SSL. It's a pretty simple operation.

tptacek13• 17 years ago

Injecting a new public key? Heh. You can MITM this library just by inserting a JS tag into the DOM that turns its "encryption" off. No need to be clever.

dryicerx2• 17 years ago

This will tip the server off as it won't receive the expected cyphertext.

By doing a mitm interception with a newly injected public key and re-encrypting with the real key before sending to server, you can let the client-server carry on a conversation as usual, while you intercept the entire conversation.

[Client] ---(fakekey)---- MITM ----(realkey)---- [Server]

epe• 17 years ago

Voted up in hopes that tptacek sees this so I can watch him rip it apart. ;)

NateLawson3• 17 years ago

Ironically, it looks like the talk I gave on common crypto flaws also made HN today (http://news.ycombinator.com/item?id=748164). What's funny is it explains exactly why Javascript crypto is a bad idea, but it appears to have less votes than this one.

tptacek13• 17 years ago

I think this library is a great idea. We can add its signature to automated scanning tools, and feed it to Google Code Search queries, and periodically generate lists of catastrophically insecure web applications. I much prefer a single, easily-detected security failure than a diverse population of more subtle failures. Kudos to this guy.

I will send a Matasano poster to anybody who posts a valid flaw in actual implementation of this library, excluding the fatal design flaw of delivering encryption code via Javascript to browsers.

I'll get you started (I've already got a poster): this library uses PHP's builtin mt_rand() to generate keys.

sriramk• 17 years ago

Not a crypto person. I'm pretty sure this is going to be ripped apart by tptacker, NateLawson or cperciva. But I'll speak up anyway :-)

I see a lot of sites use HTTP basic auth to do usernames/passwords (especially startups). Or worse, they send it over the clear (for e.g., some very popular APIs out there which I shall not name). Their reasons vary but typically it is one of cost and convenience. It is of course a terrible practice.

Compared to HTTP basic auth, this seems less evil. In this case, with no implementation issues, I assume you need an active attacker. With HTTP basic, you can just grep logs and decrypt credentials.

This seems the lesser of two evils.

Please be gentle :-)

NateLawson3• 17 years ago

Yes, basic auth with no encryption is bad. In some cases, this is no better though.

For example, if the key and JS are provided by the server, then it is the same as basic auth (all data needed to obtain the plaintext password is in the HTTP session). If the key is generated locally on the client, you have the problem of including a good enough PRNG, seeded from enough entropy that the attacker can't guess it.

And those are all purely passive attacks (no MITM interjection). Active attacks could include modifying the JS to insert another field in the FORM POST response that is the plaintext key.

lonestar• 17 years ago

From main.php: $keyLength = 256;

I'm assuming most people who would choose to use this library will just copy his example code and use 256 bit keys, which are very easy to factor.

keefe2• 17 years ago

"use 256 bit keys, which are very easy to factor.".... uh, cite source please?

paulbaumgart5• 17 years ago

I know next to nothing about crypto, but just a bit of Googling came up with:

"Mersenne Twister is not cryptographically secure. (MT is based on a linear recursion. Any pseudorandom number sequence generated by a linear recursion is insecure, since from sufficiently long subsequence of the outputs, one can predict the rest of the outputs.)

To make it secure, you need to use some Secure Hashing Algorithm with MT. For example, you may gather every eight words of outputs, and compress them into one word (thus the length of the output sequence is 1/8 of the original one)."

http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/efaq.html <-- And since that's the "Mersenne Twister Home Page", I'll take his word for it. :-)

So, looking at the PHP source code for mt_rand():

  PHPAPI php_uint32 php_mt_rand(TSRMLS_D)
  {
    /* Pull a 32-bit integer from the generator state
       Every other access function simply transforms the numbers extracted here */

    register php_uint32 s1;

    if (BG(left) == 0) {
        php_mt_reload(TSRMLS_C);
    }
    --BG(left);

    s1 = *BG(next)++;
    s1 ^= (s1 >> 11);
    s1 ^= (s1 <<  7) & 0x9d2c5680U;
    s1 ^= (s1 << 15) & 0xefc60000U;
    return ( s1 ^ (s1 >> 18) );
  }

Which doesn't seem like it qualifies as a cryptographically secure implementation; I don't see any Secure Hashing going on.

tptacek13• 17 years ago

You can't just hash a cryptographically insecure RNG and turn it into a cryptographically secure RNG. =)

If you need secure random numbers in PHP, the best advice I have off the top of my head is to take it from /dev/urandom.

axod• 17 years ago

All security is about levels though - nothing is secure. This library obviously fills a specific level, and provides some protection. It'd certainly make some guy in the IT dept packet sniffing likely give up.

You're not going to use it for a banking website, but saying it's useless as you seem to be, seems odd to me.

tptacek13• 17 years ago

See previous comment, re: XOR encryption. It's all about levels! Get 95% of the value of this level with 1/1000th as much code.

paulbaumgart5• 17 years ago

In that vein, Javascript's Math.random, while the implementation is JS-engine specific (so I'm hesitant to condemn it across the board), hardly qualifies as a CSPRNG either.

tptacek13• 17 years ago

No, it doesn't; that's why you're supposed to use java.security.SecureRandom.

yread• 17 years ago

Why do they use RSA? Isn't Diffie-Hellman a better method? Exchange keys by DH and then encrypt traffic symmetricaly. Is it reasonable?

tptacek13• 17 years ago

No, using DH would be even worse here than using RSA; JS crypto is intinsically vulnerable to MITM attacks, but so is DH --- an attacker just runs DH independently with both sides of the transaction, zeroing or fixating the key.

More comments about how they used RSA? Fire away, I'll send you a poster. They're pretty neat, if bigger than I expected.

codahale• 17 years ago

Oh, gross.

They just pass the plaintext right through to RSA. No OAEP, just bang right into the BigInt. There's some random gibberish appended to the plaintext ("hey, this needs some salt"), but they're not padding a damn thing. Bleichenbacher's chosen-ciphertext attack; game over.

The RSA decryption, server-side, isn't blinded at all. Timing attack free-for-all there. Boneh's timing attack might work, as long as you can pin the session down. (And since this is for folks who don't get SSL, I'm sure you could.)

And key generation is equally horrible. The lack of a real CSPRNG was pointed out by someone else. They're also not protecting against Fermat factorization: when they generate p and q they only check equality and primality, not distance. Same with small decryption exponents. Unlikely to be serious, but it sure doesn't speak to their skills as cryptographic implementers.

Jesus H. Christ. What a train wreck.

sweis• 17 years ago

This does raw RSA in ECB mode. It is vulnerable to both chosen-plaintext and replay attacks.

JCryption - JavaScript data encryption

Related Stories