Я не хотел, чтобы WeTransfer читал мои файлы, и написал хранилище, которое не доверяет само себе

[gerbert_MX]

а зачем вообще ключ?

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

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

[MountainGoat]

главная защита это уникальная ссылка

И куча собеседников с телеметрийными расширениями, которые шлют все ссылки каким-то ботам на анализ.

[gerbert_MX]

Потому и поддержка лимитов на срок или на количество загрузок

в любом случае от ссылки с ключом оно ничем не отличается, кроме оверхеда на шифрование со стороны сервера

[onokashino]

Шифрование клиентское, в браузере, сервер ничего не парсит и не шифрует, просто гоняет непрозрачные байты, так что работы у него меньше, а не больше.

[wii]

А как залить и скачать через curl, если под рукой только консоль? Но с # частью для ключа, признаюсь, до неприличия просто впечатлен :)

[onokashino]

Спасибо! Про curl честно: готового консольного клиента пока нет, вся крипта живёт в браузере, шифрование плюс ключ из части ссылки после решётки. Так что одним curl за раз не выйдет, надо повторять формат руками. Но крипто вынесено в отдельный небольшой пакет, и сделать маленький CLI на расте вполне реально. Запишу в планы.

[persona]

Странно что не нашли. Есть такие шарилки и думаю даже не одна. На работе ставили и использовали.

[cpud47]

Почитал исходники шифрования. Каких-то прям уязвимостей не увидел сходу. Хотя кажется многие вещи можно сделать проще. Например, попытки в ctime, которые ничего не дают (но они и не нужны здесь). Но это не шибко важно.

Важно то, что схема исходно сломана. Шифрование на клиенте принципиально требует доверия к серверу. Проблема в том, что ничего не мешает серверу просто взять и отдать конкретному одному клиенту другой жс код, который, например, пришлёт пароль на сервер.

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

В идеале, для шифрования на клиенте, обновление кода должно происходить только при подтверждении пользователя. Плюс какой-нибудь transparency report от третьих лиц...

[onokashino]

Это принципиальное ограничение вообще любой браузерной E2E крипты: сервер, который отдаёт код, может одному конкретному пользователю подсунуть вредоносный js, который сольёт пароль или ключ. От этого в вебе никуда не деться, и я это не прячу.

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

[cpud47]

От этого в вебе никуда не деться, и я это не прячу.

Так это, в определённом смысле, ставит крест на всей затее. Если у нас нет доверия к серверу, то браузерный E2EE не имеет смысла декларировать.

Здесь нужно менять подход. Хотя бы банально сделать расширение для браузера, чтобы шифрование в нём происходило.

Или, что круче, это расширение браузера для контролируемых обновлений: ведёт локальный, или распределённый) реестр версий сайтов и выдаёт алерт при любом обновлении. Тогда можно было бы попробовать восстановить доверие к браузерному e2ee.

P.S. не увидел в коде собственно стримминга. Ожидал бы, что крипто библиотека выдаёт именно стрим, который сразу гонится на сервер/в загрузку, без полной буферизации...