Epha-ots: одноразовые секреты с нулевым доверием к серверу

Ну несколько дней назад я узнал, что OneTimeSecret не Secret. У меня пригорело.

наноутбуке

хм.

Джва ночи было уже, понимаешь?

а че там не секрет , ссылочку на пруф или эксплоит можна ?)

модифицированная qrdode.js

qrdode: qr code для додиков

Это аналог https://github.com/Luzifer/ots ?

Ну несколько дней назад я узнал, что OneTimeSecret не Secret.

Что имеется в виду? Есть подробности?

Строго говоря, любой секрет — не секрет, если есть достаточно времени на вскрытие шифра.

А если по теме, то в чем там проблема?

Идеологически похоже, надо протоколы сравнивать. Epha-ots заточена на то, что сообщение генерит твой броузер и шлет на сервер, а сервер только перепихивает его по ID тому, кто попросил. Дистрибуция ключей (паролей) как-то за рамками изложения осталась. Ну, типа, мы с тобой договорились по независимому кканалу о пароле и можем теперь друг другу сообщния слать, которые на сервере живут ограниченное время.

Судя по тому, что клиент — броузер, имеем типичное нинужно и, даже, опасно.

Epha-ots заточена на то, что сообщение генерит твой броузер и шлет на сервер, а сервер только перепихивает его по ID тому, кто попросил.

Как и https://github.com/Luzifer/ots

Дистрибуция ключей (паролей) как-то за рамками изложения осталась.

Аналогично.

Судя по тому, что клиент — броузер, имеем типичное нинужно и, даже, опасно.

А какой ещё клиент ты ожидаешь для сервера, работающего по http(s)?

Да, тащемта, много кто проткол-то поддерживает и серверов приложений в ассортименте.

У них протоколы чем-то разные, но суть одна и та же. Надо протоколы анализировать, а мне чот времени на это нет.

одноразовые секреты с нулевым доверием к серверу

Нам нужны ссылки на теорию.

Что мешает на сервере поменять код и аккуратно хранить все передаваемые данные? А потом статистически их проанализировать исходя из того, что пароль у общающихся не меняется? И на основе этого сильно сузить область поиска ключа?

а мне чот времени на это нет

Так и вопрос не к тебе, а к автору софтины :)

У меня криптография — это одна из сфер профессиональной деятельности. И вотпрямщас стоит вовпрос аутентификации одного приложения другому. Или аутентификация приложения и ядра через netlink. OTP, вроде, подходит, но где ключи брать как всегда проблема.

От этого никто не гарантирован. Ну почитай доку на гитхабе, эта штука много от чего не защищает. От соседнего жабаскрипта в броузере,, например. Подмена сервера черевата только тем, что сообщения не будут доставлены, или будет доставлено не то.

Криптоанализ имеет смысл только если информация в сообщении сохраняет актуальность в течение времени енализа.

Использовать такую штуку можно на корпоративногм портале для чата сотрудников например. В «открытом мире» не применимо, конечно.

OTP, вроде, подходит

Надеюсь это просто к слову пришлось? Потому что обсуждаемый софт к ОТР вообще никаким боком :)

где ключи брать как всегда проблема

В ТРМ разумеется - его для этого в общем-то и делали.

В «открытом мире» не применимо, конечно.

Почему, собственно? Что конкретно плохого случится если я подниму инстанс OTS на публичном URL, доступном всему инету?

Помимо возможности секретно переслать через него дикпик в ascii-графике :)

Да, тащемта, ничего, если весь мир твоему серверу будет доверять.

Ну, почти к слову. Там нужны коротокживущие пароли. А TPM не везде есть.И не факт, что заказчик разрешит им пользоваться.

hobbit поправь на QRCode.js, пожалуйста.

Там нужны коротокживущие пароли.

стоит вовпрос аутентификации одного приложения другому.

Если пароли и OTS, то это про людей и для людей. Если приложения, то это mTLS, JWT и прочее такое машинно-ориентированное.

