← Sesame/
Sesame · Bölüm 03 cryptography / sesame

3. Sesame

Sesame algorithm, her device’ın sakladığı state’i ve encrypted messages göndermek ve almak için bu state’i kullanan algorithms’ı tanımlar.

3.1. Device state

Her device, correspondents’leri için UserID ile index’lenmiş bir UserRecord seti saklar.

Her UserRecord, DeviceID ile index’lenmiş bir DeviceRecord seti içerir.

Her DeviceRecord, bir active session ve/veya sıralı bir inactive sessions listesi içerebilir.

Her device, kendi UserID’si için bir UserRecord saklar, ancak kendi DeviceID’si için bir DeviceRecord saklamaz. Bu UserRecord, device’ın gönderdiği her outbound message’ın bir kopyasını user’ın diğer device’larına göndermesini sağlar.

Bir UserRecord veya DeviceRecord, stale olarak işaretlenebilir; bu, record’un silinmiş bir user veya device’a karşılık geldiği, ancak gecikmiş messages’ları decrypt etmek için tutulduğu anlamına gelir.

Stale bir record, sending device tarafından herhangi bir zamanda silinebilir (stale olarak işaretlendiği anda bile). Gecikmiş messages’ları ele almak için önerilen deletion policy, stale record’un ilk kez stale olarak işaretlendiği zamanı kaydeden bir timestamp içermesidir. Timestamp MAXLATENCY’den daha eski hale geldiğinde, stale record, device mailbox’ındaki tüm messages’ı bir sonraki fetch edip process etmesinden sonra güvenli biçimde silinebilir (message loss korkusu olmadan).

Her device, cryptographic authentication için bir identity key pair (bir public key ve private key) saklar. Bir device her zaman aynı DeviceID ve identity key pair’e sahip olacaktır (bunları değiştirmek için söz konusu physical device önce logical olarak silinmeli, sonra yeni değerlerle eklenmelidir).

Sesame, key pairs için iki farklı model destekler: per-user identity keys ile bir user altındaki tüm device’lar aynı key pair’i paylaşır. Per-device identity keys ile her device farklı bir key pair’e sahip olabilir.

Per-user identity keys ile, diğer device’ların identity public keys’leri UserRecords içinde saklanır. Per-device identity keys ile, diğer device’ların identity public keys’leri DeviceRecords içinde saklanır.

3.2. Device state’i güncelleme

Devices local state’lerini birkaç şekilde değiştirebilir:

Devices, UserRecords’ları, DeviceRecords’ları ve sessions’ları delete edebilir. Eğer bir DeviceRecord içindeki son session silinirse, DeviceRecord silinir. Eğer bir UserRecord içindeki son DeviceRecord silinirse, UserRecord silinir.

Devices, bir DeviceRecord içine yeni sessions insert edebilir. Insert edilen bir session her zaman DeviceRecord’un active session’ı olur ve daha önceki active session (varsa) DeviceRecord’un inactive sessions list’inin başına taşınır. Inactive sessions list’i fazla büyürse, sessions son kısımdan silinebilir.

Devices, bir DeviceRecord içindeki inactive bir session’ı activate edebilir; bu, inactive session’ı DeviceRecord’un active session’ına taşır ve daha önceki active session’ı (varsa) DeviceRecord’un inactive sessions list’inin başına taşır.

Devices, UserRecords veya DeviceRecords’ları stale olarak mark edebilir.

Devices, kayıtlarını bir (UserID, DeviceID, public key) tuple’ına göre conditionally update edebilir:

Devices, bir (UserID, DeviceID, public key) tuple’ına göre encrypt etmeye hazırlanabilir:

3.3. Messages gönderme

Sesame sending process’in girişi bir plaintext ve bir recipient UserIDs kümesidir. Recipient set, device’ın kendi UserID’sini içerir.

