4 ms·

> Instead, copies of the server's role in the key negotiation are stored by a centralized server for potential clients to fetch and use. This "centralised" and

by ChoHag 10y ago

> Instead, copies of the server's role in the key negotiation are stored by a centralized server for potential clients to fetch and use. This "centralised" and "server" are just about the worst words you want to hear in the description of a system like this and yet they are just thrown in there in a flippant comment at the end of a section? I think a more detailed description of this glorified cache is warranted.

ChoHag 10y ago
Oh it's not warranted is it? Does whichever butthurt shill clicked that button want to suggest why we don't need more detail on which central server stores what in this self-proclaimed "secure" system?
- stouset 10y ago
  Perhaps people are responding to your unwarranted, toxic tone, your rudeness elsewhere in the comments, and your inability to give even a modicum of respect to the developers who've not only designed and openly published groundbreaking advances in secure private messaging protocols, and not only implemented them and freely distributed those implementations, but have also worked to have those designs incorporated into the some of the most widely-used messaging software in history.
  - ChoHag 10y ago
    It lacks the most basic, fundamental property of a secure system: A demonstration (actual proof can wait!) that it can be trusted without handwavium. I don't care if it's the dog's bollocks or the bee's knees. If I can't trust it, it's useless for secure communication. I don't give the tiniest shit how many hours some twat on the internet, or well-paid collection of highly-trained twats, has poured into its creation if they can't even be arsed to give a basic description of its most fundamental property. And that moniker can remain until they do.
    - Canada 10y ago
      Feel free to propose a secure, decentralized way to pass the payload between the endpoints. Be sure your solution includes an effective mechanism to mitigate spam. Bonus if your solution denies attackers access to the same metadata centralized systems do. Double bonus if you can support push messaging systems to deliver timely notification that users have come to expect.
      - ChoHag 10y ago
        I'm not trying to propose a "way" of anything, "secure", "decentralised" or otherwise! Don't you get it? I'm talking about the documentation. I have no idea if this solution to the problems posed is sound because before I can even get to the source code there is no description of how or even whether it solves the fundamental problems in the cryptographic situation it describes (viz. device which cannot straightaway engage in IP communication requires to receive unsolicitated securely-encrypted messages).
        Canada 10y ago
        > whether it solves the fundamental problems in the cryptographic situation it describes (viz. device which cannot straightaway engage in IP communication requires to receive unsolicitated securely-encrypted messages). Please elaborate and clarify.
      - Natanael_L 10y ago
        Home servers connected over I2P, hopefully.
  - newjersey 10y ago
    Instead of responding to the tone, let's concentrate on the merits. For most people, it is unacceptable to require both parties to be simultaneously online in a chat session. I'm very interested in any potential implementation that allows asymmetric conversations without a dedicated third node (if we don't like the name server) somewhere in between.
    - stouset 10y ago
      Of course tone is relevant. Tone is how one has a civil conversation with another person, even if they disagree.
      - newjersey 10y ago
        Ah, thanks for displaying your civility with a down vote, downvoter. Some people are rougher around the edges than others. I thought this place was a sjw heaven but clearly some people want this place to be a monoculture as well.
        sctb 10y ago
        > Please resist commenting about being downvoted. It never does any good, and it makes boring reading. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
      - dredmorbius 10y ago
        Tone matters. It's not everything, but it matters. There are people, and/or messages, in which a lack of civility needn't warrant a complete dismissal. They're relatively rare. I'm willing to give a hearing here. Crypto is, for better or worse, an area in which there is a tendency toward both informed and abrasive contributions. I'm aware HN doesn't take well to that. I've been arguing the opposite strategy for the past few days with a friend (he likes tossing bollocks about, I prefer avoiding that). I'd advise ChoHag to tone it down (and reconsider their chosen handle), but contribute. I did consider vouching the flagged/dead comment, but decided against in this case.
- sctb 10y ago
  You can't go off about downvotes like this on Hacker News. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
detaro 10y ago
The server role seems quite clearly described in more detail in the actual protocol description, is there something missing? The section you quote just describes the high-level idea of why and how to introduce the server in the scheme.
- ChoHag 10y ago
  No. If the section beginning "Protocol" is what you refer to as the "actual protocol description" then no, the server role does not seem clearly described in any level of detail. To cut a long story short: Alice gives the cache, aka Mallory, a set of secret data which are implied but not proven to be able to be used by Bob to create cryptographic text which Alice can decrypt but this magic cache, aka Mallory, cannot. This document provides few hints and no detail on how we can be assured that the magic cache, A.K.A. MALLORY, is unable to make use of the secret data provided by Alice (and "promised not to be shared") to make inferrences on the crypyographic text provided by Bob.
  - dfox 10y ago
    The cache contains ephemeral _PUBLIC_ keys, that would otherwise be transmitted to anyone who requests them by the message recipient (perhaps through some encrypted channel, but without meaningful authentication). In essence it's the same thing as PGP's encryption subkeys, which are completely published, but the cache contains more of them as the keys are preferably only used once (there is one difference in that the cache gives only one key at a time and will not give the same public key again as long as it contains enough of them). So: making the whole thing completely public only enables adversary to match session initializations with receivers, which the server can do by definition as it has to route the messages to correct recipient. (In the case without such central server, anybody observing the traffic could do that, as another role of the central server is to mask sender addresses on the lower protocol layers)
    - ChoHag 10y ago
      Good! Say that! Then the entire protocol and its description can be reduced to "this is a cache of ephemeral public keys and messages encrypted using them". I know that doesn't sound quite so impressive, but that's because it isn't.

by ChoHag 10y ago

ChoHag 10y ago

Oh it's not warranted is it? Does whichever butthurt shill clicked that button want to suggest why we don't need more detail on which central server stores what in this self-proclaimed "secure" system?

stouset 10y ago
Perhaps people are responding to your unwarranted, toxic tone, your rudeness elsewhere in the comments, and your inability to give even a modicum of respect to the developers who've not only designed and openly published groundbreaking advances in secure private messaging protocols, and not only implemented them and freely distributed those implementations, but have also worked to have those designs incorporated into the some of the most widely-used messaging software in history.
- ChoHag 10y ago
  It lacks the most basic, fundamental property of a secure system: A demonstration (actual proof can wait!) that it can be trusted without handwavium. I don't care if it's the dog's bollocks or the bee's knees. If I can't trust it, it's useless for secure communication. I don't give the tiniest shit how many hours some twat on the internet, or well-paid collection of highly-trained twats, has poured into its creation if they can't even be arsed to give a basic description of its most fundamental property. And that moniker can remain until they do.
  - Canada 10y ago
    Feel free to propose a secure, decentralized way to pass the payload between the endpoints. Be sure your solution includes an effective mechanism to mitigate spam. Bonus if your solution denies attackers access to the same metadata centralized systems do. Double bonus if you can support push messaging systems to deliver timely notification that users have come to expect.
    - ChoHag 10y ago
      I'm not trying to propose a "way" of anything, "secure", "decentralised" or otherwise! Don't you get it? I'm talking about the documentation. I have no idea if this solution to the problems posed is sound because before I can even get to the source code there is no description of how or even whether it solves the fundamental problems in the cryptographic situation it describes (viz. device which cannot straightaway engage in IP communication requires to receive unsolicitated securely-encrypted messages).
      - Canada 10y ago
        > whether it solves the fundamental problems in the cryptographic situation it describes (viz. device which cannot straightaway engage in IP communication requires to receive unsolicitated securely-encrypted messages). Please elaborate and clarify.
    - Natanael_L 10y ago
      Home servers connected over I2P, hopefully.
- newjersey 10y ago
  Instead of responding to the tone, let's concentrate on the merits. For most people, it is unacceptable to require both parties to be simultaneously online in a chat session. I'm very interested in any potential implementation that allows asymmetric conversations without a dedicated third node (if we don't like the name server) somewhere in between.
  - stouset 10y ago
    Of course tone is relevant. Tone is how one has a civil conversation with another person, even if they disagree.
    - newjersey 10y ago
      Ah, thanks for displaying your civility with a down vote, downvoter. Some people are rougher around the edges than others. I thought this place was a sjw heaven but clearly some people want this place to be a monoculture as well.
      - sctb 10y ago
        > Please resist commenting about being downvoted. It never does any good, and it makes boring reading. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
    - dredmorbius 10y ago
      Tone matters. It's not everything, but it matters. There are people, and/or messages, in which a lack of civility needn't warrant a complete dismissal. They're relatively rare. I'm willing to give a hearing here. Crypto is, for better or worse, an area in which there is a tendency toward both informed and abrasive contributions. I'm aware HN doesn't take well to that. I've been arguing the opposite strategy for the past few days with a friend (he likes tossing bollocks about, I prefer avoiding that). I'd advise ChoHag to tone it down (and reconsider their chosen handle), but contribute. I did consider vouching the flagged/dead comment, but decided against in this case.
sctb 10y ago
You can't go off about downvotes like this on Hacker News. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

detaro 10y ago

The server role seems quite clearly described in more detail in the actual protocol description, is there something missing? The section you quote just describes the high-level idea of why and how to introduce the server in the scheme.

ChoHag 10y ago
No. If the section beginning "Protocol" is what you refer to as the "actual protocol description" then no, the server role does not seem clearly described in any level of detail. To cut a long story short: Alice gives the cache, aka Mallory, a set of secret data which are implied but not proven to be able to be used by Bob to create cryptographic text which Alice can decrypt but this magic cache, aka Mallory, cannot. This document provides few hints and no detail on how we can be assured that the magic cache, A.K.A. MALLORY, is unable to make use of the secret data provided by Alice (and "promised not to be shared") to make inferrences on the crypyographic text provided by Bob.
- dfox 10y ago
  The cache contains ephemeral _PUBLIC_ keys, that would otherwise be transmitted to anyone who requests them by the message recipient (perhaps through some encrypted channel, but without meaningful authentication). In essence it's the same thing as PGP's encryption subkeys, which are completely published, but the cache contains more of them as the keys are preferably only used once (there is one difference in that the cache gives only one key at a time and will not give the same public key again as long as it contains enough of them). So: making the whole thing completely public only enables adversary to match session initializations with receivers, which the server can do by definition as it has to route the messages to correct recipient. (In the case without such central server, anybody observing the traffic could do that, as another role of the central server is to mask sender addresses on the lower protocol layers)
  - ChoHag 10y ago
    Good! Say that! Then the entire protocol and its description can be reduced to "this is a cache of ephemeral public keys and messages encrypted using them". I know that doesn't sound quite so impressive, but that's because it isn't.