5 ms·

Mosh would be more widely available, outside of just this 'reference implementation', if it did not use patent encumbered OCB crypto. Phillip Rogaway holds pat

by st3fan 10y ago

Mosh would be more widely available, outside of just this 'reference implementation', if it did not use patent encumbered OCB crypto. Phillip Rogaway holds patents relevant to OCB. See the following for his patent grant: http://www.cs.ucdavis.edu/~rogaway/ocb/grant.htm http://www.cs.ucdavis.edu/~rogaway/ocb/grant.htm I think this is the primary reason why there are still no alternative clients. And specifically, no good Mobile clients. The reliance on OCB is unfortunate. I wish the Mosh developers would introduce multiple cipher schemes so that people can move away from OCB. Unfortunately the protocol is also pretty poorly designed, with no easy backward compatible way to do this. For example, when a client starts a session, the server prints "MOSH CONNECT 60001 sdmDrHqo8DBdpKxtAFAUyw" where the last part is the OCB key. It should have been prefixed with the ciper type for extensibility, but it is not. So this would need a backward incompatible redesign to get it going.

shakna 10y ago
> And specifically, no good Mobile clients. I use JuiceSSH [0] on Android, which is based around mosh-client. It works great... What precisely do you mean by the above? [0] https://juicessh.com/ https://juicessh.com/
jitl 10y ago
Is Blink "bad"? It works for me. http://www.blink.sh http://www.blink.sh
- st3fan 10y ago
  It is not bad. But it took 5 years.
  - brians 10y ago
    It is missing the one crucial feature: resuming the last session after a while away!
    - goerz 10y ago
      Why do you think it's missing it? It has the same persistence as the mosh-client on a deskop. That is, the connection will persist as long as the client process exists. If you are observing anything else, that would justify a bug report on Blink. The one complication is that iOS can sometimes kill background processes at will, which would also kill the mosh-connection. As far as I know, the Blink team is currently working on dealing with this better (issue #59). It shouldn't happen very often, though, and I've certainly had Blink persist in the background for multiple days.
Flowdalic 10y ago
> The reliance on OCB is unfortunate. I wish the Mosh developers would introduce multiple cipher schemes so that people can move away from OCB. Isn't OCB an open standard? https://www.rfc-editor.org/rfc/rfc7253.txt https://www.rfc-editor.org/rfc/rfc7253.txt
- tptacek 10y ago
  "Open standard" doesn't really mean anything. It's standardized, in that there is a standard (actually, multiple compatible standards) that you can code to and end up with interoperable OCB. The complaint upthread is that OCB is patented, which it is. But for many years now, OCB has been free for open source software.
  - st3fan 10y ago
    The license terms are vague. Is it connected to OpenSSL or not? Do you have to ask the author permission or not? And it is limited to open source software. Nobody wants to involve expensive lawyers, so for many folks that rules out OCB. Mosh is a great idea, but by connecting it to OCB, the authors completely stalled more widespread adoption. That, and like you said, the complete lack of protocol spec.
    - tptacek 10y ago
      It's not vague: it's not connected to OpenSSL. You do not need permission; you need to use an OSI-compliant license for your software.
JdeBP 10y ago
One reason that independent alternatives do not exist is nothing to do with patents, and everything to do with the protocol never actually being properly documented. * https://news.ycombinator.com/item?id=11612615 https://news.ycombinator.com/item?id=11612615 Make that 5 years and counting.
tptacek 10y ago
This is a red herring. OCB --- which is possibly the best "mainstream" authenticated encryption construction --- has a blanket patent license for open source software. It applies to any software licensed under any license recognized by OSI, and its only restriction is that the license is withdrawn if you initiate patent litigation. OCB should be far more widely used than it is. Meanwhile, configurable "cipher schemes" have in practice been a disaster. They are, for instance, the reason we still have RC4 in TLS today, despite knowing for almost 2 decades now that RC4 is broken.
- Shish2k 10y ago
  > Meanwhile, configurable "cipher schemes" have in practice been a disaster. They are, for instance, the reason we still have RC4 in TLS today, despite knowing for almost 2 decades now that RC4 is broken. If TLS had hard-coded RC4 with no alternatives, how would we be better off?
  - tptacek 10y ago
    You have one cipher, deployed in exactly one authenticated encryption construction. The protocol has a version. If the cipher is weakened or broken, you upgrade the whole protocol. You don't add better ciphersuites to the existing protocol to compensate. Having a bunch of ciphersuites, all believed at the time of their inclusion to be strong, just maximizes the attack surface of the protocol. Having ciphersuite negotiation at all practically guarantees that interoperability will require lowest-common-denominator security.

