Blog‎ > ‎

Off The Record & Facebook Confidentially services closed

posted Jun 23, 2013, 10:13 AM by Sami Lehtinen   [ updated Jun 23, 2013, 10:18 PM ]
Unfortunately I really don't have enough time to maintain the service which I used to study how Google App Engine works. As well as we all know, that it's not very after all secure, because data is stored by Google and there are well known SSL/TLS security issues. Now the service is officially closed, here's copy of Finnish and English service FAQ what it was all about.

Off The Record Messaging

FAQ / Technical information


Q: Off-The-Record (OTR) - What is this?

A: This service is meant for delivering messages to recipient
   off-the-record (OTR). It means that message content isn't
   being archived by recipient systems. Message is delivered using
   safe methods. Message content is erased immediately upon
   reading.
        
Q: How to use Off-The-Record (OTR)?

A: Follow these steps:
   1. Write message in form on front page.
   2. If you want to change storage period change it.
      Message is automatically deleted after this period expires
      even if it's not being read by recipient.
   3. If you want to add additional password, it will be hashed with
      random message key to encrypt the message.
   4. Click Send to send message and get "Read URL"
   5. Deliver "read URL" to recipient using what ever method you
      wish to use. (If you log in with Google account OTR can send
      message behalf of you.) Don't click on that URL, if you read
      the message, the message is also automatically destroyed as
      described earlier.
   6. When recipient gets that URL, they'll click on it and after
      giving the (optional) password, recipient sees your message only
      once and over secure encrypted connection.
   7. Message has been destroyed.

Q: Ok? Why would I take all these complex steps? Why I couldn't
   sent that message directly using email, IM, Facebook or any
   other service?
  
A: No. It's not same thing. OTR uses always encrypted connection,
   many service unfortunately do not, even if it would be highly
   recommended.
  
   Yet another reason is archiving. This service erases message
   immediately when it's read. But many other services archive
   message data for undefined period. As example, how do you delete
   email that you sent to your friends gmail account two years ago?
  
   With this service, if message isn't archived immediately by
   recipient when it's read it can't be read ever again. Especially
   if using company email or so, it might be nice to be sure that
   unofficial messages are gone, when they're gone. Nobody can
   restore erased messages.

Q: I'm tech geek, I want to know how it's done.

A: Yep. I'm tech geek too. So let's share the facts.

   Connections:
   All connections are secured using HTTPS.
   It's just as secure as online banking is.
  
   Message storage and retrieval:
   When new message is stored we'll generate following data.
  
   MessageId is one 64 bits long. That identifies message in DB.
   MessageKey is 256 bits long. It's used with AES-256/OFB to
   encrypt message.
   MessageKey is then hashed using SHA-256 with optional
   MessagePassword to form new MessageKey.
   MessageChk is 256 bits long. It's SHA-256 of
   MessageId+Message+MessageKey and it's actually
   the first 256 bits of message being encrypted.
  
   When message is being read, it's located in DB using MessageId.
   After that it's decrypted using MessageKey. And after decryption
   it's checked if MessageChk is valid. If not, error message is
   shown and message is not deleted. Technically allows timing
   attack which proves that MessageID exists, but speed would be
   really unfeasible!
  
   Only MessageId, MessageExp (time-stamp) and EncryptedData is
   stored in DB. So without information given out only on that send
   message result page, it's impossible to read anything (useful)
   from database.
     
   This means that all 320 bits of information which is base64
   encoded in URL, need to be correct before message can be read.
   I would call it extreme overkill safe. It's very much more secure
   than any security achieved using passwords.
  
   Biggest security issue is "Read URL" delivery method. But usually
   that's not big deal. Because recipient would be alarmed because
   valid URL isn't working any more. And they'll know that message
   has been intercepted. Usually most of information leak happens
   so that end-users aren't aware of that. Now it's possible to
   get message without exposing "Read URL" to HTTP server logging.
   Simply visit front page and enter that URL (or id+key) to get
   message box and get it.
  
   Using additional MessagePassword is recommended, in that case
   the Read URL isn't enough, correct additional password needs to
   be provided, which is not stored anywhere. This part could also
   be done using JavaScript quite easily.
  
   When message is erased it's always first overwritten with random
   data, and then it's actually deleted.

Q: Can I trust this service.

A: Of course you can't and you shouldn't. I don't trust many other
   similar services either. That's just why I wrote this application.
   But I can trust this one.

   I personally hate all kind of excessive generic archiving and
   prefer log free, non-archiving option instead.

Q: Does Google have privacy policy?

A: Of course they do, check it out.

