TiTs isn’t Tits, sorry 

Telegram implementation

Tit is a kind of bird!

official name: ω IM

prototype

https://github.com/lug-tw/TiTs

http://gitlab.gg-in.in/ronmi/TiTs

UI

Satisfy Taiwanese user habits

architecture

Client + server cloud, the could architecture should be flexible and scalable.

• server cloud

A server should connect with at least 3 servers in the cloud.

When a server wants to join the cloud, the topology of the cloud should be bridgeless.

Each server will remember available server list (topology of the network).

A connection between two servers should be a directed-or-forwarded.

Shortest path routing is recommended but optional for servers.

We should display the active user-proxy list on dbs’ website

XXX: routing algorithms: ronmi’s job

Take GPG fingerprint as identity of a user.

messages

•              |    plaintext    |   encrypted
• -------------+-----------------+-----------------------
• 1-to-1       | normal chatting | secure chatting
• -------------+-----------------+-----------------------
• group group  | chatting secure | secure group chatting
• -------------+-----------------+-----------------------

Text messages should be signed and encrypted in client with public key algorithm (GnuPG) and a session key, respectively.

All media (including pictures, stickers or any kind of files) will **not** be encrypted (in any cases).

Media are recommended but optional to be signed by sender’s private key.

chatting

Group id: nothing to do with servers, it’s just a identity for clients.

• group chatting
• normal chatting (1 to 1, only 2 members in the group)

Do not provide any guarantee about security.

Speed is No. 1.

secure chatting

All secure chatting are encrypted by a session key.

Key-exchanging is done by GPG (using GPG to protect the session key).

All data (including text messages and media) are signed by sender’s private key before transmission.

The session is generated by the inviter’s client, in group chatting case, more key-exchanging to multiple members in the chatting room.

C-C header and payload are encrypted by shared session key.

The session key should be revoked in a time period.

Security is No. 1.

 the protocol

• RFT #02
• Client to server header
  • length of the list   (special case: 1-to-1 = sender + receiver = 2)
  • list of fingerprints
  • message type: plaintext or encrypted
• Client to client header (encrypted by the session key)
  • timestamp
  • serial number
  • checksum
  • message type (MIME: text/plain or not)
  • life time (how long does a message show on the client UI)
  • group ID (0 for 1-to-1 chatting)
• Payload (encrypted by session key)
  • (text) message body or attachment

login

client use his private key and server’s public key to encrypt "e2014b07b02c3359a370343edc03b0808b129892"

server use client’s public key and it’s private key to decrypt that -> "I love big tits"

    Client sends: my_private_key( server_public_key( MAGIC_WORD ) )

    Server decodes: client_public_key( my_private_key( PACKET_DATA ) )

• Replay attack: 偷聽者 Eve 把 client Alice 傳出的前幾個加密封包錄下來，下次再重播，server 依然會讓 Eve 以 Alice 的身份 login。使用這個方法 Eve 不需要具備解密能力。
• Maybe, but you still need client’s private key to decrypt the session key
• Fake login itself can be a problem. Make clients to encrypt a server-generated random number instead of fixed string can avoid this problem by proving it’s "liveness". And to my understanding, insecure chatting does not need a session key.
• 另外所有的 Client 都無法判斷這個 server 是真的 server，還是把 server 用 DOS attack 打死之後冒用 IP 的假 server。
• we can verify the server by his public key
• Yeah this can solve the problem, but I think the "server public key" part is just missing in this text. And the server still has to prove it’s "liveness" to the client, because fake server can also use the replay attack, send the same initial random number and same session key every time to pass the login protocol.
• good point. Maybe we should do both encrypting and signing when logging in.

 To fix

multiple device

Key Server

We should build our own key server in order not to impact original PGP network. Existing public key server might be queried as a fallback, but PROXIES AND CLIENTS MUST NOT UPLOAD ANY KEY TO PUBLIC KEY SERVER.

•  There would be a lot of "careless" user who does not know "signing other’s key" means. Such keys might destroy whole trust-network. We should do something to prevent this.

TODO & wish list

stickers

theme

slash command

tag people (@)

beware of fake-clients/implementation