3 ms·

> While it does not stop even the most basic active attackers You just admitted that it's useless! https://adamcaudill.com/2014/02/25/on-opportunistic-encrypt

> While it does not stop even the most basic active attackers You just admitted that it's useless! https://adamcaudill.com/2014/02/25/on-opportunistic-encryption/ https://adamcaudill.com/2014/02/25/on-opportunistic-encrypti...

mehrdada 11y ago
> You just admitted that it's useless! No, I do not believe stopping passive attacks is useless.
- sarciszewski 11y ago
  When you stop passive attacks, then attackers will just step up their game to active attacks. If you want to call something secure, you need to design a threat model that doesn't involve an attacker with one arm tied behind their back. That doesn't serve anyone's interests, except maybe the blackhats'.
  - mehrdada 11y ago
    > When you stop passive attacks, then attackers will just step up their game to active attacks. Not always. It often changes the economics of the game. Especially when facing mass surveillance, considering the potential risk of detectability. Just because some attackers can step up their game for some targets, it does not imply they will do the same for all targets. > If you want to call something secure... I don't disagree with your point of view about what can or cannot be called "secure". One can debate that definition. However, stopping passive attackers is often NOT useless and it does add value. Security is not a binary proposition.
    - sarciszewski 11y ago
      Sure, but consider this: Do you know what stops all passive attackers and most active attackers? TLS. Do you know what WebCrypto adds that TLS doesn't? Nothing. That's why this is useless. Just use TLS correctly and you're better off. Now, reframe this as "desktop application that uses libsodium in a protocol designed by cryptography engineer" and suddenly my interest is piqued.
      - mehrdada 11y ago
        > Do you know what WebCrypto adds that TLS doesn't? Nothing. No, consider this: an end-to-end encrypted messaging web page delivered over TLS that stores keys in browser local storage. A passive attacker that can see the incoming traffic on the server but does not want to alter the JavaScript sent to the clients will never see the messages. I argue this is weak but not useless. (I would argue all TLS encryption in the browser is, in a sense, opportunistic to a certain extent, since very rarely people look at the address bar, effectively making it unauthenticated.)
- tptacek 11y ago
  Systems that stop only "passive" attackers simply aren't cryptographically secure.
  - mehrdada 11y ago
    "Cryptographically secure" sounds like a vague thing you bring up here. To me, it sounds it is by definition secure (and cryptographically so, if they use cryptography) against passive attackers (and probably nothing else), but I am not really debating abstract and fuzzy definitions here. My objection is very concrete: to say whatever uses JavaScript cryptography is as secure as TLS is false. Precisely, what it means is for all threat models imaginable, if you can somehow subvert TLS, you can always break the JavaScript crypto, and this is obviously false at least for one scenario I described in the other comment. We could reasonably debate the likelihood of the scenarios, but it's really hard to argue the mathematical equivalence of the two.

mehrdada 11y ago

> You just admitted that it's useless! No, I do not believe stopping passive attacks is useless.

sarciszewski 11y ago
When you stop passive attacks, then attackers will just step up their game to active attacks. If you want to call something secure, you need to design a threat model that doesn't involve an attacker with one arm tied behind their back. That doesn't serve anyone's interests, except maybe the blackhats'.
- mehrdada 11y ago
  > When you stop passive attacks, then attackers will just step up their game to active attacks. Not always. It often changes the economics of the game. Especially when facing mass surveillance, considering the potential risk of detectability. Just because some attackers can step up their game for some targets, it does not imply they will do the same for all targets. > If you want to call something secure... I don't disagree with your point of view about what can or cannot be called "secure". One can debate that definition. However, stopping passive attackers is often NOT useless and it does add value. Security is not a binary proposition.
  - sarciszewski 11y ago
    Sure, but consider this: Do you know what stops all passive attackers and most active attackers? TLS. Do you know what WebCrypto adds that TLS doesn't? Nothing. That's why this is useless. Just use TLS correctly and you're better off. Now, reframe this as "desktop application that uses libsodium in a protocol designed by cryptography engineer" and suddenly my interest is piqued.
    - mehrdada 11y ago
      > Do you know what WebCrypto adds that TLS doesn't? Nothing. No, consider this: an end-to-end encrypted messaging web page delivered over TLS that stores keys in browser local storage. A passive attacker that can see the incoming traffic on the server but does not want to alter the JavaScript sent to the clients will never see the messages. I argue this is weak but not useless. (I would argue all TLS encryption in the browser is, in a sense, opportunistic to a certain extent, since very rarely people look at the address bar, effectively making it unauthenticated.)
tptacek 11y ago
Systems that stop only "passive" attackers simply aren't cryptographically secure.
- mehrdada 11y ago
  "Cryptographically secure" sounds like a vague thing you bring up here. To me, it sounds it is by definition secure (and cryptographically so, if they use cryptography) against passive attackers (and probably nothing else), but I am not really debating abstract and fuzzy definitions here. My objection is very concrete: to say whatever uses JavaScript cryptography is as secure as TLS is false. Precisely, what it means is for all threat models imaginable, if you can somehow subvert TLS, you can always break the JavaScript crypto, and this is obviously false at least for one scenario I described in the other comment. We could reasonably debate the likelihood of the scenarios, but it's really hard to argue the mathematical equivalence of the two.