4 ms·

That key generator seems to imply javascript-based encryption. The only possible use I can see, is encrypting a file on upload, so MEGA's servers can't look ins

That key generator seems to imply javascript-based encryption. The only possible use I can see, is encrypting a file on upload, so MEGA's servers can't look inside. In which case I'd very much insist on having an open-source desktop client, instead of entrusting encryption to some javascript code which can be hijacked.

nwh 14y ago
Even if the encryption is using a known-good algorithm, there's absolutely no way for the JavaScript client to generate anything close to a cryptographically secure random string for the key. Unless they use random numbers supplied by Mega itself, I just don't see how that would work. If they are using entropy supplied by Mega, then they might as well not bother with the whole encryption thing. ED: The screenshot does mention that they gather entropy via keystrokes and mouse movements (like modern OS do), but I'm still not sure that would provide anywhere near the randomness needed.
- daeken 14y ago
  > Even if the encryption is using a known-good algorithm, there's absolutely no way for the JavaScript client to generate anything close to a cryptographically secure random string for the key. The WebCrypto proposal includes a CSPRNG -- I believe it's now implemented in Gecko and/or Webkit (don't recall which one I saw). However, the bigger concern is that the JS is coming from their servers, which means it's completely compromised by default.
  - deleted 14y ago
    [deleted]
- onli 14y ago
  Why? The screenshot mentions RSA-2048. At which point of that algorithm is random input so important that it breaks the encryption if you don't have access to a true random number generator? I know that you choose p and q by random. And it is obvious that you want to choose numbers that an attacker can't easily guess. But not having access to a hardware number generator doesn't automatically imply you have a real useable vulnerability here, or does it?
  - daeken 14y ago
    Not generating good random numbers is not a huge concern for something like AES, where there's just such a large search space. But with RSA, generating a "bad prime" is the difference between something taking until the death of the sun to break, and taking days. Edit: To clarify, primes for RSA keys are generated probabilistically -- we don't really know that they're prime, we just have a fair amount of confidence to that effect. It's entirely possible to generate bad 'primes' that really aren't prime at all, which makes factoring the keys trivial.
    - onli 14y ago
      Thanks for the answer. But I don't understand that. For generating the prime-numbers used, you basically guess a number and use the miller-rabin-test or something like that to test if prim. Maybe you have a better approach, but generally, that should be equally possible using JS as any other language. You never want to implement something like this yourself for a real product, of course, but i don't see that specific issue. They even could build upon something like jsbn[1] I thought that this is about a missing random number generator. [1]http://www-cs-students.stanford.edu/~tjw/jsbn/ http://www-cs-students.stanford.edu/~tjw/jsbn/
      - daeken 14y ago
        I am not a crytographer (by any means!), but my understanding from conversations with folks in that space is that it's very possible for a bad PRNG to generate primes that pass the standard tests but are still very breakable. I really don't have any more information than that; I should read up more there. Either way, that's by no means the biggest issue here -- some browsers already have CSPRNGs -- but rather that the code is coming from their server and is considered to be compromised by default. Browser-side crypto without very strict security boundaries on key generation and access is just bad news.
    - tptacek 14y ago
      WAT? Bad random numbers are fatal to AES. Attacks against "AES" with a bad RNG don't attack the whole AES keyspace; they attack the bad RNG; in effect, implementing AES with a bad RNG reduces the security of the system to that of the RNG.
- Osiris 14y ago
  I recently switching to Braintree Payments and they have a Javascript client-side library for encrypting the credit card information before sending it to my servers. As they explain it, they use a private/public key encryption in which the server has the private key and the encryption occurs with a public key. Only the private key on their servers can decrypt the file. Could they be using something similar where you generate your own large (2048 bit) key and use that repeatedly for each file that you upload? Could they allow the user to supply their own cryptographic key that can be generated with local tools like openssl? I'm no cryptography expert, I'm just curious what they could do to make it more secure.
  - nwh 14y ago
    That makes sense in that case, and indeed probably increases your security too. Mega are sort of doing things the other way around though. In their case, the user has the secret key and the server only knows the public (or none at all). This only serves to benefit them, as they can't be forced to reveal the content of any particular file. Users could use OpenSSL to make their own strong keys, sure, but if they were they might as well use a local client application (which Mega will probably have). The alternate would be to store a strong private key in localstorage and use that for encryption, though I'm not sure how you'd sell that to the users.
  - rdl 14y ago
    You still generally use a RNG/PRNG to generate a symmetric key for each file you encrypt, use that key to encrypt the data using a symmetric algorithm like AES, and then encrypt that symmetric key under the public key using asymmetric algorithms like RSA. (There are several reasons; symmetric crypto is faster, and there are attacks on asymmetric algorithms based on the plaintext encrypted. Using random key data as the plaintext for the asymmetric algorithm prevents those attacks.) So, even for asymmetric cryptography, a good source of randomness in the browser is an essential part of good crypto. Exposing a randomness source is probably the easiest thing for the browsers to solve -- key management/key storage, code integrity, the DOM, etc. are the more fundamental issues.)
    - jtdowney 14y ago
- deleted 14y ago
  [deleted]
