4 ms·

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 ser

by 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
  John from Braintree here. In the case of our client-side encryption library we use sjcl (http://crypto.stanford.edu/sjcl/ http://crypto.stanford.edu/sjcl/) to generate the symmetric keys for encryption. This library uses Ferguson and Schneier's Fortuna PRNG to generate random values. The main entropy source is crypto.getRandomValues (https://developer.mozilla.org/en-US/docs/DOM/window.crypto.getRandomValues https://developer.mozilla.org/en-US/docs/DOM/window.crypto.g...) where it is available. In other places it uses mouse movements to provide entropy for the PRNG.
  - rdl 14y ago
    What do you do on touchscreen tablets running on non-firefox, non-webkit browsers (which don't have the RNG exported)? The only devices I could think of which meet that description are RIM Playbook and maybe Windows Phone, or maybe IE on horrible devices which have touchscreens.
    - abrowne 14y ago
      The Playbook browser is a webkit variant.

by Osiris 14y ago

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
John from Braintree here. In the case of our client-side encryption library we use sjcl (http://crypto.stanford.edu/sjcl/ http://crypto.stanford.edu/sjcl/) to generate the symmetric keys for encryption. This library uses Ferguson and Schneier's Fortuna PRNG to generate random values. The main entropy source is crypto.getRandomValues (https://developer.mozilla.org/en-US/docs/DOM/window.crypto.getRandomValues https://developer.mozilla.org/en-US/docs/DOM/window.crypto.g...) where it is available. In other places it uses mouse movements to provide entropy for the PRNG.
- rdl 14y ago
  What do you do on touchscreen tablets running on non-firefox, non-webkit browsers (which don't have the RNG exported)? The only devices I could think of which meet that description are RIM Playbook and maybe Windows Phone, or maybe IE on horrible devices which have touchscreens.
  - abrowne 14y ago
    The Playbook browser is a webkit variant.