by st3fan 10y ago

shakna 10y ago

> And specifically, no good Mobile clients. I use JuiceSSH [0] on Android, which is based around mosh-client. It works great... What precisely do you mean by the above? [0] https://juicessh.com/ https://juicessh.com/

jitl 10y ago

Is Blink "bad"? It works for me. http://www.blink.sh http://www.blink.sh

st3fan 10y ago
It is not bad. But it took 5 years.
- brians 10y ago
  It is missing the one crucial feature: resuming the last session after a while away!
  - goerz 10y ago
    Why do you think it's missing it? It has the same persistence as the mosh-client on a deskop. That is, the connection will persist as long as the client process exists. If you are observing anything else, that would justify a bug report on Blink. The one complication is that iOS can sometimes kill background processes at will, which would also kill the mosh-connection. As far as I know, the Blink team is currently working on dealing with this better (issue #59). It shouldn't happen very often, though, and I've certainly had Blink persist in the background for multiple days.

Flowdalic 10y ago

> The reliance on OCB is unfortunate. I wish the Mosh developers would introduce multiple cipher schemes so that people can move away from OCB. Isn't OCB an open standard? https://www.rfc-editor.org/rfc/rfc7253.txt https://www.rfc-editor.org/rfc/rfc7253.txt

tptacek 10y ago
"Open standard" doesn't really mean anything. It's standardized, in that there is a standard (actually, multiple compatible standards) that you can code to and end up with interoperable OCB. The complaint upthread is that OCB is patented, which it is. But for many years now, OCB has been free for open source software.
- st3fan 10y ago
  The license terms are vague. Is it connected to OpenSSL or not? Do you have to ask the author permission or not? And it is limited to open source software. Nobody wants to involve expensive lawyers, so for many folks that rules out OCB. Mosh is a great idea, but by connecting it to OCB, the authors completely stalled more widespread adoption. That, and like you said, the complete lack of protocol spec.
  - tptacek 10y ago
    It's not vague: it's not connected to OpenSSL. You do not need permission; you need to use an OSI-compliant license for your software.

JdeBP 10y ago

One reason that independent alternatives do not exist is nothing to do with patents, and everything to do with the protocol never actually being properly documented. * https://news.ycombinator.com/item?id=11612615 https://news.ycombinator.com/item?id=11612615 Make that 5 years and counting.

tptacek 10y ago

This is a red herring. OCB --- which is possibly the best "mainstream" authenticated encryption construction --- has a blanket patent license for open source software. It applies to any software licensed under any license recognized by OSI, and its only restriction is that the license is withdrawn if you initiate patent litigation. OCB should be far more widely used than it is. Meanwhile, configurable "cipher schemes" have in practice been a disaster. They are, for instance, the reason we still have RC4 in TLS today, despite knowing for almost 2 decades now that RC4 is broken.

Shish2k 10y ago
> Meanwhile, configurable "cipher schemes" have in practice been a disaster. They are, for instance, the reason we still have RC4 in TLS today, despite knowing for almost 2 decades now that RC4 is broken. If TLS had hard-coded RC4 with no alternatives, how would we be better off?
- tptacek 10y ago
  You have one cipher, deployed in exactly one authenticated encryption construction. The protocol has a version. If the cipher is weakened or broken, you upgrade the whole protocol. You don't add better ciphersuites to the existing protocol to compensate. Having a bunch of ciphersuites, all believed at the time of their inclusion to be strong, just maximizes the attack surface of the protocol. Having ciphersuite negotiation at all practically guarantees that interoperability will require lowest-common-denominator security.