Не, это все тяжело. Ну какой в пень TLS между ядром и приложением? Мне, скорее, идеи интересны, нежели чем реализации.

Что мешает на сервере поменять код и аккуратно хранить все передаваемые данные?

Минимальное количество зависимостей позволяет запустить его локально. Типа «судоаптгет, гитклон, цмаке-цмаке, едем». Запустил и раздавай ссылочки, самому себя можно и не обманывать.

А потом статистически их проанализировать исходя из того, что пароль у общающихся не меняется? И на основе этого сильно сузить область поиска ключа?

Если ты подменил клиентский код, то ты получаешь и пароль, и ключ, и всё что хочешь делай. Если ты допустишь чужой js во фронт — он тоже. Если у юзера гугляндексбраузер или просто «расширение безопасности YouTubeDownloadManager» — они тоже. Против такого надо отдельное, не браузерное, приложение.

Безобразности тред:

OneTimeSecret: ложь на спине опенсорса?

В целом — да. Но у меня можно поставить и пароль, которй спасёт от «перехват ссылки»+«перехват данных без подмены клиента». И не Go+Node+Tilt.

Ну, типа, мы с тобой договорились по независимому кканалу о пароле

Так, конечно, лучше. Надо подсказку какую добавить к парольному полю. А-ля «Не отправляйте пароль тем же чатом, созвонитесь в Maxдругом мессенджере».

клиент — броузер, имеем типичное нинужно

И да, и нет.

и, даже, опасно.

И да, и нет. Тут ситуация как с onetimesecret: есть модель угроз, от которой защищает.

https://github.com/x6prl/epha-ots/blob/master/README.md#what-etha-ots-does-not-protect-against

Чё-то демка кривая
У поля ввода maxlength=5000, при этом внизу указано, что максимум 127.90 KiB. Если пытаешься отправить, то пишет
Secret is too large. Maximum size is 1 MiB.

Чё-то демка кривая

Факт. Поправим.

у меня можно поставить и пароль

Так и в OTS можно: прямо в https://github.com/Luzifer/ots раздел «Bash: Sharing an encrypted secret (strongly recommended!)» - в душе не гребу каким боком тут автору OTS привиделся bash, но пароль там точно есть.

И не Go+Node+Tilt.

Да хоть раст - кому не пофиг-то?

Зависимости же. Объем технологий. Сложность поддержки. Сложность аудита.

А баш там как раз потому что сам сервис не поддерживает такого шифрования. Ты пароль через веб-морду поставить не можешь. https://ots.fyi/

Зависимости же.

Ты где был все эти годы? Такое давно запускается в контейнере вместе со всеми зависимостями и обновляется с ними же атомарно.

Объем технологий.

Ой да ладно, ещё один императивный язык (тем более Go!) освоить это даже без LLM было не слишком сложной задачей.

Сложность поддержки.

Что ты там поддерживать собрался? Чему там ломаться?

Сложность аудита.

Это такая шутка или ты код не смотрел? Там самый большой файл это README, кода там полдюжины файлов и те меньше сотни строк.

А баш там как раз потому что сам сервис не поддерживает такого шифрования.

А сраный баш-то при чём тут? Перенаправление в любом шелле есть.

Ты пароль через веб-морду поставить не можешь.

Более того, я ни в коем случае не хочу его через веб-морду ставить - здесь же весь смысл в том что пароль ни при каких обстоятельствах не должен прилететь на сервер

Comparison to OneTimeSecret

Поставь нормальную ссылку чтобы было понятно с чего конкретно у тебя пригорело. Я не первый год пользуюсь https://github.com/Luzifer/ots (после того как с его автором пивка бахнул :) и про https://github.com/onetimesecret/onetimesecret узнал из твоего поста на ЛОР.

пароль 123