Plaintext, sending device tarafından aşağıdaki süreç kullanılarak her recipient UserID için encrypt edilip gönderilir:

  1. Eğer recipient UserID için ilgili ve non-stale bir UserRecord varsa, o UserRecord içindeki active session içeren her non-stale DeviceRecord için sending device plaintext’i o active session kullanarak encrypt eder.

  2. Recipient UserID, encrypted messages listesi ve her message için ilgili recipient mailbox’ı gösteren karşılık gelen bir DeviceIDs listesiyle birlikte server’a gönderilir. Eğer ilgili active session yoksa bu listeler boş olur.

  3. Eğer recipient UserID şu anda in-use durumdaysa ve sender’ın DeviceIDs listesi recipient UserID için current ise, server messages’ı kabul eder ve messages ilgili mailboxes’a gönderilir. Bu süreç sonra recipient UserID için sona erer ve sonraki recipient UserID için step 1’e dönülür.

  4. Aksi halde server messages’ı reddeder ve ya recipient UserID yoksa sending device’a bunu bildirir; ya da sending device’ın records’unu current hale getirmek için gereken eski DeviceIDs ve yeni DeviceIDs’leri ve yeni DeviceIDs’lere karşılık gelen identity public keys’leri bildirir.

  5. Eğer server, recipient UserID’nin mevcut olmadığını belirtirse, sending device ilgili UserRecord’u (varsa) stale olarak mark eder. Sending device sonra bu süreçten recipient UserID için çıkar ve sonraki recipient UserID için step 1’e döner.

  6. Her eski DeviceID için, sending device ilgili DeviceRecord’u stale olarak mark eder.

  7. Her yeni DeviceID için, sending device (UserID, DeviceID, ilgili public key) tuple’ına encrypt etmeye hazırlanır.

  8. Bu süreç, mevcut recipient UserID için step 1’den yeniden başlatılır.

Belirli bir user’a encrypt ederken herhangi bir error oluşursa (örneğin invalid bir server response veya session creation sırasında bir failure), sending device ilgili UserRecord üzerindeki herhangi bir change’i discard edecektir. Bu, records’un inconsistent durumda kalmasını önler. Sending device, diğer users’a encrypt etmeye ve göndermeye devam etmeyi seçebilir ya da tüm sending process’i sonlandırabilir.

Kötü niyetli veya hatalı bir server durumunda aşırı looping’i önlemek için, devices bir recipient user için message sending loop’unu kaç kez tekrar etmeye istekli olduklarına dair bir limit koymalıdır.

3.4. Messages alma

Sesame receiving process’in girişi bir encrypted message ve server’dan fetch edilmiş olan sender’ın UserID ve DeviceID’sidir.

Message’ın nasıl fetch edildiği bu document’in kapsamı dışındadır. Devices server’ı periyodik olarak poll edebilir veya yeni messages fetch edilebilir olduğunda bir notification alabilir.

Encrypted message, recipient device tarafından aşağıdaki süreçle decrypt edilir:

  1. Eğer encrypted message bir initiation message ise ve recipient device message’ı decrypt edebilen ilgili bir session içeren bir DeviceRecord’a sahip değilse, aşağıdaki adımlar uygulanır:

    • İlgili public key message header’ından çıkarılır.
    • Device, kayıtlarını (sender’ın UserID’si, sender’ın DeviceID’si, ilgili public key) tuple’ına göre conditionally update eder.
    • Device, initiating message kullanarak yeni bir session oluşturur ve yeni session’ı ilgili DeviceRecord içine insert eder.
  2. Eğer ilgili DeviceRecord içindeki hiçbir session encrypted message’ı decrypt edemiyorsa, encrypted message discard edilir, device state’ine yapılan tüm değişiklikler discard edilir ve bu process sona erer.

  3. Aksi halde message, ilgili session ile decrypt edilir.

  4. Eğer ilgili session active değilse, active hale getirilir.

Message’ı parse ederken veya process ederken herhangi bir error oluşursa, session creation ya da message decrypt etmedeki cryptographic errors dahil, device tüm state değişikliklerini discard eder, encrypted message’ı discard eder ve decryption process’ini sonlandırır.