Because I don't have access to phones that may support this I will not try. The code will be open sourced so anyone may port it. But however I will now assume the app may not always be running on an encrypted filesystem so i'll add some support for keeping the files private Anonbox looks cool. It doesnt appear i can write emails? This isn't meant for emails, just simple PMs which you cannot attach image nor need to sign up for. Right now by design i cam PM someone w/o giving them a way to know who i am (although if you want a discussion you should attach your public key) The tech used will be openssl, mono (or .NET) and sqlite. I can drop openssl but i suspect people would prefer using openssl pem keys rather then mono/.NET generated keys. It sounds like you want to know how it works technically. Well, here are some notes i written for myself. It may not make sense or be a little incoherent but perhaps you can get an idea how secure it may be. --What data we have (in the client sqlite db)-- -If app is encrypted, all data unless with a * is encrypted with the symmetric key- db version*, path to pem file*, symmetric key (encrypted with said pem file or generated with PBKDF2 on the users password), misc options, server url, server public key private keys, plain names, ids*, last ident public keys, plain names, ids* association table: association value*, private key id* inbox: private key id*, inmsg/timestamp/optional from public key id outbox: public key id*, outmsg/timestamp/optional reply to public key id draft: same fields as outbox last ident is when the user last identify himself to the server. If user marks server as untrusted this will prevent user from grabbing all his msgs from the server using different keys. This is so the server is less likely to associate a group of keys to one user --- communication to server Handshake with server: Client encrypts random data with server public key, server sends it back plaintext Register public key. Client gives user pub key, server reply's with an encrypted block of random data, client decrypt it using private key then sends it back plaintext Unregister: delete all msgs and public key from user. Of course server sends random data which will need to be sent back as plaintext to verify the key is mine. Send Message: Client send data which is encrypted with AES which key is encrypted with the recipient pub key. The data is msg+optional my reply to/identity pub key) + recipient pub key. This data is compressing with DEFLATE. Server replies with success or error message. It makes sure recipient and your pub key is registered. Also replies with test to ensure the reply-to pub key is yours. Get Messages: Send pubic key i'd like to get messages for. Server sends me random data to send back in plaintext. Then receive all my data (compressed with DEFLATE) Messages is msg + timestamp(UTC server date) + if available the reply to public key. The client app will decrypt the messages and store it either compressed or compressed/encrypted with the db AES key. Timestamp and reply-to pub key are encrypted. Messages are deleted from servers after 10days of retrieval (or immediately). If pub key has not been seen > 1 year he is unregister and all messages are deleted

Date: Thu, 12 Jul 2012 17:12:01 +0000 From: krugar <tor-admin@krugar.de> To: tor-dev@lists.torproject.org Subject: Re: [tor-dev] Encrypted PM site/hidden service Message-ID: <4FFF0561.40906@krugar.de> Content-Type: text/plain; charset=ISO-8859-1

take a look at https://anonbox.net/ for a similar service.

a few considerations: if you create an "app" that lives on a mobile phone, are private keys stored on the phone? are they secured somehow while the app is running / not running? which public keys will be stored on the phone? will messages be stored on the phone? will someone always know who sent a PM, or only if the sender so chooses? how do you know how to reach someone on your service? are there pseudonyms? how long to they last? what about key revocation? what happens if the server is compromised somehow, will attackers be able to look at the data and see who wrote messages to whom? for which time period?

try to clearly define which privacy guarantees you try to achieve against which type of attacker. the more precise you write this down, the easier someone can help you spot weaknesses in your concept, and the better for you and your users once the system is live. http://dud.inf.tu-dresden.de/Anon_Terminology.shtml may help if you are uncertain about wording.

cheers -k

-- http://www.fastmail.fm - Faster than the air-speed velocity of an unladen european swallow