Send messages from Off-The-Record.appspot.com

Change log:
Version 9 - 16.02.2013 (DD.MM.CCYY)
 - Removed FB-Confidentially references from UKK & FAQ
 - Announced service getting closed soon.
 
Version 8 - 09.09.2012 (DD.MM.CCYY)
 - Removed link to FB-Confidentially, I closed down the project
 - Removed refernces to Google Anaytics to enhance privacy

Version 7 - 05.02.2011 (DD.MM.CCYY)
 - Lot of junk removed from application paths
 - Improved application / GAE platform  exception handling.

Version 6 - 08.05.2010 (DD.MM.CCYY)

 - All remains of DES/3DES encryption/decryption removed from source.

 - Added more secure get message field to front page.
   This field uses post method instead of get, so HTTP server logs wont
   contain message get/decryption key. It could have been cosidered
   a security issue, even if message was immediately overwritten.
   It would have been possible for Google staff to use database backup
   with old data and http logs containing fetch key.
 
 - Logging absolute minimum, error messages only. Message IDs not
   being used anymore in logging / trouble shooting. Now there is no
   easy way to find out even from logs, who left which message and
   who fetched it.

(C) Sami Lehtinen 2011

Powered by Google App Engine
KW: message, messages, messaging, private, expire, expiring, encryption, encrypted, encrypt, secured, trusted, trust, platform, secure, self destructing, destruct, email, unofficial, OTRM, OTR, secured, hush-hush, free, web, service, www, based, browser, internet, aes, 256, aes256, des, 3des, twofish, vanish, records, expire, no record, ssl, tls, send, receive, get
Off The Record home

-- Finnish --

Epävirallinen ja luottamuksellinen viestintä / sähköposti

UKK / Tekniikka


K: Off-The-Record (OTR) - Mitä ja miksi?

V: Tämän palvelun tarkoituksena on sallia viestien turvallinen
   ja luottamuksellinen toimittaminen vastanottajalle. Sekä
   huolehtia siitä, että viesti tuhotaan välittömästi sen
   toimittamisen jälkeen ilman, että se jää arkistoihin roikkumaan
   ennalta  määräämättömäksi ajaksi.

K: Kuinka käytän OTR palvelua?

V: Toimi seuraavasti:
   1. Kirjoita viesti etusivun lomakkeelle.
   2. Jos haluat muuttaa säilytysaikaa oletusarvosta, tee se.
      Kun säilytysaika päättyy, viesti tuhotaan vaikka sitä ei ole
      luettu.
   3. Aseta viestille lisäsalasana joka tarvitaan viestin lukuavaimen
      lisäksi.
   4. Paina "Send"-näppäintä
   5. Toimita "Read URL" vastaanottajalle. Mitä tapaa sitten ikinä
      haluatkin käyttää. (Jos kirjaudut Google tunnuksilla palveluun,
      voimme lähettää viestin puolestasi. Viestin kieli on englanti.)
      Älä klikkaa "Read URL" osoitetta. Jos avaat lukusivun,
      näytetään viesti sinulle ja se tuhotaan välittömästi.
   6. Kun vastanottaja saa lähettämäsi linkin, hän voi avata linkin
      ja antaa mahdollisen lisäsalasan. Tämän jälkeen käyttäjä 
      näkee viestin vain yhden kerran salatun yhteyden yli.
   7. Viesti on tuhottu.
           
K: Miksi haluaisin tehdä sen näin hankalasti? Enkä voi lähettää
   viestiä suoraan vastaanottajalle? Esimerkiksi sähköpostilla,
   Messangerilla, Facebookilla tai muulla tavalla?
     
V: Kyllä ja ei.

   1. Sähköposti käyttää salaamattomia yhteyksiä.
  
   2. Kun  lähetät viestin esimerkiksi sähköpostilla, et
   voi vaikuttaa siihen, että viestiä ei arkistoitaisi ennalta
   määrittelemättömäksi ajaksi tai ikuisesti.

   Kun käytät tätä palvelua, voit olla varma, että viesti voidaan
   lukea vain kerran. Viesti tuhotaan pysyvästi lukemisen yhteydessä
   tai viimeistään heti määritellyn säilytysajan päättyessä. Viestiä
   on tämän jälkeen täysin mahdotonta palauttaa.
  
K: Olen propellihattu, haluan tietää, miten homma toimii.

