У твітары са мной не вельмі актыўна гэта абмяркоўваюць, таму я да вас

Я загнаўся думкай напісаць мэсэнджэр, які пра вас ніколі нічога нікому не распавядзе.

І ўжо маю пэўныя поспехі. Шмат што трэба распавесці, таму гэта будзе трэд.

Я буду вельмі рады адваротнай сувязі на гэтую тэму, бо, на жаль, веданне матэматыкі не дацягвае да глыбокага разумення крыптаграфіі, аднак калі прыняць за аксіому некаторыя рэчы, якія зробленыя да мяне, мне здаецца я магу даць рады з такой задачай.

Пачнём. Асноўная ідэя - не збіраць, не захоўваць, не паказваць, як мага больш інфармацыі, якая можа прывесці да разумення, які чалавек, каму пісаў, калі пісаў. Нават калі база даных уцячэ. Аніякіх глабальных нікнэймаў, аніякіх пароляў, рэгістрацыя з мінімум пытанняў (у ідэале толькі адна кнопка)

Каб нават сервер ніколі не ведаў цела паведамлення, яе сэнсоўную частку, яго задача, проста зрабіць тунэль камунікацыі паміж двума або больш людзьмі

І я ўжо маю некаторыя поспехі ў гэтым накірунку.

Па першае, крыху змененая імплементацыя адносна свежага RFC 9420 - The Messaging Layer Security (MLS) Protocol

ён вырашае праблему шыфравання паведамленняў, дзе ўдзельнікаў больш за два. Дазваляючы дзве рэчы

Не толькі паведамленні 1:1, але групавыя чаты, а таксама чаты, да якіх вы маеце доступ з любой вашай прылады

Па другое - аніякіх запытаў нумара тэлефона ці сканавання адраснай кнігі (гэтым нават сігнал грашыць), або емэілаў

Гэта канешне мае мінусы, кшталту, вы не можаце знайсці чалавека, які ўжо зарэгістраваны ў мэсэнджэры проста таму, што вы ведаеце яго нумар тэлефону.

Але тут нічога не паробіш, прынцыпы дыктуюць правілы

Аднак, знайсці адно адное прапануецца QR кадамі.

Напрыклад - вось невялічкае відэа, яно паказвае як адзін дэвайс далучаецца да другога ў адзін аккаўнт, але шэрынг кантактаў прынцыпова не адрозніваецца
Далей - спам акаўнты. З аднаго боку, калі няма мажлівасці знайсці рандомнага карыстальніка, то здавалвся б, прычым тут спам акаўнты. Аднак яны могуць ствараць нагрузку на сервер. Але ў нас няма нумараў тэлефонаў і емэілаў, але нам трэба абмежаваць рэгістрацыю для тых, хто гэтым карыстацца будзе не па накіраванню. Адказ просты - PoW. Пры першым падключэнні да сервера, трэба знайсці чысло, якое пры хэшаванні дасць канкрэтны вынік.

Шукаецца такое чысло пэўны час, правяраецца рашэнне імгненна, а калі нагрузка вялікая, або шмат рэгістрацый адбываецца з аднаго адраса, заўжды можна падняць складанасць гэтай задачы дынамічна

Вось прыклад.

А як схаваць факт, што акаўнт "юзер1" меў кантакт з акаўнтам "юзер2". Думаў над гэтым пэўны час і прыйшоў да выніку, што найлепшае выйсце наступнае.

Калі ты паказваеш куар код будучаму суразмоўцы, твая прылада генерыруе рандомны айдзі - топік, праз які ты будзеш чакаць паведамленне-запыт на дадаванне ў кантакты. Ты кажаш серверу - хачу атрымліваць паведамленні, якія пазначаны вось гэтым топікам.