- SideburnsOfDoom 14y ago
  Does Javascript-based encryption imply Javascript-based key generation? Key generation could be done on a server despite the presence of a progress bar in the web client. It doesn't have to stay only the server, or even be kept on the server at all. Actually, all the screenshot is showing is Javascript-based entropy gathering. It does not demonstrate that any of the other steps are necessarily done on the client.

nwh 14y ago

Even if the encryption is using a known-good algorithm, there's absolutely no way for the JavaScript client to generate anything close to a cryptographically secure random string for the key. Unless they use random numbers supplied by Mega itself, I just don't see how that would work. If they are using entropy supplied by Mega, then they might as well not bother with the whole encryption thing. ED: The screenshot does mention that they gather entropy via keystrokes and mouse movements (like modern OS do), but I'm still not sure that would provide anywhere near the randomness needed.

daeken 14y ago
> Even if the encryption is using a known-good algorithm, there's absolutely no way for the JavaScript client to generate anything close to a cryptographically secure random string for the key. The WebCrypto proposal includes a CSPRNG -- I believe it's now implemented in Gecko and/or Webkit (don't recall which one I saw). However, the bigger concern is that the JS is coming from their servers, which means it's completely compromised by default.
- deleted 14y ago
  [deleted]
onli 14y ago
Why? The screenshot mentions RSA-2048. At which point of that algorithm is random input so important that it breaks the encryption if you don't have access to a true random number generator? I know that you choose p and q by random. And it is obvious that you want to choose numbers that an attacker can't easily guess. But not having access to a hardware number generator doesn't automatically imply you have a real useable vulnerability here, or does it?
- daeken 14y ago
  Not generating good random numbers is not a huge concern for something like AES, where there's just such a large search space. But with RSA, generating a "bad prime" is the difference between something taking until the death of the sun to break, and taking days. Edit: To clarify, primes for RSA keys are generated probabilistically -- we don't really know that they're prime, we just have a fair amount of confidence to that effect. It's entirely possible to generate bad 'primes' that really aren't prime at all, which makes factoring the keys trivial.
  - onli 14y ago
    Thanks for the answer. But I don't understand that. For generating the prime-numbers used, you basically guess a number and use the miller-rabin-test or something like that to test if prim. Maybe you have a better approach, but generally, that should be equally possible using JS as any other language. You never want to implement something like this yourself for a real product, of course, but i don't see that specific issue. They even could build upon something like jsbn[1] I thought that this is about a missing random number generator. [1]http://www-cs-students.stanford.edu/~tjw/jsbn/ http://www-cs-students.stanford.edu/~tjw/jsbn/
    - daeken 14y ago
      I am not a crytographer (by any means!), but my understanding from conversations with folks in that space is that it's very possible for a bad PRNG to generate primes that pass the standard tests but are still very breakable. I really don't have any more information than that; I should read up more there. Either way, that's by no means the biggest issue here -- some browsers already have CSPRNGs -- but rather that the code is coming from their server and is considered to be compromised by default. Browser-side crypto without very strict security boundaries on key generation and access is just bad news.
  - tptacek 14y ago
    WAT? Bad random numbers are fatal to AES. Attacks against "AES" with a bad RNG don't attack the whole AES keyspace; they attack the bad RNG; in effect, implementing AES with a bad RNG reduces the security of the system to that of the RNG.
Osiris 14y ago
I recently switching to Braintree Payments and they have a Javascript client-side library for encrypting the credit card information before sending it to my servers. As they explain it, they use a private/public key encryption in which the server has the private key and the encryption occurs with a public key. Only the private key on their servers can decrypt the file. Could they be using something similar where you generate your own large (2048 bit) key and use that repeatedly for each file that you upload? Could they allow the user to supply their own cryptographic key that can be generated with local tools like openssl? I'm no cryptography expert, I'm just curious what they could do to make it more secure.
- nwh 14y ago
  That makes sense in that case, and indeed probably increases your security too. Mega are sort of doing things the other way around though. In their case, the user has the secret key and the server only knows the public (or none at all). This only serves to benefit them, as they can't be forced to reveal the content of any particular file. Users could use OpenSSL to make their own strong keys, sure, but if they were they might as well use a local client application (which Mega will probably have). The alternate would be to store a strong private key in localstorage and use that for encryption, though I'm not sure how you'd sell that to the users.
- rdl 14y ago
  You still generally use a RNG/PRNG to generate a symmetric key for each file you encrypt, use that key to encrypt the data using a symmetric algorithm like AES, and then encrypt that symmetric key under the public key using asymmetric algorithms like RSA. (There are several reasons; symmetric crypto is faster, and there are attacks on asymmetric algorithms based on the plaintext encrypted. Using random key data as the plaintext for the asymmetric algorithm prevents those attacks.) So, even for asymmetric cryptography, a good source of randomness in the browser is an essential part of good crypto. Exposing a randomness source is probably the easiest thing for the browsers to solve -- key management/key storage, code integrity, the DOM, etc. are the more fundamental issues.)
  - jtdowney 14y ago
deleted 14y ago
[deleted]
SideburnsOfDoom 14y ago
Does Javascript-based encryption imply Javascript-based key generation? Key generation could be done on a server despite the presence of a progress bar in the web client. It doesn't have to stay only the server, or even be kept on the server at all. Actually, all the screenshot is showing is Javascript-based entropy gathering. It does not demonstrate that any of the other steps are necessarily done on the client.