A: Kiitos kysymästä, kerron mielelläni.

   Yhteydet:
   Kaikki yhteydet tähän palvleuun käyttävät salattua HTTPS yhteyttä.
   Yhteydet ovat siis aivan yhtä luotettavia kuin verkkopankkien
   yhteydet, joita olet varmasti tottunut käyttämään.
        
   Viestien tallentaminen ja noutaminen:
   Viestiä tallenetteaessa luomme seuraavat tiedot.
  
   Tunniste, joka on 64 bittiä pitkä. Se kertoo, mistä viestistä on
   kyse. Salausavain, joka on 256 bittiä pitkä. Sitä käytetään
   AES-256/OFB lohkosalaimen kanssa viestien salaamiseen.  
   Viestitarkiste, joka on 256 bittiä pitkä. Sitä käytetään viestin
   noudon yhteydessä tarkistamaan, että annettu salausavain oli
   oikea.
  
   Viesti noudetaan luettaessa kannasta tunnisteella. Sen jälkeen
   salaus puretaan, perustuen lukulinkkiin ja viestin salasanaan.
   Puretusta tiedosta luotua tarkistetta verrataan
   viestitarkisteeseen. Jos tarkiste täsmää, viesti näytetään ja
   tuhotaan. Jos tarkiste ei täsmää, näytetään sanoma, joka kertoo,
   että viestiä ei lyödy.

   Vain tunniste, viestin voimassaolo ja salattu viesti tallennetaan
   tietokantaan. Ilman "Read URL" osoitteessa olevaa avaintietoa ja
   viestin mahdollista salasanaa, viestin lukeminen on käytännössä
   mahdotonta.
  
   Jotta viesti voidaan lukea, tarvitaan 320 bittinen tunniste, joka
   on base64 koodattuna "Read URL" osoitteessa ja viestin salasana.
   Jos yksikin bitti on väärin, viestin lukeminen ei onnistu.
  
   Jos haluat laskea eri avainvaihtoehdot, kaava on 2 potenssiin 320.
   Tulos on 2,13+E96. Luvussa on siis 97 numeroa. Onnea arvaamiseen.
   Tämä on huomattavasti turvallisempaa kuin mikään salasanoilla
   saavutettava turvallisuus.
  
   Suurin turvallisuus kysymys on tapa, jolla toimitat lukemiseen
   tarvittavan "Read URL" osoitteen.
  
   Kuitenkin, jos joku ulkopuolinen lukee viestin, vastaanottaja tulee
   tietoiseksi asiasta viimeistään yrittäessään lukea viestiä, koska
   viesti on jo tuhottu. Viestit voidaan edelleen lukea vain ja
   ainoastaan yhden kerran. Huom! Nyt tähän on tullut parannus.
   Viestin voi noutaa menemällä etusivulle ja antamalla tuon nouto
   urlin "Get Message" laatikkoon. Silloin nouto URL ei kirjaudu
   laikaan HTTP palvelimen logeihin.
   Kun vielä käytät viestikohtaista salausavainta josta olet sopinut
   vastaanottajan kanssa, ei edes kokonaisen linkin vuotaminen aiheuta
   ongelmaa, koska linkistä puuttuu salasanan vaikutus ReadURLissa
   Olevaan MessageKey salausavaimeen.
     
   Pahimmat tietovuodot tapahtuvat yleensä niin, että kumpikaan
   osapuoli ei ole tietoinen vuodon olemassaolosta.
          
K: Voinko luottaa tähän palveluun?

V: Et tietenkään. Minkään en luota useimpiin tämän kaltaisiin
   palveluihin. Juuri siksi loin tämän palvelun, johon Minä voin
   luottaa.
  
   En henkilökohtaisesti pidä palveluista, jotka arkistoivat suuria
   määriä tietoa aivan tarpeettomasti. Ilman, että tiedon tuhoamisesta
   voi varmistua mitenkään. Siksi suosin tämän kaltaista palvelua,
   joka huolehtii viestien tuhoamisesta ajallaan.
  
K: Onko Googlella tietosuojakäytäntöä?

V: On niillä, katso täältä.
  
Lähetä luottamuksellisia viestejä osoitteesta: Off-The-Record.appspot.com

Mutokset:

Versio 9 - 16.02.2013 (PP.KK.VVVV)
 - Poistin viitteet FAQsta ja UKKsta FB-Confidentially projektiin
 - Ilmoitin että palvelu tullaan sulkemaan piakkoin muiden projektien
   vuoksi.
   
Versio 8 - 09.09.2012 (PP.KK.VVVV)
 - Removed link to FB-Confidentially, I closed down the project
 - Removed refernces to Google Anaytics to enhance privacy