Пра гэты факт сервер нічога не запісвае, проста трымае ў памяці, што ўсё пазначанае гэтым топікам трэба пераслаць па гэтаму канэкшану. То бок ёсць, вядома, факт перадачы на сервер, што юзер1 падпісаўся на топік А, а юзер 2 шле на топік А паведамленне, але першая палова не захоўваецца ўвогуле, а пра другую палову нідзе не пазначаецца, што паведамленне было прыслана юзерам 2
Пры гэтым, усе паведамленні, тэхнічныя і сістэмныя, або фактычныя паведамленні што вы напісалі свайму сябру заўжды зашыфраваныя такім чынам, што і сервер не можа іх прачытаць. Толькі людзі, якім гэтае паведамленне адрасавана. Гэтая частка апісана цалкам у загаданым вышэй RFC, а літаральна ўчора мая імплементацыя навучылася вызначаць агульны сакрэт групы, не перадаваючы гэты сакрэт яўна.

І вось цяпер у мяне пытанне да вас, спадарства. Я вар'ят ці мае сэнс працягваць?

Сарцы з'явяцца як толькі я давяду гэтую справу да чагосьці, чым можна карыстацца. На гэты момант я мяркую, што гэта мае сэнс рабіць сэлфхостэд рашэннем для закрытых груп, але ёсць кейсы, калі глабальны сэрвіс толькі б дапамог схаваць факт сувязі паміж двума людзьмі. Але баюся не даць рады (сродкамі або рэсурсамі) трымаць глабальны сэрвіс.

Такія пірагі :)

@GomZik я абывацель калі гаворка заходзіць пра прыватнасць і крыптаграфію і той яшчэ мамкін крыпташыз, але якая менавіта ў цябе мэта стварэння? гэта чыста акадэмічная цікавасць, ці ты хочаш стварыць нейкую працоўную альтэрнатыву існуючым сек’юным мэсэнджарам вырашаючы праблемы, якія яны маюць?

Я без усялякіх наездаў, калі што, ідэя мне падабаецца :)

p.s. мне гэта нечым нагадала Session

@hleb шчыра, усе існуючыя рашэнні мне ў тым ці іншым не падабаюцца, то яны нават бывае хаваюць факты, як менавіта ў іх што там зроблена (Гляджу ў бок thereema, ці як ён там), то не даюць сэлф хосэд рашэння (дароў sessions), то вось скануюць кнігу (вітанкі signal) і дарэчы не вельмі паспяхова хаваюць метадату. Бо я ацэньваю метадату таксама як тое, што можа быць выкарастана супраць цябе.

@hleb

Навошта я гэта раблю - тлумачэнне простае - я з Беларусі :) я хачу даць мажлівасць напісаць дурню сябру і не атрымаць угалоўку ў плечы.

@GomZik мне здаецца галоўная праблема прыватнасці найчасцей не ў тэхналогіях, а людзях. І таварыш маёр з паяльнікам у тваёй дупе ўсё яшчэ мацнейшы за самы складаны постквантавы алгарытм шыфравання🥲

Але наогул, мне было б цікава пачытаць пабольш пра архітэктуру твайго месэнджэра. Напрыклад, калі маецца на ўвазе наяўнасць сервера або групы сервераў, як ты плануеш забяспечваць утойванне ip адрасоў?

@hleb ды проста - не лагаваць іх нікуды :) ну або впны ды торы, калі трэба схаваць ад правайдэра. Серверу на самай справе не патрэбная гэтая інфармацыя каб працаваць, максімум - хэш адраса для фільтраў празмернай актыўнасці, але не сам адрас.Вядома,найбольшая праблема ў людзях,людзі складаныя істоты і сапраўды аніякая тэхналогія не дапаможа.Але,няхай сам уваход у сетку не патрабуе пароля,пароль можа быць на лакальную базу і пры ўводзе правільнага "няправільнага" паролю,база можа проста выдаляцца
@hleb Агулам ўсё гэта пакуль у зачатачным выглядзе і я літаральна нядаўна пераехаў з думак і прататыпу - хачу зрабіць падобна на матрыкс, але па іншаму, да вось гэтага РФЦ, павывучаўшы больш дасканала, мне падалося, што гэта лепей масштабуецца за тое, што ёсць у матрыкса і дае большую бяспеку, а таксама дазволіла мне прыбраць увогуле ўсю адкрытую метадату апроч топікаў, якія не шмат што кажуць на самай справе.
@GomZik гэта ўсё выглядае цікава, працягвай калі ласка дзяліцца прагрэсам

@hleb дзякуй за зваротную сувязь!

Буду прыходзіць з навінамі час ад часу 🫡

