[OTR-dev] Persisting userstate object across app restarts.

Madhav V madhav at avaamo.com
Mon Aug 11 22:13:59 EDT 2014


So as to not sound I am trying to add OTR to a generic application, we
started off with the following constraints

- This is only a mobile app supported on iOS 7+ and Android 4.2.
- OTR messages are used in specific cases.  There is regular chat for
non-confidential discussions.
- The mobile app requires a passcode and full on-disk encryption enabled to
enable OTR chat.
- There are no web or desktop(PC/Mac) applications.

That said, got additional 2 questions

#1 I am sure above case(mobile only apps) must have been discussed in the
past; are there any proposals on how to handle the mobile only use-cases?.

#2.Unlike desktop operating systems both the iOS and Android(latest
versions) OSs provide a mature application data sandboxing/protection
comparable to RAM on desktops*. When you said RAM only/persistent state,
did you mean to include the latest mobile OSs as well?

* Please treat this as a developer perspective from reading the OS security
guides; not from a cryptography expert view.




On Mon, Aug 11, 2014 at 5:19 PM, Ian Goldberg <ian at cypherpunks.ca> wrote:

> On Mon, Aug 11, 2014 at 08:12:52PM -0400, Greg Troxel wrote:
> >
> > Madhav V <madhav at avaamo.com> writes:
> >
> > > 3. Alice goes into the app. Bob and Alice apps establish a secure
> session.
> > > The app persist the session on Alice' device.
> > > The session is persisted on Bob's device as well.
> > >
> > > 4. Now Bob can send Alice messages even when her phone is switched off
> or
> > > off the network or the app is in the background.
> > >
> > > 5. Alice's app can restore the session on restart or whenever
> necessary to
> > > decrypt Bob's message.
> >
> > I can see why you want to do this, but it more or less breaks the
> > Perfect Forward Secrecy property to write the encryption keys to other
> > than RAM.   So I would be concerned about this being labeled as OTR.
>
> I agree with Greg.  You're planning to store *session keys* in
> persistent state?  Please don't do that.
>
>    - Ian
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cypherpunks.ca/pipermail/otr-dev/attachments/20140811/4e9d7bb6/attachment.html>


More information about the OTR-dev mailing list