7 ms·

Javascript encryption

43 points by aberatiu 15y ago

acqq 15y ago
John Walker made that already at least 6 years ago: http://www.fourmilab.ch/javascrypt/ http://www.fourmilab.ch/javascrypt/ Moreover, Walker's code is public domain and he discusses security aspect, whereas the op link appears not to care about such things.
- d0ne 15y ago
  Similarly with Movable-Type's implementation: http://www.movable-type.co.uk/scripts/aes.html http://www.movable-type.co.uk/scripts/aes.html http://www.movable-type.co.uk/ http://www.movable-type.co.uk/ contains several very useful resources for implementing JS crypto.
  - tptacek 15y ago
    ... which, implementing JS crypto, you should never do.
    - d0ne 15y ago
      If your goal is to share state secrets, then no, I wouldn't suggest using JS for crypto. If your goal is to no longer be low hanging fruit for attackers, then yes, I would recommend it.
      - tptacek 15y ago
        The terminus of your argument admits to using ROT13 as a cipher. Surely there's some attacker ROT13 bars. While you're at it, Base64 the "ciphertext". There are professional pentesters that can't recognize Base64 on sight! And if you want to get really tricksy, swap the Base64 alphabet around. That'll hoist that fruit up higher. In reality, no credible cryptosystem accepts the flaws I'm talking about.
        jrockway 15y ago
        That's true, but I'm not sure everyone should be quite so defeatist as you with respect to implementing crypto. It has and can be done, after all, it just requires care beyond "hey, my PHP script outputs some HTML." The same goes for many, many aspects of programming: design, object lifecycle, memory allocation, error handling, etc. Programming is hard, and implementing crypto is no different. The difference is that mistakes are not immediately obvious and that they can be severe. But that, again, is the case with many things.
        thaumaturgy 15y ago
        If there's anything I've learned so far after observing the security world for a few years, it's that implementing crypto is very different. I think that this mindset from programmers -- "crypto is just like programming" -- is what causes them to constantly, and almost without fail, screw up their password storage systems, their authentication mechanisms, their crypto functions, and pretty much everything else security-related. Software development in general tolerates (and in some ways even encourages) "acceptable risk". Programmers don't often try to prove that their functions are correct and free of any potential errors. In security-related programming, you can't take the same approach. Implementing crypto is very, very different. If you're "iterating" the design of your crypto functions, you're doing it wrong.
        jrockway 15y ago
        The reason people screw up password storage is because they don't know they are supposed to think about it. If they flipped the "oh, this is important" switch, the result would be better. But at the end of the day, their bosses are asking them for shiny widgets, not a secure backend. So they are doomed to fail. The same goes for the non-security things I've listed. The problem is much deeper than getting crypto wrong -- most programmers today get everything wrong. That's why I think if you're the type of person that can think about programming, it's not too unsafe to implement AES in Javascript and use it. You know what the weaknesses of Javascript-based crypto are, and you know how to implement crypto. In that case, why not do it? Remember: most non-crypto software is massively incorrect. If we can trust people to implement crypto, why can we trust them to be programmers at all?
      - thaumaturgy 15y ago
        That looks suspiciously like security theatre: "this adds no actual security, but it will discourage simple attacks."