@hleb @GomZik вось згодны. Мне здаецца што самая вялікая праблема - не перахоп трафіка ці ўзлом севера, а карыстальніцкая прылада. Калі да яе будзе доступ, то ніякія пратаколы перадачы даных не дапамогуць.
@xzfantom @hleb ну, любую абарону ад дурня якую можна зрабіць праграмна я абавязкова зраблю, там ужо вядома мае паўнамоцтвы ўсё
@hleb ладна, магу прызнаць што SimpleX chat гучыць як мінімум падобна на тое, што я хачу атрымаць
@GomZik некаторы час таму таксама раздумваў на гэтую ж тэму, да рэалізацыі не дайшло пакуль. Кліентскую аплікацыю было бы добра маскіраваць пад калькулятар ці браўзэр, якія пры ўводзе нейкай сакрэктнай камбінацыі разблакіруюць функцыянал мэсэнджэра. Функцыя тэрміновага выдалення дадзеных з дэвайсаў - гэта абавязкова.
@mikola ну гэта відавочная рэчы, вядома) але праз тое што гэта не тычыцца самога мэсэджэнгу, то і прыярытэт і гэтых фічэй на апошнюю чэргу. Для пачатку праверыць працаздольнасць ідэі агулам
У мяне адразу адно пытанне. Чым гэта плануецца быць лепей ды адрозніваца ад, скажам, XMPP + OMEMO + Jingle/XEP-0166 ? Бо самаробная імплементацыя крыптаграфіі заўжды таіць сабе *БАГАТА* пастак, а яшчэ адзін новы пратакол/тып/кліент (?) месанджэру з ідэей сэлф-хостынгу федаратыўных сістэм, калі

@afox.me xmpp па змаўчанні мае метадату, якая расказвае, што ты кантактаваў з васей пупкіным у 19:13 учора, напрыклад

Адзінае што я не вельмі дасканала знаёмы з усімі экстэншамі, але калі вы скажаце мне адваротнае, то добра

А яшчэ, чаму тэлеграм лепей за пералічанае? Здавалася б нічым, але карыстаюцца ім нашмат больш за xmpp, хіба не?

Я намагаюся павязаць бяспеку са зручным экспірыенсам. Атрымаецца ці, час пакажа.

@afox.me так, і я разумею што крыптаграфія гэта складана. Таму і спасылаюся на RFC. Тым больш што згаданы RFC адносна нядаўні, наколькі хапае майго мозгу - ён прам геніальна просты (у сэнсе ядра, ідэі)

Таму для кліентскай рэалізацыі я выкарыстоўваю голэнг, дзе ўсе патрэбныя прымітывы крыптаграфіі ўжо ёсць у стандартнай бібліятэцы, што паніжае шанец на крытычную памылку

@afox.me
Ну а яшчэ, самае як на мяне прыгожае - Ты можаш аднесці дамп базы каму заўгодна, але акром колькасці паведамаленняў, што прайшло праз сістэму, адтуль нічога не атрымаць

@GomZik дарэчы, ёсць яшчэ такі не вельмі знакаміты праект https://code.briarproject.org/briar/briar
Я ім не карыстаўся, але выглядае цікава, як менш па апісанню. З мінусаў - здаецца, толькі пад Андроід.

Там увогуле няма цэнтральнага сервера і калі камунікацыя праз інтэрнэт (ёсць яшчэ магчымасць працаваць праз wifi і bluetooth), то сувязь ідзе праз тор.
Магчыма, можна ўзяць адтуль пару ідэй.

briar / briar · GitLab

Secure messaging, anywhere.

