John, thanks a lot for the detailed feedback. It has been very useful to continue :)
I'm definitely going to store all differences for states from the "throwaway number". I'm currently saving/restoring the string diffs of the states in order (so each state is a diff on the previous, and the first is a diff on an empty terminal, etc...). I thought serialising the Rows graph might be another way, but that turned out being a blackhole. Maybe related is that I do not follow you on why we might need to serialise with Messages though. My understanding is that Messages operate as a wrapper on Packets to send over the network, and it would be a lower level than we need to work with for this scenario. Is it due to some special compression / encryption? Were you thinking about a way to feed the system back with Messages and simplify object reconstruction? Thanks again! On Sat, Nov 12, 2016 at 12:55 PM, john hood <cg...@glup.org> wrote: > 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 > > start a session > lose connectivity to the server > type quite a lot or paste a large amount of text into the frozen session > switch away from the app and invoke the state-save code > > 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. > > 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. > > 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. > > 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. > > regards, > > --jh > > > On 11/9/16 8:03 PM, Keith Winstein wrote: > > Hello Carlos, > > 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. > > 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. > > -Keith > > On Wed, Nov 9, 2016 at 3:14 PM, Carlos Cabanero <carlosecaban...@gmail.com > > wrote: > >> I have started to work on “Persistent Connections” for Blink with great >> success! For background, these are the related GH issues ( >> https://github.com/mobile-shell/mosh/issues/394) and ( >> https://github.com/blinksh/blink/issues/59). >> >> >> 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. >> >> >> 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. >> >> >> 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. >> >> >> 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. >> >> >> Thanks a lot!! >> >> _______________________________________________ >> mosh-devel mailing list >> mosh-devel@mit.edu >> http://mailman.mit.edu/mailman/listinfo/mosh-devel >> >> > > > _______________________________________________ > mosh-devel mailing > listmosh-devel@mit.eduhttp://mailman.mit.edu/mailman/listinfo/mosh-devel > > >
_______________________________________________ mosh-devel mailing list mosh-devel@mit.edu http://mailman.mit.edu/mailman/listinfo/mosh-devel