Я не понимаю почему до сих пор никто не сделает otr в виде браузер аддона к telegram web, для лишнего otr например. Хотя видел пару проектов, но все заброшено. Или просто telegram клиент кастомный с дополнительным otr, туда же можно и альтернативные звонки прикрутить в обход инфраструктуры телеграмма.

Несколько лет уже думаю об этой модификации. Руки пока не дошли.

сразу скажу о спойлере: в microhttpd сильно течёт память при высоких нагрузках (много сессий). писала им про это, они заявили, что исправлять не будут, потому что «их сервер не рассчитан на высокие нагрузки». в общем, если есть возможность, то лучше использовать другой http-сервер.

Прочитал как «одноразовые секты с нулевым доверием к серверу».

Задумался о новом для меня в области сект: одноразовых раньше не было. :))

пароль 123

Слишком простой. Вот «123456» — это круто!..

да вообще все эти кувыркоды - для додиков

Минимальное количество зависимостей позволяет запустить его локально. Типа «судоаптгет, гитклон, цмаке-цмаке, едем». Запустил и раздавай ссылочки, самому себя можно и не обманывать.

Но ведь можно обманывать других. Как другой человек проверит, что ты запустил именно «судоаптгет, гитклон, цмаке-цмаке» на своем сервере? Он должен тебе довериться? А как же нулевое доверие к серверу?

Но ведь можно обманывать других.

Факт!

Как другой человек проверит, что ты запустил именно «судоаптгет, гитклон, цмаке-цмаке» на своем сервере? Он должен тебе довериться?

Вообще, по-уму, нажмёт Ctrl+U и посмотрит код. А так, OTS это специфический инструмент и бывает нужен «между своими» и когда для принимающей стороны всё должно быть максимально просто: открыл ссылку → прочитал/скопировал. Я не хочу принудительные парли водить как раз по той причине, что «открыл ссылку → ввёл пароль → прочитал/скопировал» может быть для кого-то слишком сложно.

А как же нулевое доверие к серверу?

При таком раскладе — приятное дополнение.

лучше использовать другой http-сервер.

Можешь посоветовать что-то?

как же нулевое доверие к серверу?
При таком раскладе — приятное дополнение.

С твоим подходом - нулевое доверие отсутствует.

Кроме того, у тебя нестыковка в рассуждениях. В начале ты пишешь, что пользователь должен быть достаточно квалифицирован, чтобы нажать Ctrl+U и проаудировать код, который выполняется у него в браузере. Дальше ты пишешь, что принимающая сторона настолько неквалифицирована, что не сможет даже собственный пароль ввести (а тут плюсом сразу встает вопрос откуда пароль взять и где этот пароль/хеш хранится). В общем, одно противоречит другому.

The shareable URL contains #/<base64url(K)>.

Ну то есть, ссылки на суперсекретные сообщения нужно постить в какой-то сторонний канал. И построение превьюшки в этом стороннем мессенджере во-первых всё прочитает, во-вторых ещё и сотрёт чтобы получатель не прочитал. Зато без латте, ага, изобретённое заново колесо целый собственный сервер на си, с кучей собственных уязвимостей. Небось этот ваш Крокейшество руку приложил.

они просто не для людей. вот когда я их ещё лет цать назад использовала в промышленной автоматике - это было самое нормальное применение. там промышленный принтер методом «набрызгивания» (кстати, крутая технология, позволяет за доли секунды нанести надписи на любую поверхность даже на весьма внушительных расстояниях) наносил маркировку с QR-кодом на объекты, которые шли по тракту, и там содержалась техническая информация о дате производства, времени выпуска, линии, смене, количеству и качеству. она печаталась машинами и распознавалась также машинами. это идеальное применение QR-кодов. а люди - не роботы и не надо эту чисто промышленную фигню притягивать в жизнь. это выглядит нездорово. я считаю, что это неуважение к людям, когда вместо нормального линка постят вот это.

я бы советовала h2o. но это на вкус и цвет, так сказать.

