Может, вы и имели ввиду что-то большее, но написали совершенно конкретную вещь, и отвечали вам на неё. Речь шла о сквозном шифровании, что в вашем сообщении, что в сообщении, на которое вы отвечали. Не сквозном обеспечении целостности и не обеспечении доступности. Шифровании. Так вот, именно сквозное шифрование обеспечивается описанным методом (и наверняка есть более совершенные).
Например сохранение тайны переписки
Этим методом она полностью обеспечивается.
в том числе сохранения и самой целостности переписки
Проверка целостности легко и непринуждённо достигается крипто подписью, никаких серьёзных изменений не требуя.
Тот механизм, который вы описали далеко не новость и как раз используется текущими мессенджерами типа WhatsApp
Раз это для вас не новость, тогда странно, что вы написали, будто "накрывается медным тазом дедупликация", да ещё и использовали это как основной аргумент. Ведь благодаря такому методу она вовсе не накрывается.
1) факт доступа уже известен третьей стороне, а это уже информация о вашей активности
Да, и? Информация об активности по определению появляется у централизованной системы, тут нет особых отличий от получения доступа к обычныхому хранимому сообщению; а если и найдётся способ этого избежать, то он равно сможет работать и для файлов. И нет никакой разницы, бесплатная при этом система или платная.
2) файл может быть удалён c "blob storage" — нарушается целостность переписки
Да, и? А ещё на хранилище может упасть метеорит или напасть террорист. Файлы и переписка, внезапно, также хранятся локально на клиентах, и почему обеспечение бесперебойного вечного хранения данных должно быть включено в понятие сквозного шифрования — совершенно непонятно. И снова нет никакой разницы, бесплатная при этом система или платная, централизованная или нет.
3) чем больше участников могут просмотреть такой расшаренный файл, тем больше шансы на утечку ключа шифрования этого файла, неужели это так неочевидно?
Да, и? Проблемы реализации. В случае утечки ключа методы, использующий хранимые дынные, делает эти данные потенциально доступными, вне зависимости от того, бесплатная при этом система или платная, централизованная или нет. Этот метод в таком случае раскрывает больше информации, чем отдельный ключ для каждой копии. Наверняка есть более совершенные.
4) вы в курсе про проблемы шифрования файлов и про банальную атаку по размеру, по которой можно даже иногда идентифицировать зашифрованный файл?
Да, и? Для всего есть методы, начиная с простейшего рандомного дополнения файла. И снова нет никакой разницы, бесплатная при этом система или платная, централизованная или нет.
Для меня полноценное end-to-end security, это когда ни расшифровать, ни повлиять на диалог третья сторона не может никоим образом.
Жалко, что мы не говорили об end-to-end security, мы говорили о сквозном шифровании: end-to-end encryption.
Отсюда и проблемы дедупликации и отсутствие такого подхода в мейнстриме.
Что ж, ну хоть уже просто "проблемы", а не "накрылось медным тазом". Так, глядишь, придём к тому, что да, трудности есть, но принципиально погоды не делают : ) А насчёт сквозного шифрования в мейнстриме с вами не очень хотят соглашаться WhatsApp и Viber.
Не соглашусь. Но это в сущности вопрос терминологии. Файл шифруется до отправки на стороне отправителя и расшифрован может быть только с помощью ключа. Ключ передаётся сообщением со сквозным шифрованием, а значит может быть расшифрован только получателем. Что в конечном итоге позволит только ему расшифровать файл. Конечный результат в этом смысле не отличается от "прямой" передачи файла.
Если этот файл будет, например, трактоваться как запрещённая информация, факт доступа к нему доказать очень просто
Кем? Как? Не потребуется ли для этого множество других условий, о наличии или отсутствии которых я ничего не говорил? И какое это имеет оношение к делу?
ключ для расшифровки в такой схеме можно считать уже полностью скомпрометированным
Есть пример продуктов аналогичных Viber, Whatsapp, TG с e2e для всех?
Literally Hitler Viber and WhatsApp. Т.е. даже из вашего списка только Telegram не имеет сквозного шифрования по умолчанию. Signal и Matrix довольно популярны, но не настолько, да, и?
То есть, причём здесь этот аргумент? Вы же не написали "мессенджеру со сквозным шифрованием по умолчанию не войти в топ-3 по массовости" (хотя и это неверно), вы написали "Вероятность равна нулю для любой централизованной бесплатной системы", и я отвечал именно на это, а теперь вы предлагаете дискутировать о чём-то совершенно другом.
Зарабатывать они могут на дополнительных сервисах, профессиональных, как Wire, или развлекательных, могут зарабатывать на рекламе (да, менее эффективно), или опросах каких-нибудь, или вообще быть некомменрческой организацией и принципиально отказываться зарабатывать, живя на пожертвования. Это отдельный вопрос, но это точно не невозможно.
Сквозное шифрование для всех чатов по умолчанию не позволяет хранить историю сообщений между устройствами
А Signal, Wire и Matrix-то и не в курсе.
Сверху уже дали более развернутый ответ.
Более развёрнутый неправильный ответ.
Сквозное шифрование действительно усложняет хранение и всё такое, но далеко не так сильно, как указано, и уж конечно не делает возможность существования бесплатных централизованных систем со сквозным шифрованием нулевой.
Для файлов (всех или больше определённого размера) можно использовать другую модель шифрования: при первой загрузке файл шифруется и может быть безопасно сохранён на сервере (сервер не может получить доступ к содержимому, поскольку не знает ключа; для пущей надёжности можно посолить), в дальнейшем при пересылке этого файла пересылается ссылка на него и ключ шифрования — поскольку это происходит с использованием сквозного шифрования, сервер никогда не получит доступа к ключу, а значит и к содержимому файла.
Конкретно этот метод работает только для пересылаемых файлов, а не для повторных загрузок одинаковых файлов разными пользователями, но я предположу, что при вирусном распространении чего-то популярного это позволяет не хранить процентов 90 "копий" такого файла, если не больше (в смысле, в подавляющем большинстве случаев люди именно пересылают, а не скачивают и загружают заново).
И это возникшая за 10 секунд схема (я гораздо дольше писал этот комментарий), при вдумчивой проработке найдутся методы куда более продуктивные (за следующую минуту в голову ещё пришла возможность использования элементов метода работы HIBP / Firefox Monitor при проверке паролей — когда вы отправляете часть хэша, недостаточную для сервера для восстановления исходной информации, в этом случае пароля, но достаточную, чтобы вернуть вам разумный по размеру массив полных хэшей, которые вы уже сами проверяете).
И вообще — Signal, Wire и Matrix не согласны с вашим суждением о нулевой вероятности : )
newTrackon мониторит публичные трекеры и ведёт статистику аптайма, так что с него удобно брать список трекеров с высоким аптаймом, а не все подряд, как в этих файликах на GitHub и т.п. Через API можно, например, взять все трекеры с аптаймом больше 95 или любым другим указанным (в примере по ссылке 99).
Звучит как начало поста 😉
Это где такое? У меня DoT/DoH хорошо работают.
Видимо имеется ввиду принцип, как в АнтиЗапрет: https://bitbucket.org/anticensority/antizapret-vpn-container (см. раздел Особенности VPN в описании).
РКН, см. https://habr.com/ru/news/t/667096
Raspberry Pi же теперь умеет загружаться с USB, и microSD необязательна, насколько я понимаю.
Из горячего также есть (цены за месяц):
Из холодного:
Это из тех, кто не слишком наглеет с ценами за трафик. Наверняка есть ещё.
¹ Хотя Sia и не совсем корректно сравнивать с централизованными облачными хранилищами
Или воспользоваться консолью Firefox, позволяющей делать скриншоты всей страницы или конкретного элемента, задавать любое разрешение (больше или меньше реального), и вообще. TL;DR
Anki
Может, вы и имели ввиду что-то большее, но написали совершенно конкретную вещь, и отвечали вам на неё. Речь шла о сквозном шифровании, что в вашем сообщении, что в сообщении, на которое вы отвечали. Не сквозном обеспечении целостности и не обеспечении доступности. Шифровании. Так вот, именно сквозное шифрование обеспечивается описанным методом (и наверняка есть более совершенные).
Этим методом она полностью обеспечивается.
Проверка целостности легко и непринуждённо достигается крипто подписью, никаких серьёзных изменений не требуя.
Раз это для вас не новость, тогда странно, что вы написали, будто "накрывается медным тазом дедупликация", да ещё и использовали это как основной аргумент. Ведь благодаря такому методу она вовсе не накрывается.
Да, и? Информация об активности по определению появляется у централизованной системы, тут нет особых отличий от получения доступа к обычныхому хранимому сообщению; а если и найдётся способ этого избежать, то он равно сможет работать и для файлов. И нет никакой разницы, бесплатная при этом система или платная.
Да, и? А ещё на хранилище может упасть метеорит или напасть террорист. Файлы и переписка, внезапно, также хранятся локально на клиентах, и почему обеспечение бесперебойного вечного хранения данных должно быть включено в понятие сквозного шифрования — совершенно непонятно. И снова нет никакой разницы, бесплатная при этом система или платная, централизованная или нет.
Да, и? Проблемы реализации. В случае утечки ключа методы, использующий хранимые дынные, делает эти данные потенциально доступными, вне зависимости от того, бесплатная при этом система или платная, централизованная или нет. Этот метод в таком случае раскрывает больше информации, чем отдельный ключ для каждой копии. Наверняка есть более совершенные.
Да, и? Для всего есть методы, начиная с простейшего рандомного дополнения файла. И снова нет никакой разницы, бесплатная при этом система или платная, централизованная или нет.
Жалко, что мы не говорили об end-to-end security, мы говорили о сквозном шифровании: end-to-end encryption.
Что ж, ну хоть уже просто "проблемы", а не "накрылось медным тазом". Так, глядишь, придём к тому, что да, трудности есть, но принципиально погоды не делают : ) А насчёт сквозного шифрования в мейнстриме с вами не очень хотят соглашаться WhatsApp и Viber.
Не соглашусь. Но это в сущности вопрос терминологии. Файл шифруется до отправки на стороне отправителя и расшифрован может быть только с помощью ключа. Ключ передаётся сообщением со сквозным шифрованием, а значит может быть расшифрован только получателем. Что в конечном итоге позволит только ему расшифровать файл. Конечный результат в этом смысле не отличается от "прямой" передачи файла.
Кем? Как? Не потребуется ли для этого множество других условий, о наличии или отсутствии которых я ничего не говорил? И какое это имеет оношение к делу?
С чего вдруг?
Literally
HitlerViber and WhatsApp. Т.е. даже из вашего списка только Telegram не имеет сквозного шифрования по умолчанию. Signal и Matrix довольно популярны, но не настолько, да, и?То есть, причём здесь этот аргумент? Вы же не написали "мессенджеру со сквозным шифрованием по умолчанию не войти в топ-3 по массовости" (хотя и это неверно), вы написали "Вероятность равна нулю для любой централизованной бесплатной системы", и я отвечал именно на это, а теперь вы предлагаете дискутировать о чём-то совершенно другом.
Зарабатывать они могут на дополнительных сервисах, профессиональных, как Wire, или развлекательных, могут зарабатывать на рекламе (да, менее эффективно), или опросах каких-нибудь, или вообще быть некомменрческой организацией и принципиально отказываться зарабатывать, живя на пожертвования. Это отдельный вопрос, но это точно не невозможно.
А Signal, Wire и Matrix-то и не в курсе.
Более развёрнутый неправильный ответ.
Сквозное шифрование действительно усложняет хранение и всё такое, но далеко не так сильно, как указано, и уж конечно не делает возможность существования бесплатных централизованных систем со сквозным шифрованием нулевой.
Для файлов (всех или больше определённого размера) можно использовать другую модель шифрования: при первой загрузке файл шифруется и может быть безопасно сохранён на сервере (сервер не может получить доступ к содержимому, поскольку не знает ключа; для пущей надёжности можно посолить), в дальнейшем при пересылке этого файла пересылается ссылка на него и ключ шифрования — поскольку это происходит с использованием сквозного шифрования, сервер никогда не получит доступа к ключу, а значит и к содержимому файла.
Конкретно этот метод работает только для пересылаемых файлов, а не для повторных загрузок одинаковых файлов разными пользователями, но я предположу, что при вирусном распространении чего-то популярного это позволяет не хранить процентов 90 "копий" такого файла, если не больше (в смысле, в подавляющем большинстве случаев люди именно пересылают, а не скачивают и загружают заново).
И это возникшая за 10 секунд схема (я гораздо дольше писал этот комментарий), при вдумчивой проработке найдутся методы куда более продуктивные (за следующую минуту в голову ещё пришла возможность использования элементов метода работы HIBP / Firefox Monitor при проверке паролей — когда вы отправляете часть хэша, недостаточную для сервера для восстановления исходной информации, в этом случае пароля, но достаточную, чтобы вернуть вам разумный по размеру массив полных хэшей, которые вы уже сами проверяете).
И вообще — Signal, Wire и Matrix не согласны с вашим суждением о нулевой вероятности : )
Попробуйте 4х-мерный
Всё так. В полном соответствии со знаменитой формулой Ё*Т=m*c^2
Оттуда не то что мейнтейнер, оттуда недавно основатель ушёл : ) /s
Уже изобретено, написал ниже.
ZeroTier (open source виртуальная LAN, типа Hamachi) легко решает эту проблему. Вот простое краткое описание и опыт использования (англ.).
newTrackon мониторит публичные трекеры и ведёт статистику аптайма, так что с него удобно брать список трекеров с высоким аптаймом, а не все подряд, как в этих файликах на GitHub и т.п. Через API можно, например, взять все трекеры с аптаймом больше 95 или любым другим указанным (в примере по ссылке 99).
Сорри за некропост :)