13 ms·

What is uncool is that it's using AES-GCM in all of its 128 bit glory, which is subpar compared to just using libsodium like magic-wormhole does.

by iaml 5y ago

feross 5y ago
Please don't spread FUD. AES-GCM 128 is perfectly fine and it's standard for a reason.
- tptacek 5y ago
  AES-GCM is imperfectly fine and its standard has nothing to do with any of it. It's inferior in more than one way to the Chapoly-style ciphers in Sodium. Case in point: it looks like if callers to your ECE library pass in a repeated salt through Keychain for any reason, you'll generate a duplicate nonce, which blows up GCM. There are authenticated ciphers that mitigate this problem (most commonly: by having a nonce wide enough that you can simply always generate it randomly without requiring callers to manage it); GCM, on the other hand, is the poster child for that flaw. Since this is browser crypto, and not native execution like Magic Wormhole, all of this is irrelevant; the important distinction between the two projects isn't that one uses a lesser cryptosystem, but rather that the other uses real end-to-end cryptography and the other uses client-server cryptography pretending to be end-to-end.
  - feross 5y ago
    > the other uses client-server cryptography pretending to be end-to-end This is misleading and false. Wormhole.app uses end-to-end encryption. To address the larger point – auditing a web app is indeed challenging with current web technologies. In the past, I experimented with a technique using App Cache to permanently cache a web app on first use [1]. Later, that technique was expanded into hyperboot [2] to give users the benefits of explicit, immutable versioning with control over upgrades using the html-version-spec while preserving the simplicity of passing around a URL. With the impending removal of AppCache from most browsers, the web is currently missing a way to "pin" a site to a specific version and only update it with user consent. Service Workers come close but they mandate a 24 hour maximum cache time before refetching from the server. We'd love to offer the usability benefits of web apps – you can give someone a URL and they can immediately load the app – with the security of installed apps – doesn't change without warning – once web standards catch up. This is something that I care deeply about. In the meantime, use magic-wormhole if you prefer a locally-installed command line tool and you're sending files to someone who understands the command line. Use Wormhole.app if you want usable end-to-end encryption, similar to what Firefox Send used to provide. [1]: https://github.com/feross/infinite-app-cache https://github.com/feross/infinite-app-cache [2]: https://github.com/substack/hyperboot https://github.com/substack/hyperboot
    - tptacek 5y ago
      I stand by my analysis.
    - psanford 5y ago
      > if you prefer a locally-installed command line tool and you're sending files to someone who understands the command line There's at least one good desktop GUI for Magic Wormhole[0]. I've also recently released an Magic Wormhole Android app[1][2]. [0]: https://github.com/Jacalz/wormhole-gui https://github.com/Jacalz/wormhole-gui [1]: https://github.com/psanford/wormhole-william-mobile https://github.com/psanford/wormhole-william-mobile [2]: https://play.google.com/store/apps/details?id=io.sanford.wormhole_william https://play.google.com/store/apps/details?id=io.sanford.wor...
  - injinj 5y ago
    Do I have this right? 1. A duplicate salt, which in this case should be a 16 byte random value, causes an repeated use of an KEY+IV for AES, which allows for a dictionary attack on the KEY (which looks like a password in this case) and weaker encryption because there will be multiple files encrypted with the same KEY+IV. What are the authenticated ciphers that mitigate this? 2. The end-to-end property is useful because of man in the middle attacks, since the stream is sent to the server unencrypted and the server does the encryption work.
    - feross 5y ago
      Is this comment in reference to Wormhole.app? If so, it contains multiple inaccuracies. 1. The salt is only ever used once. All shared files are concatenated into a single stream and encrypted one time. 2. Only end-to-end encrypted file data is sent to the server. By definition, the server cannot be involved in end-to-end encryption.
      - tptacek 5y ago
        I'm referring only to the library Wormhole uses for this, and its security UX, and to the implications of using vanilla AES-GCM. I don't know of and haven't looked for vulnerabilities in your application. I wouldn't have fully agreed with the grandparent comment either, but your refutation was also inaccurate, so here we are.
        codezero 5y ago
        This thread is really annoying to me. I see two people I look up to basically talking past one another in a situation where one of them could be providing a lot more advice, as I've seen them do on many occasions, but seems not to want to because they are mad about a naming decision. Every thread on hacker news that devolves into a fight over a name choice is pointless and distracts from the good work people are doing. Names are hard, and they're even harder to change, we should come up with a more productive way to have that conversation, or not have it at all. In the mean time, I'm super disappointed.
  - minitech 5y ago
    > Since this is browser crypto, and not native execution like Magic Wormhole, all of this is irrelevant; the important distinction between the two projects isn't that one uses a lesser cryptosystem, but rather that the other uses real end-to-end cryptography and the other uses client-server cryptography pretending to be end-to-end. Is my reading of this as a vague and misleading way of saying that because the code responsible for the encryption is provided by the server it doesn’t count as end-to-end encryption accurate? Or is it an even vaguer hint towards something else?
    - feross 5y ago
      > Is my reading of this as a vague and misleading way of saying that because the code responsible for the encryption is provided by the server it doesn’t count as end-to-end encryption accurate? This is how I read tptacek's comment as well. It's vague and misleading to say that any code provided to a client by a server cannot be end-to-end encryption. By that logic, even something like the Signal Desktop client (which has an auto-updater) is not end-to-end encryption. This is a not a reasonable or honest definition of end-to-end encryption.
      - tptacek 5y ago
        The point of end-to-end cryptography is not having to trust servers. Your argument is that a system that appears to need to trust its server on an HTTP-request-by-HTTP-request basis must be end-to-end, because browsers on either side also do some cryptography. But that's not how it works.
        feross 5y ago
        You can't invent your own definition of end-to-end encryption. There is a material difference between a service which end-to-end encrypts your files – even if it sends you the code to do so – and one which does not. Services like Dropbox or WeTransfer receive plaintext copies of your files. Firefox Send did not. And Wormhole, using the same design, does not either.

