Off The Record & Facebook Confidentially services closed

Post date: Jun 23, 2013 5:13:02 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.

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.

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.

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.

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.