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-сервер.

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