GitLab
@GomZik Канешне варта рабіць праект, калі важна тое, чаму навучышся па дарозе. Я таксама сваё раблю для эстэтычнага задавальнення і практыкі новых тэхналогій. Змагацца з тэлеграмамі наўрад атрымаецца – сеткавы эфект непераадольны. Я на Сігнал толькі найбліжэйшых сяброў угаварыў.
Можна натхнення пашукаць яшчэ ў Delta Chat. Яны таксама стараюцца зменшыць метададзеныя, а сэлф-хостэд серверы выкарыстоўваюць толькі як перадатчык паведамленняў са скразным шыфраваннем. UI - форкнуты сігнал.
@safonas а дэльта чат гэта хіба... Не зашыфраваны емэіл?
@GomZik там транспартны пратакол ад мэйла, так. Але дастаўка імгненная, dovecot дае рады лёгка. Адрасы паштовыя аўтаматычна генеруюцца толькі для маршрутызацыі, асноўная тоеснасць (user identity) – крыптаграфічная, захоўваецца на прыладзе. Такім чынам можна змяняць сервер без рэгістрацыі. Паведамленні пасля дастаўкі выдаляюцца Так што з пункту гледжання карыстальніка, гэта ўсё ж чат 🙂
@safonas не падобна што яны падтрымліваюць групавыя чаты. То ж гэта проста GPG паверх емеіла ў іншай абалонцы, хіба не?
@GomZik я найбольшы групавы чат бачыў на 130 чалавек, deltachat support называецца. Бот там выдаляе неактыўных удзельнікаў бадай з-за таго, што большы лік ўплывае-такі на сервер, г. зн. ёсць нейкія невырашаныя праблемы з пратаколам. GPG паверх эмэйла - згодны, наконт "проста" - не зусім 😁

@safonas ды проста :)

Мяркую таму што каб зрабіць выгляд групы, табе трэба даслаць Н паведамленняў на кожнае лагічнае паведамленне. Не скейліцца. MLS (які ў рфц), прапануе спосаб дамовіцца пра агульны сакрэт і як яго змяняць пры тых ці іншых умовах, таму яно для мяне выглядае больш масштабуемым і цікавым :)

@xzfantom так, я пра яго даўно ведаю, але гэта не зусім тое, як мне здаецца. Яно нават не блізка дае нейкі экспірыенс штодзённага мэсенджэра. Ды і быццам бы пераследуе іншыя мэты.

Я недзе ўжо казаў - p2p у гэта нават магчыма мінус у нашым выпадку, як бы я не любіў п2п тэхналогіі

@GomZik ну я не кажу, што брось дурное і карыстайся ім) але можна разглядзець, напрыклад, сервер як onion сервіс

@xzfantom ну ... Я проста мяркую што каб гэта было юзабельна, яно мусіць быць даступна з клірнэта

А адвансэд юзеры самі пюмогуць завярнуць усё ў оніон, гэта таксама варыянт

Маю на ўвазе каб сокет адкрыты быў менавіта ў оніон сетцы

@GomZik каб не трымаць глабальны сэрвіс, ты можаш дадаць федэрацыю, тады паведамленні будуць ісці не на топік, а на сервер:топік

але ў цэлым уражанне https://xkcd.com/927/ 😅

Standards

xkcd

@Anibyl ну як, ва ўсіх існуючых ёсць фатальны недахоп! Яны зробленыя не мною!)))

Я жартую) вядома, але ў горшым выпадку я атрымаю клёвы досвед, мінусаў не бачу :)

Ну каб да канца шчырым, 100% супадзення (па функцыях) я пакуль так і не знайшоў. Таму чаму б не мець яшчэ адзін варыянт :)

@GomZik @Anibyl ну ты ж разумееш што самае складанае ў мэсэнджэры гэта не зрабіць яго, а перацягнуць хоць каго-небудзь туды) у мяне да сіх ёсць знаёмыя ў вайберы, ды і ў скайпе былі да моманту як яго майкрасофт закрыў
@xzfantom @Anibyl ну так, але я на ім усё роўна нічога не зраблю, бо прыватнасць і манетызацыя перпендыкулярныя адно аднаму. У мяне дакладна ёсць пара зацікаўленых суполак :) я спадзяюся даць інструмент і пастараюся зрабіць яго дастаткова зручным, каб нават мая маці перайшла без праблем)
@GomZik вось тут крыху не зразумела - а калі сервер перазагрузіцца, то гэтыя даныя знікнуць? Ці пры перападключэнні кліент зноў павінен пераслаць свае падпіскі?
@xzfantom ну калі гэта топік для шэру кантакта ці лінка дэвайса (то бок мае аднаразовае выкарыстанне) ў адзін акк, то так, але калі гэта менавіта топік паведамленняў, то кліент самастойна перападключыцца на патрэбныя топікі