это зависит от задачи, от требуемых протоколов, от нагрузки на сервер. есть мелкие серверы типа httpd, если клиентов не много и поддержка множества разных протоколов не важна.

Кроме того, у тебя нестыковка в рассуждениях. В начале ты пишешь, что пользователь должен быть достаточно квалифицирован, чтобы нажать Ctrl+U и проаудировать код, который выполняется у него в браузере. Дальше ты пишешь, что принимающая сторона настолько неквалифицирована, что не сможет даже собственный пароль ввести (а тут плюсом сразу встает вопрос откуда пароль взять и где этот пароль/хеш хранится). В общем, одно противоречит другому.

И да, и нет. Где нет: Ctrl+U жмёт отправляющая сторона, она же решает, «потянет» принимающая сторона пароль или нет. Где да: конечно, я полагаю, что обе стороны могут быть не в состоянии нажать Ctrl+U. Как и многое в нашей жизни, тут всё строится на доверии. И вот тут-то я предлагаю не доверять сервису дяди Вити, а пускать эту шляпу локально, даже расписываю как сделать это без белого айпи. Остаётся доверять коду. И тут я тоже предлагаю: кода мало, это Си и JS, которые читаются достаточно просто.

А нулевое доверие к серверу даже в случае сервиса дяди Вити обеспечить очень просто просто: скачай клиент (html+js).

Ну то есть, ссылки на суперсекретные сообщения нужно постить в какой-то сторонний канал.

Факт. Здесь TLS защищает от тех, кто просшуивает канал по которому передаётся ключ, а #/<base64url(K)>. защищает от тех, кто владеет сервисом. Если это одна и та же организация — ты в беде, если не использовал пароль. Пароль никуда не передаётся, даже ключ, получаемый из него. Если ты доверяешь браузеру И расширениям, которые в нём пускаешь — всё будет хорошо. Ну и ОС. Ну и шифрованию. Ну ты понел.

построение превьюшки в этом стороннем мессенджере во-первых всё прочитает, во-вторых ещё и сотрёт чтобы получатель не прочитал.

Кажется превьюшки ещё не научились исполнять JS, поэтому не прочитает. И даже не отправит ключ на сервер, потому что всё, что после # должно резаться.

целый собственный сервер на си

Там microhttpd. Функционал же примитивный: принял файлик, отдал файлик.

с кучей собственных уязвимостей.

Возможно. Дебаунс не работает вот(

Крокейшество

А это кто?

А написал я это JFF, просто у меня подгорело с OneTimeSecret.

OneTimeSecret: ложь на спине опенсорса?

Смотри, я создал секретное сообщение, получилось https://example.org/messageid#secretkey. Всё что там про браузер, https и прочее, это всё здорово. Но мне нужно прислать эту ссылку получателю. Допустим я выбрал телеграм, и прям в личные сообщения вставляю эту ссылку. И вот телеграм способен полностью получить все потроха, все эти телодвижения становятся бесполезными.

И вот телеграм способен полностью получить все потроха, все эти телодвижения становятся бесполезными.

Способен конечно! Но мы предполагаем, что пользователь не настолько «интересен», чтобы условный телеграм ходил по его ссылкам и исполнял JS с запросами. Если он достаточно интересен, то эти телодвижения становятся бесполезными и нужны гораздо более сложные телодвижения)

Есть опасность «встроенного» браузера Телеграмм. Спасибо, что навёл на это.

Можно в каждом сообщении указывать новый ключ, который должен использовать собеседник для прочтения следующего сообщения.

В итоге каждое сообщение будет зашифровано уникальным ключом и криптоанализ будет затруднён.

Впрочем, я слышал, что есть алгоритмы, у которых каждый предыдущий байт сообщения влияет на следующий. То есть добавление небольшого случайного префикса будет выдавать разные закодированные байты даже при отправке одного и того же сообщения несколько раз. Это тоже усложняет взлом радикально само по себе.