What is uncool is that it's using AES-GCM in all of its 128 bit glory, which is subpar compared to just using libsodium like magic-wormhole does.

by iaml 5y ago

What is uncool is that it's using AES-GCM in all of its 128 bit glory, which is subpar compared to just using libsodium like magic-wormhole does.

feross 5y ago

Please don't spread FUD. AES-GCM 128 is perfectly fine and it's standard for a reason.

tptacek 5y ago
AES-GCM is imperfectly fine and its standard has nothing to do with any of it. It's inferior in more than one way to the Chapoly-style ciphers in Sodium. Case in point: it looks like if callers to your ECE library pass in a repeated salt through Keychain for any reason, you'll generate a duplicate nonce, which blows up GCM. There are authenticated ciphers that mitigate this problem (most commonly: by having a nonce wide enough that you can simply always generate it randomly without requiring callers to manage it); GCM, on the other hand, is the poster child for that flaw. Since this is browser crypto, and not native execution like Magic Wormhole, all of this is irrelevant; the important distinction between the two projects isn't that one uses a lesser cryptosystem, but rather that the other uses real end-to-end cryptography and the other uses client-server cryptography pretending to be end-to-end.
- feross 5y ago
  > the other uses client-server cryptography pretending to be end-to-end This is misleading and false. Wormhole.app uses end-to-end encryption. To address the larger point – auditing a web app is indeed challenging with current web technologies. In the past, I experimented with a technique using App Cache to permanently cache a web app on first use [1]. Later, that technique was expanded into hyperboot [2] to give users the benefits of explicit, immutable versioning with control over upgrades using the html-version-spec while preserving the simplicity of passing around a URL. With the impending removal of AppCache from most browsers, the web is currently missing a way to "pin" a site to a specific version and only update it with user consent. Service Workers come close but they mandate a 24 hour maximum cache time before refetching from the server. We'd love to offer the usability benefits of web apps – you can give someone a URL and they can immediately load the app – with the security of installed apps – doesn't change without warning – once web standards catch up. This is something that I care deeply about. In the meantime, use magic-wormhole if you prefer a locally-installed command line tool and you're sending files to someone who understands the command line. Use Wormhole.app if you want usable end-to-end encryption, similar to what Firefox Send used to provide. [1]: https://github.com/feross/infinite-app-cache https://github.com/feross/infinite-app-cache [2]: https://github.com/substack/hyperboot https://github.com/substack/hyperboot
  - tptacek 5y ago
    I stand by my analysis.
  - psanford 5y ago
    > if you prefer a locally-installed command line tool and you're sending files to someone who understands the command line There's at least one good desktop GUI for Magic Wormhole[0]. I've also recently released an Magic Wormhole Android app[1][2]. [0]: https://github.com/Jacalz/wormhole-gui https://github.com/Jacalz/wormhole-gui [1]: https://github.com/psanford/wormhole-william-mobile https://github.com/psanford/wormhole-william-mobile [2]: https://play.google.com/store/apps/details?id=io.sanford.wormhole_william https://play.google.com/store/apps/details?id=io.sanford.wor...