antimora 15y ago
Could anyone explain what's the use case for encrypting text on a web page using JavaScript? I don't understand how this library is useful except for situation when used in Chrome extensions like the one used by LastPass. If this lib is used on a page to decrypt/encrypt user data before sending to the server, theoretically it's possible for the host to steal private key simply by injecting a JS code that copies user's private key.
- netnichols 15y ago
  The first thought I had was to be able to store personal data on a server and have secure access from any web browser. Basically a simplified version of 1PasswordAnywhere (http://help.agilebits.com/1Password3/1passwordanywhere.html http://help.agilebits.com/1Password3/1passwordanywhere.html). Update: I should probably note that I haven't looked at the implementation, and there's no way I'd do as I mention above without having complete control of sources.
- clintjhill 15y ago
  Maybe not encrypting text on a page, but possibly to encrypt JSON data to local storage for persistence. Never do this with absolutely private data, but then again.
- tptacek 15y ago
  It's worse than that. Among many other things, it's possible for any attacker with an XSS bug in any component of the DOM of that page (cached or fetched fresh) to steal keys. Modern browsers provide no way to verify the whole JS runtime to ensure that no function that your crypto depends on has been backdoored, but every JS implementation allows functions to be overridden. It's the worst possible environment to implement crypto in, and you should never do it.
  - DenisM 15y ago
    XSS is in your own control (as a site owner/developer), and it is less likely to happen than the user machine being infested with malware to begin with. And the malware infestation threat has never stopped anyone from advocating native (non-browser) crypto, right?.
KonradKlause 15y ago
Snakeoil
antihero 15y ago
What does this offer over SJCL? And for those asking in the thread, JS encryption is useful in that you never have to trust a server with your plaintext.
- gorset 15y ago
  If you are running javascript on a page from a server, you are trusting the server with your plaintext.
  - Acorn 15y ago
    Seems like browser extensions would be the way to go. Here's the SJCL demo: http://bitwiseshiftleft.github.com/sjcl/demo/ http://bitwiseshiftleft.github.com/sjcl/demo/
    - dublinclontarf 15y ago
      SJCL has a bug in their RSA implementation. We're using a good bit of their code with a few changes for our web client. The idea being that we don't want to store passwords, so the webclient stores an encrpyted private key and everything sent to the server must be signed. The users id is a sha256 hash of their public key and all we keep are the public keys. Working so far in FF and Chrome, not even trying it in IE
      - yid 15y ago
        Not sure what you mean, SJCL doesn't have an RSA implementation.
        dublinclontarf 15y ago
        Hmmm, indeed it doesn't. Who's RSA implementation am I using, guess I've forgotten.
        yid 15y ago
st3fan 15y ago
Looks like a nice implementation. But I would feel more comfortable if it had some tests to show that the AES test vectors all pass.
oconnore 15y ago
Be careful: if you are using a javascript library to encrypt data, you get protection from eavesdroppers, but not from man-in-the-middle attacks. If I can alter data that you send/receive over the wire, I can simply modify your aes function calls to xor the data with a predictable sequence that I generate. The only way to prevent this that I have thought of is to store the site (which has presumably already been acquired over a secure channel) locally on the client's machine, and make AJAX calls over the encrypted channel for fresh content.
- thaumaturgy 15y ago
  > *...if you are using a javascript library to encrypt data, you get protection from eavesdroppers..." Nope. Replay attacks. Piece of cake. The number of things that JavaScript does better than SSL is 0.
  - oconnore 15y ago
    I don't think you know what you are talking about. If your authentication is implicit in the decryption of the messages, replaying that data will accomplish nothing. For example, if I share a secret "password" with my server, I can do this in javascript using any symmetric cipher: ToServer: "My name is oconnore" ToClient: cipher(iv1, "(C1) Hi oconnore. Use this! iv2=rng()"++msghash, "password") ToServer: cipher(iv2, "(C2) Thanks, give me my data please!"++msghash, "password") ToClient: cipher(iv3, "(C3) <Some data>, and iv4=rng()"++msghash, "password") ... If an attacker repeats any of these messages, the client/server will discard them based on the counter. Of course, for real use you would need to use public key crypto to avoid storing passwords in what is essentially plaintext, but I thought this would illustrate how replay attacks are a non issue. Of course, as noted before, all this is irrelevant if you are sending your code over a channel vulnerable to MITM...
dguido 15y ago
Relevant: http://rdist.root.org/2010/11/29/final-post-on-javascript-crypto/ http://rdist.root.org/2010/11/29/final-post-on-javascript-cr... The killer for me has always been #7 on Nate Lawson's list: Auditability. How do you tell that your browser is using the right copy of the code to do the crypto?
- thaumaturgy 15y ago
  This should be at the top.
- antimora 15y ago
  This is an excellent article on this subject. The author (Nate Lawson) is thorough in his argument. His conclusion is "I am certain JS crypto does not make security sense."

43 points by aberatiu 15y ago

acqq 15y ago

John Walker made that already at least 6 years ago: http://www.fourmilab.ch/javascrypt/ http://www.fourmilab.ch/javascrypt/ Moreover, Walker's code is public domain and he discusses security aspect, whereas the op link appears not to care about such things.

d0ne 15y ago
Similarly with Movable-Type's implementation: http://www.movable-type.co.uk/scripts/aes.html http://www.movable-type.co.uk/scripts/aes.html http://www.movable-type.co.uk/ http://www.movable-type.co.uk/ contains several very useful resources for implementing JS crypto.
- tptacek 15y ago
  ... which, implementing JS crypto, you should never do.
  - d0ne 15y ago
    If your goal is to share state secrets, then no, I wouldn't suggest using JS for crypto. If your goal is to no longer be low hanging fruit for attackers, then yes, I would recommend it.
    - tptacek 15y ago
      The terminus of your argument admits to using ROT13 as a cipher. Surely there's some attacker ROT13 bars. While you're at it, Base64 the "ciphertext". There are professional pentesters that can't recognize Base64 on sight! And if you want to get really tricksy, swap the Base64 alphabet around. That'll hoist that fruit up higher. In reality, no credible cryptosystem accepts the flaws I'm talking about.
      - jrockway 15y ago
        That's true, but I'm not sure everyone should be quite so defeatist as you with respect to implementing crypto. It has and can be done, after all, it just requires care beyond "hey, my PHP script outputs some HTML." The same goes for many, many aspects of programming: design, object lifecycle, memory allocation, error handling, etc. Programming is hard, and implementing crypto is no different. The difference is that mistakes are not immediately obvious and that they can be severe. But that, again, is the case with many things.
        thaumaturgy 15y ago
        If there's anything I've learned so far after observing the security world for a few years, it's that implementing crypto is very different. I think that this mindset from programmers -- "crypto is just like programming" -- is what causes them to constantly, and almost without fail, screw up their password storage systems, their authentication mechanisms, their crypto functions, and pretty much everything else security-related. Software development in general tolerates (and in some ways even encourages) "acceptable risk". Programmers don't often try to prove that their functions are correct and free of any potential errors. In security-related programming, you can't take the same approach. Implementing crypto is very, very different. If you're "iterating" the design of your crypto functions, you're doing it wrong.
        jrockway 15y ago
        The reason people screw up password storage is because they don't know they are supposed to think about it. If they flipped the "oh, this is important" switch, the result would be better. But at the end of the day, their bosses are asking them for shiny widgets, not a secure backend. So they are doomed to fail. The same goes for the non-security things I've listed. The problem is much deeper than getting crypto wrong -- most programmers today get everything wrong. That's why I think if you're the type of person that can think about programming, it's not too unsafe to implement AES in Javascript and use it. You know what the weaknesses of Javascript-based crypto are, and you know how to implement crypto. In that case, why not do it? Remember: most non-crypto software is massively incorrect. If we can trust people to implement crypto, why can we trust them to be programmers at all?
    - thaumaturgy 15y ago
      That looks suspiciously like security theatre: "this adds no actual security, but it will discourage simple attacks."

antimora 15y ago

Could anyone explain what's the use case for encrypting text on a web page using JavaScript? I don't understand how this library is useful except for situation when used in Chrome extensions like the one used by LastPass. If this lib is used on a page to decrypt/encrypt user data before sending to the server, theoretically it's possible for the host to steal private key simply by injecting a JS code that copies user's private key.

netnichols 15y ago
The first thought I had was to be able to store personal data on a server and have secure access from any web browser. Basically a simplified version of 1PasswordAnywhere (http://help.agilebits.com/1Password3/1passwordanywhere.html http://help.agilebits.com/1Password3/1passwordanywhere.html). Update: I should probably note that I haven't looked at the implementation, and there's no way I'd do as I mention above without having complete control of sources.
clintjhill 15y ago
Maybe not encrypting text on a page, but possibly to encrypt JSON data to local storage for persistence. Never do this with absolutely private data, but then again.
tptacek 15y ago
It's worse than that. Among many other things, it's possible for any attacker with an XSS bug in any component of the DOM of that page (cached or fetched fresh) to steal keys. Modern browsers provide no way to verify the whole JS runtime to ensure that no function that your crypto depends on has been backdoored, but every JS implementation allows functions to be overridden. It's the worst possible environment to implement crypto in, and you should never do it.
- DenisM 15y ago
  XSS is in your own control (as a site owner/developer), and it is less likely to happen than the user machine being infested with malware to begin with. And the malware infestation threat has never stopped anyone from advocating native (non-browser) crypto, right?.

KonradKlause 15y ago

Snakeoil

antihero 15y ago

What does this offer over SJCL? And for those asking in the thread, JS encryption is useful in that you never have to trust a server with your plaintext.

gorset 15y ago
If you are running javascript on a page from a server, you are trusting the server with your plaintext.
- Acorn 15y ago
  Seems like browser extensions would be the way to go. Here's the SJCL demo: http://bitwiseshiftleft.github.com/sjcl/demo/ http://bitwiseshiftleft.github.com/sjcl/demo/
  - dublinclontarf 15y ago
    SJCL has a bug in their RSA implementation. We're using a good bit of their code with a few changes for our web client. The idea being that we don't want to store passwords, so the webclient stores an encrpyted private key and everything sent to the server must be signed. The users id is a sha256 hash of their public key and all we keep are the public keys. Working so far in FF and Chrome, not even trying it in IE
    - yid 15y ago
      Not sure what you mean, SJCL doesn't have an RSA implementation.
      - dublinclontarf 15y ago
        Hmmm, indeed it doesn't. Who's RSA implementation am I using, guess I've forgotten.
        yid 15y ago

st3fan 15y ago

Looks like a nice implementation. But I would feel more comfortable if it had some tests to show that the AES test vectors all pass.

oconnore 15y ago

Be careful: if you are using a javascript library to encrypt data, you get protection from eavesdroppers, but not from man-in-the-middle attacks. If I can alter data that you send/receive over the wire, I can simply modify your aes function calls to xor the data with a predictable sequence that I generate. The only way to prevent this that I have thought of is to store the site (which has presumably already been acquired over a secure channel) locally on the client's machine, and make AJAX calls over the encrypted channel for fresh content.

thaumaturgy 15y ago
> *...if you are using a javascript library to encrypt data, you get protection from eavesdroppers..." Nope. Replay attacks. Piece of cake. The number of things that JavaScript does better than SSL is 0.
- oconnore 15y ago
  I don't think you know what you are talking about. If your authentication is implicit in the decryption of the messages, replaying that data will accomplish nothing. For example, if I share a secret "password" with my server, I can do this in javascript using any symmetric cipher: ToServer: "My name is oconnore" ToClient: cipher(iv1, "(C1) Hi oconnore. Use this! iv2=rng()"++msghash, "password") ToServer: cipher(iv2, "(C2) Thanks, give me my data please!"++msghash, "password") ToClient: cipher(iv3, "(C3) <Some data>, and iv4=rng()"++msghash, "password") ... If an attacker repeats any of these messages, the client/server will discard them based on the counter. Of course, for real use you would need to use public key crypto to avoid storing passwords in what is essentially plaintext, but I thought this would illustrate how replay attacks are a non issue. Of course, as noted before, all this is irrelevant if you are sending your code over a channel vulnerable to MITM...

dguido 15y ago

Relevant: http://rdist.root.org/2010/11/29/final-post-on-javascript-crypto/ http://rdist.root.org/2010/11/29/final-post-on-javascript-cr... The killer for me has always been #7 on Nate Lawson's list: Auditability. How do you tell that your browser is using the right copy of the code to do the crypto?

thaumaturgy 15y ago
This should be at the top.
antimora 15y ago
This is an excellent article on this subject. The author (Nate Lawson) is thorough in his argument. His conclusion is "I am certain JS crypto does not make security sense."