<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">The core Mosh code in Blink is current
with Mosh after the 1.2.6 release, after my performance changes.
That code creates a graph of differences/history via the
smart-pointer shared Rows that it uses, though it doesn't
explicitly use/look at the graph structure. I would have to
review the code to be sure, but I think you might lose some info
(probably resulting in larger differences) if you didn't save all
diffs. I think you're safe blindly saving/restoring the entire
list of states, and in the iOS client app save/kill/restore flow,
it would be highly unusual for that complete list to take
significantly more storage/compute than a more minimal list. For
that to happen, I think you'd have to do something like <br>
<br>
start a session<br>
lose connectivity to the server<br>
type quite a lot or paste a large amount of text into the frozen
session<br>
switch away from the app and invoke the state-save code<br>
<br>
In the common case, where Mosh is idle or the updates reflect
normal typing, the list of states will have one large initial
state, and the following states will be empty or very small
updates.<br>
<br>
I would guess the saved state is unlikely to exceed 2MB even on
the large iPad Pro, especially if you're able to save the state as
serialized, compressed Messages. I recently did a small
refactoring in the serialization and deserialization code paths
that I think will help you access serialized but unencrypted
Messages, actually. I wasn't even thinking of this problem at
all-- I did it on general principles-- but now I'm happy I did
it. See commit 255dc39. If it doesn't, let me know and we can
try and improve that.<br>
<br>
It's not clear (to me) whether encrypting the session on the
network, and the session state on persistent storage, are the same
security problem/domain. I think it might be better to use a
separate, local key for encrypting the data at rest, and not reuse
the session key, but it really requires some more thought and
analysis. I vaguely recall that the iOS keystore has a
get-and-destroy operator as well. If this actually exists and you
used this in conjunction with a newly generated local key and
maybe an OS boot-unique id each time you saved the state to
persistent storage, I think that might nicely avoid the
possibility of accidental session reuse. If the iOS keystore has
key options to make the key volatile (non-persistent across
reboot) and/or local (not backed up, iCloud, etc), these would
also be useful in this case. Again, Crypto is Hard, and these are
ideas, not advice.<br>
<br>
I remember looking over the iOS keystore API and writing some
email or notes previously, but I can't find that now-- if I find a
private note I'll add that to this discussion.<br>
<br>
regards,<br>
<br>
--jh<br>
<br>
On 11/9/16 8:03 PM, Keith Winstein wrote:<br>
</div>
<blockquote
cite="mid:CAMzhQmMTdX2qmCaXn-sOd-jQVe0DKiZKC6SRckr_SjoMKssK9w@mail.gmail.com"
type="cite">
<div dir="ltr">Hello Carlos,
<div><br>
</div>
<div>Sounds cool! I think you will need to save every state
newer than the "throwaway number," because the other side is
allowed to reference that state (or any newer state that you
have acked) in building a new diff.</div>
<div><br>
</div>
<div>My main fear with these saved states is that a user would
somehow be able to try "resuming" the same session twice, from
the same save file. That will result in the same sequence
number being reused, which would be cryptographically
catastrophic. So any implementation that allows "resuming"
from a saved state must ensure that the saved state is
destroyed as part of the resumption.</div>
<div><br>
</div>
<div>-Keith</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Wed, Nov 9, 2016 at 3:14 PM, Carlos
Cabanero <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:carlosecabanero@gmail.com" target="_blank">carlosecabanero@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<p
style="margin:0px;font-size:12px;line-height:normal;font-family:helvetica;color:rgb(69,69,69)">I
have started to work on “Persistent Connections” for
Blink with great success! For background, these are the
related GH issues (<a moz-do-not-send="true"
href="https://github.com/mobile-shell/mosh/issues/394"
target="_blank">https://github.com/mobile-<wbr>shell/mosh/issues/394</a>)
and (<a moz-do-not-send="true"
href="https://github.com/blinksh/blink/issues/59"
target="_blank"><span style="color:rgb(228,175,9)">https://github.com/blinksh/<wbr>blink/issues/59</span></a>).</p>
<p
style="margin:0px;font-size:12px;line-height:normal;font-family:helvetica;color:rgb(69,69,69);min-height:14px"><br>
</p>
<p
style="margin:0px;font-size:12px;line-height:normal;font-family:helvetica;color:rgb(69,69,69)">I
hacked together - as in I have hardcoded most of the
stuff - a simple version that is able to save a session
to disk and reconstruct it given the previous key. Turns
out it was all a lot easier than I thought, without
requiring hardcore object serialisation. States
(timestamp, sequence nonce and content) can be dropped
to disk as if they were going to be sent over the
network, and reconstructing the states to the initial
Terminal::Complete and Network::UserStream objects is
straightforward with the diff functions. </p>
<p
style="margin:0px;font-size:12px;line-height:normal;font-family:helvetica;color:rgb(69,69,69);min-height:14px"><br>
</p>
<p
style="margin:0px;font-size:12px;line-height:normal;font-family:helvetica;color:rgb(69,69,69)">There
is the question of how many states should be saved, from
reading the code I guess the answer is all of them, from
my test only the latest acked one was enough - but
again, crappy test.</p>
<p
style="margin:0px;font-size:12px;line-height:normal;font-family:helvetica;color:rgb(69,69,69);min-height:14px"><br>
</p>
<p
style="margin:0px;font-size:12px;line-height:normal;font-family:helvetica;color:rgb(69,69,69)">Another
obvious security concern as the states contain
information from the terminal in a completely readable
format. Could that be encrypted again with the key
before saving? In the case of iOS I can save the secure
key to the keychain. But I think that on top of that,
saving the session with a Passphrase might be a good
idea.</p>
<p
style="margin:0px;font-size:12px;line-height:normal;font-family:helvetica;color:rgb(69,69,69);min-height:14px"><br>
</p>
<p
style="margin:0px;font-size:12px;line-height:normal;font-family:helvetica;color:rgb(69,69,69)">I
understand that this might only be useful in Blink, but
any guidance would be appreciated. In the same manner,
if you change your opinion, I'm more than happy to walk
the extra mile and make it work for everyone.</p>
<p
style="margin:0px;font-size:12px;line-height:normal;font-family:helvetica;color:rgb(69,69,69)"><br>
</p>
<p
style="margin:0px;font-size:12px;line-height:normal;font-family:helvetica;color:rgb(69,69,69)">Thanks
a lot!!</p>
</div>
<br>
______________________________<wbr>_________________<br>
mosh-devel mailing list<br>
<a moz-do-not-send="true" href="mailto:mosh-devel@mit.edu">mosh-devel@mit.edu</a><br>
<a moz-do-not-send="true"
href="http://mailman.mit.edu/mailman/listinfo/mosh-devel"
rel="noreferrer" target="_blank">http://mailman.mit.edu/<wbr>mailman/listinfo/mosh-devel</a><br>
<br>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
mosh-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:mosh-devel@mit.edu">mosh-devel@mit.edu</a>
<a class="moz-txt-link-freetext" href="http://mailman.mit.edu/mailman/listinfo/mosh-devel">http://mailman.mit.edu/mailman/listinfo/mosh-devel</a>
</pre>
</blockquote>
<p><br>
</p>
</body>
</html>