- injinj 5y ago
  Do I have this right? 1. A duplicate salt, which in this case should be a 16 byte random value, causes an repeated use of an KEY+IV for AES, which allows for a dictionary attack on the KEY (which looks like a password in this case) and weaker encryption because there will be multiple files encrypted with the same KEY+IV. What are the authenticated ciphers that mitigate this? 2. The end-to-end property is useful because of man in the middle attacks, since the stream is sent to the server unencrypted and the server does the encryption work.
  - feross 5y ago
    Is this comment in reference to Wormhole.app? If so, it contains multiple inaccuracies. 1. The salt is only ever used once. All shared files are concatenated into a single stream and encrypted one time. 2. Only end-to-end encrypted file data is sent to the server. By definition, the server cannot be involved in end-to-end encryption.
    - tptacek 5y ago
      I'm referring only to the library Wormhole uses for this, and its security UX, and to the implications of using vanilla AES-GCM. I don't know of and haven't looked for vulnerabilities in your application. I wouldn't have fully agreed with the grandparent comment either, but your refutation was also inaccurate, so here we are.
      - codezero 5y ago
        This thread is really annoying to me. I see two people I look up to basically talking past one another in a situation where one of them could be providing a lot more advice, as I've seen them do on many occasions, but seems not to want to because they are mad about a naming decision. Every thread on hacker news that devolves into a fight over a name choice is pointless and distracts from the good work people are doing. Names are hard, and they're even harder to change, we should come up with a more productive way to have that conversation, or not have it at all. In the mean time, I'm super disappointed.
- minitech 5y ago
  > Since this is browser crypto, and not native execution like Magic Wormhole, all of this is irrelevant; the important distinction between the two projects isn't that one uses a lesser cryptosystem, but rather that the other uses real end-to-end cryptography and the other uses client-server cryptography pretending to be end-to-end. Is my reading of this as a vague and misleading way of saying that because the code responsible for the encryption is provided by the server it doesn’t count as end-to-end encryption accurate? Or is it an even vaguer hint towards something else?
  - feross 5y ago
    > Is my reading of this as a vague and misleading way of saying that because the code responsible for the encryption is provided by the server it doesn’t count as end-to-end encryption accurate? This is how I read tptacek's comment as well. It's vague and misleading to say that any code provided to a client by a server cannot be end-to-end encryption. By that logic, even something like the Signal Desktop client (which has an auto-updater) is not end-to-end encryption. This is a not a reasonable or honest definition of end-to-end encryption.
    - tptacek 5y ago
      The point of end-to-end cryptography is not having to trust servers. Your argument is that a system that appears to need to trust its server on an HTTP-request-by-HTTP-request basis must be end-to-end, because browsers on either side also do some cryptography. But that's not how it works.
      - feross 5y ago
        You can't invent your own definition of end-to-end encryption. There is a material difference between a service which end-to-end encrypts your files – even if it sends you the code to do so – and one which does not. Services like Dropbox or WeTransfer receive plaintext copies of your files. Firefox Send did not. And Wormhole, using the same design, does not either.