3 ms·

With the recent revelations that private internet companies (ISPs) are colluding with the NSA, I very much doubt the security of certificates issued by a "certi

by j_m_b 13y ago

With the recent revelations that private internet companies (ISPs) are colluding with the NSA, I very much doubt the security of certificates issued by a "certificate authority". I really like the idea of Secure Remote Password (SRP) which uses a Diffie–Hellman-like key exchange instead of relying on third party certificates. The main difficulties I see to SRP adoption are: 1) Not all browsers natively support SRP, though this is changing. You therefore need a good javascript library for interfacing with the server. This of course leads to 2) No trustworthy javascript crypto library exists with the possible exception of the incomplete SJCL. The biggest problem current JS libraries have is that of 3) generating random numbers. Because there is no cryptographically secure rand() javascript implementation, the solution I've seen is to use mouse movement or other user input to generate random numbers. The problem with this is that it takes ~30 seconds of random movement from the user to "seed" the generator! One interesting method I've thought about is to use http://www.fourmilab.ch/hotbits/ http://www.fourmilab.ch/hotbits/ to retrieve random numbers, but this just leads back to depending on a third party for secure communications. I think an efficient, cryptographically secure pseudo random number generator is the biggest deficit to js-based crypto tools.

tptacek 13y ago
I'm not sure how to engage with the idea that SRP is a viable replacement for certificate authentication; it only works with the client and server have a pre-shared key. I very much do not trust certificate authorities, but observe that you don't have to trust certificate authorities to make the security architecture of TLS work. Already, CA compromises have a minimized impact on properties like Google Mail, whose certificates are pinned in Chrome and Firefox. Soon, all properties will get the same privilege, when we adopt schemes like TACK that allow dynamic certificate pinning. As soon as a critical mass of browsers support dynamic pinning, it will become drastically less profitable to target CAs, because attempts to present forged certificates to Internet users en masse will quickly be detected.
- j_m_b 13y ago
  > it only works with the client and server have a pre-shared key What "pre-shared key" are you referring to in SRP? The only a priori value needed for SRP is the safe prime (N) and generator (g).
  - tptacek 13y ago
    The password.
jnbiche 13y ago
This doesn't necessarily solve your problem, but new versions of Firefox, Chrome, Opera, and IE all provide CSPRNGs. It's experimental, but it's been available in Firefox for several versions. So if you have a modern browser, just open your console window, and try: window.crypto.getRandomValues(typedArray) On mobile, this random number generator is unfortunately not available on Android's browser, although it is available on Chrome for Android, Firefox Mobile, and Safari on iOS and up. There's also a full browser-based Crypography API in the works. You can see the draft here: http://www.w3.org/TR/WebCryptoAPI/ http://www.w3.org/TR/WebCryptoAPI/ Once all of this is implemented, the chicken and egg problem is solved, since the browser will then have native crypto primitives available. At that point, the main argument I see against browser-based crypto in JavaScript is the malleability of the Javascript runtime. And if you believe that's an intractable problem, then you should probably reconsider the use of any language for crypto that can be monkey-patched, including common server-side languages like Python, Ruby, and to a certain extent PHP.
- j_m_b 13y ago
  I didn't know about the window.crypto.getRandomValues(typedArray). Thanks! > And if you believe that's an intractable problem, then you should probably reconsider the use of any language for crypto that can be monkey-patched, including common server-side languages like Python, Ruby, and to a certain extent PHP. Someone else in this thread mentioned http://www.defensivejs.com/ http://www.defensivejs.com/ and I think it is going in the right direction.
MarkMc 13y ago
Don't you need to trust a certification authority in order to be sure that the browser running SRP hasn't been tampered with?

by j_m_b 13y ago

tptacek 13y ago

I'm not sure how to engage with the idea that SRP is a viable replacement for certificate authentication; it only works with the client and server have a pre-shared key. I very much do not trust certificate authorities, but observe that you don't have to trust certificate authorities to make the security architecture of TLS work. Already, CA compromises have a minimized impact on properties like Google Mail, whose certificates are pinned in Chrome and Firefox. Soon, all properties will get the same privilege, when we adopt schemes like TACK that allow dynamic certificate pinning. As soon as a critical mass of browsers support dynamic pinning, it will become drastically less profitable to target CAs, because attempts to present forged certificates to Internet users en masse will quickly be detected.

j_m_b 13y ago
> it only works with the client and server have a pre-shared key What "pre-shared key" are you referring to in SRP? The only a priori value needed for SRP is the safe prime (N) and generator (g).
- tptacek 13y ago
  The password.

jnbiche 13y ago

This doesn't necessarily solve your problem, but new versions of Firefox, Chrome, Opera, and IE all provide CSPRNGs. It's experimental, but it's been available in Firefox for several versions. So if you have a modern browser, just open your console window, and try: window.crypto.getRandomValues(typedArray) On mobile, this random number generator is unfortunately not available on Android's browser, although it is available on Chrome for Android, Firefox Mobile, and Safari on iOS and up. There's also a full browser-based Crypography API in the works. You can see the draft here: http://www.w3.org/TR/WebCryptoAPI/ http://www.w3.org/TR/WebCryptoAPI/ Once all of this is implemented, the chicken and egg problem is solved, since the browser will then have native crypto primitives available. At that point, the main argument I see against browser-based crypto in JavaScript is the malleability of the Javascript runtime. And if you believe that's an intractable problem, then you should probably reconsider the use of any language for crypto that can be monkey-patched, including common server-side languages like Python, Ruby, and to a certain extent PHP.

j_m_b 13y ago
I didn't know about the window.crypto.getRandomValues(typedArray). Thanks! > And if you believe that's an intractable problem, then you should probably reconsider the use of any language for crypto that can be monkey-patched, including common server-side languages like Python, Ruby, and to a certain extent PHP. Someone else in this thread mentioned http://www.defensivejs.com/ http://www.defensivejs.com/ and I think it is going in the right direction.

MarkMc 13y ago

Don't you need to trust a certification authority in order to be sure that the browser running SRP hasn't been tampered with?