Versio 7 - 05.02.2011 (PP.KK.VVVV)
  - Poistettu paljon turhaa dataa sovelluksen hakemistoista.
  - Sovelluksen virhekäsittelyä parannettu merkittävästi.

Versio 6 - 08.05.2010 (PP.KK.VVVV)

 - Poistettu DES/3DES salauksen jämät koodista.

 - Lisätty turvallisempi nouda viesti (get message) kenttä etusivulle.
   Tämän kentän kautta voi noutaa viestejä laittamatta viestin tunnis-
   tetta / salausavainta URL osoitteeseen. Koska lomake käyttää POST-
   menetelmää, GETin sijaan. Ei osoite tallennu HTTP palvelimen logeihin.
   Aikaisemmin koska osoite tallentui logeihin, olisi Googlen ollut
   mahdollista palauttaa tietokannan varmuuskopio ja purkaa siinä olevat
   noudetut viestit logissa olevien tunnisteiden/salausavainten
   perusteella.
  
 - Logeihin kirjoitetaan mahdolisimman vähän tietoa. Lähinnä virheet
   kirjataan ongelmien korjaamisen vuoksi. Viestin tunniste-osaa
   ei enää logata koskaan. Salausavainta ei tietenkään logattu koskaan
   ennenkään. Nyt kun viestitunnisteita ei tallenneta, ei ole helppoa
   tapaa yhdistää viestin jättäjää ja sen noutajaa toisiinsa.

(C) Sami Lehtinen 2011

Powered by Google App Engine
KW: message, messages, messaging, private, expire, expiring, encryption, encrypted, encrypt, secured, trusted, trust, platform, secure, self destructing, destruct, email, unofficial, OTRM, OTR, secured, hush-hush, free, web, service, www, based, browser, internet, aes, 256, aes256, des, 3des, twofish, vanish, records, expire, no record, ssl, tls, send, receive, get
Off The Record home

Facebook Confidentially (FB-Confidentially)


Confidentially application is designed to allow confidential private messaging in Facebook. All connections use strong encryption (SSL/TLS) and data is stored in encrypted database. Messages are destroyed irreversibly when read. No logging, data on rest is strongly encrypted. If nessages are not read, they expire after 30 days. It's not possible to recover expired messages.

Each individual message uses full strength 256 bit AES encryption with random individual keys. We respect absolute user privacy.

- Thank you

Exception: If local law enforcement with confirmed authority is investigating case and court orders information to be released. Then we're forced to release what ever information we have. But as said earlier, what's gone, is gone. We can't help it. It might be possible that Google is able to restore some data from their database backups. But the encryption key is still missing, we can't provide that.

FAQ

    Messages are encrypted using full strength 256 bit key and AES-256 algorithm.
    Each message uses totally separate random own encryption key!
    Messages can have additional password, which is defined by sender, it's hashed as part of encryption key.
    Recipient Facebook UserID is also hashed as part of encryption key. So if UserID isn't correct, even if password and key would be correct messages can't be read.
    If there are multiple recipients, each recipients message is encrypted individually with separate keys.
    Messages can't be read without Facebooks application request data, which includes the encryption key from Facebook and signed request with recipient user_id in it.
    As mentioned earlier additional password / key might be required if sender has configured one.
    Messages can be read only once, after that message is overwritten and deleted.
    Messages expire after 30 days, even if unread.
    Much safer option than email! Email is stored at servers and transferred between servers without encryption.
    When you're using Confidentially both storage and transport use high-grade encryption.
    No there is no way to recover expired or read messages.
    There is similar kind of application for non-Facebook users called Off-The-Record.

Terms of Service

    Don't flood
    Don't abuse
    Don't use for any illegal purposes
    If you think what you're doing is wrong, then don't do it
    As mentioned in privacy part, we'll do our best to keep your data private. But we can't simply can't absolutely guarantee it.

Privacy policy

    Any user/message information isn't given out, without written request from local authoritative court order. It's useless to point data requests to me, point those directly to Google, because they have access to (encrypted) data (from backups), which I don't have after messages are deleted.
    All requests will be reverse checked to confirm recipient authority. All messages data is deleted (overwritten) after 30 days or when read by recipient.
    In case of court order, it's only possible to give out (encrypted) unread messages. Read messages are history, can't do anything about it.
    We'll do our best to keep your data private. But we can't simply can't absolutely guarantee it.
    We can't be held responsible for any data loss or leaks. Service comes with no warranty what so ever.
    Our policy prefers data loss over data leak. So it's better to lose all confidential data than let it out in case of unclear situation.
    Site is hosted by Google's App Engine.
    Read Google's own privacy policy.