Комментарии 249
Так-то идея неплоха.
А я вот как не понимал зачем, так и не понимаю. Какие такие персональные данные мне удобнее хранить в облаке, и куда это я буду их потом предоставлять? Свои имя/фамилию я и так помню, и ввести не обломаюсь, адрес для доставки — величина переменная, а номер паспорта/ИНН — это только для госуслуг, и никакого телеграма там никогда не будет и быть не должно.
(Ещё мне непонятно, как загруженный скан паспорта вообще подтверждает личность закачавшего, если он никем не проверяется. Ну вот закачает тот же арендодатель с Airbnb ваш паспорт вместо своего, как такое решается?)
Некоторые просят видео, в живую.
А с Телеграм Паспорт можно будет их купить гораздо более удобным способом...
Более того, можно вообще ничему ниоткуда не утекать, а просто создаём видимость того, что набираем людей на удалённую работу, ездим им по ушам и добиваемся заветных фотографий…
Кстати, я подозреваю, что даже такое «посмотрел и удалил» нарушает российский закон о локализации персональных данных. Что отчасти объясняет то, почему Blizzard молча утираются, когда им случайно прилетает привет от РКН в виде веерных блокировок, и раздают баны на форуме даже за слово «Роскомпозор». Им очень не хочется лишний раз привлекать к себе внимание.
Ну вот закачает тот же арендодатель с Airbnb ваш паспорт вместо своего, как такое решается?
Думаю им пофиг, это требование регулятора а требования решать "такое" там нет :)
Благодаря KYN почти все криптобиржи и недобанки хотят фотку с паспортом и никак не проверяют достоверность данных.
www.electronicid.eu/selfie-based-identification-solutions-not-compliance-kyc-aml
Кстати, про подтверждение личности сканом паспорта — в Москве уже 20 или более каршеринг компаний… И везде надо отослать одинаковые фотографии паспорта, ВУ, и т.п. После 3-его раза это ОЧЕНЬ надоедает.
Но опять же, а чем телегам паспорт поможет? Для этого он сначала должен стать настолько же популярным, насколько facebook или gmail, чтобы каждый второй владелец сервиса старался его внедрить.
Многие частные «конторки» имеют отдельные условия работы, пройдя необходимую бюрократию, включая даже лоббирование изменения законодательства.
Во всех странах эти процедуры существуют и могут быть пройдены частной компанией. Большинство банков — частные коммерческие структуры, и ничего — и документы хранят в электронном виде и так далее.
Еще раз скажу, что в СНГ с этим сложнее, так как злоупотребление властью — стандартная практика.
Например, я работал в крупной медицинской компании, которая имела свои сертифицированные склады хранения медикаментов (включая и зоны для хранения веществ, подпадающих под наркотические). Компания самостоятельно разработала процедуру растаможки лекарственных средств, которая занимала в три раза меньше времени, чем обычная. Процедура была проверена экспертизой, и конкретно для нашей компании таможня дала добро. Понятно, что компания потратила на всю экспертизу и разработку много денег. Но прямые контракты поставщиков, которые проходя процедуру разтаможки за гораздо меньший срок (что очень критично для лекарств, у которых срок годности, например, месяц) — все расходы достаточно быстро покрыли.
И да, коммерческая компания выполняла работу, которая казалось бы должна принадлежать исключительно гос.службе (таможне). Но все было согласовано, законность соблюдена, все довольны.
В общем если все идут друг другу навстречу — все будет.
банк не просит вас сфотографироваться с картой и договором на фоне для того чтобы вам предоставить услуги.
Карту он мою и так знает, а что до фотографии… давно уже при заключении договора в банке в реальном времени фотографируют на веб-камеру.
— полноценный аккаунт госуслуг
— возможность регистрировать ИП/ООО в налоговой
— возможность подписать трудовой договор дистанционно (и без почты)
…
Решение: заходя на сайт авиакомпании, сайт обращается к плагину хрома от телеграмма, и запрашивает нужные данные, плагин спрашивает у вас разрешение на шаринг этих данных с этим сайтом, вы соглашаетесь и вы автоматом залогинены и вся информация для покупки билетов уже считайте введена, осталось только выбрать направление, опции и оплатить.
То же самое с онлайн покупками где нужно вбивать адрес доставки.
Кстати некоторые криптовалютные проекты уже предоставляют такую функциональность, включая оплату, очень удобно.
I found a bug, what do I do?
Please contact us via e-mail. Despite on there's no bug-bounty program (non-profit project), some problems may be rewarded.
Despite on
За такое издевательство над языком и правда надо канделябром.
По моим наблюдениям, только в рунете любые ошибки на любом языке будут неминуемо пытаться исправить. Иностранцы, читая такие вещи, вежливо говорят, что оборот fairly rare, but understandable. Никто никого не бьёт.
Очевидно же: расслабляем мозг и произносим «зыбский».
Понимание слова само придёт.
Даль тут мне не особо помог.
ru.wikisource.org/wiki/%D0%A1%D1%82%D1%80%D0%B0%D0%BD%D0%B8%D1%86%D0%B0:%D0%A2%D0%BE%D0%BB%D0%BA%D0%BE%D0%B2%D1%8B%D0%B9_%D1%81%D0%BB%D0%BE%D0%B2%D0%B0%D1%80%D1%8C._%D0%A2%D0%BE%D0%BC_1_(%D0%94%D0%B0%D0%BB%D1%8C_1903).djvu/886
Напомнило, как одна знакомая удивлялась слову «стрекать», «крапива стрекает». В ее краях так не говорили )
«Зыбский пирог», например, это «вкусный пирог».
Вот одну такую окраину не били, и к чему это привело?
Иностранцы, читая такие вещи, вежливо говорят, что оборот fairly rare, but understandable.
Мне тоже много чего understandable, но приятного от этого мало. Например, данное произведение вполне понятно, но от суржика, на котором говорит главгерой, ОЧЕНЬ корёжит и читать жутко сложно.
на деле же английский как общепринятый язык международного общения имеет тяжкое обременение в виде размывания норм.
E2E называется так, потому то позволяет показывать третьим лицам зашифрованные данные не опасаясь за их сохранность. Как мы увидели, это условие новым продуктом телеграма не выполняется.
Мне кажется, что Вы не правы в том смысле, что E2E это принцип/механизм, а не гарантия
Люди видят «End-to-End» и в голове у них это бренд, который подразумевает безопасность.
Сквозное шифрование (также оконечное шифрование; англ. end-to-end encryption) — способ передачи данных, в котором только пользователи, участвующие в общении, имеют доступ к сообщениям
Рассмотрим ситуацию:
Я использую пароль «1» и заливаю свои персональные данные в облако телеграма.
Получает облако доступ к моему «сообщению»? Да, конечно получает, миллисекунды через три оно будет расшифровано и полностью им доступно. Нарушается ли при этом принцип E2E? Конечно нарушается
10 GPU переберут все возможные сочетания 8 значных паролей за 80 дней
Если мерить видеокартами, какова должны быть надежность настоящего E2E в штуках? На основе чего вы предъявляете требования именно в таком количестве штук?
А если вы используете бесконечно длинный пароль и время его взлома будет бесконечно велико
Надежность системы определяется самым слабым звеном, для данной системы наихудшим вариантом будет взлом AES-256.
По поводу Е2Е с научной/инженерной/академической точки зрения Вы правы, но с обывательской — когда человек видит Е2Е, то считает что данные надёжно защищены, а в данном случае система и правда «дырявая»…
А технически подкованный человек и так знает о том что абсолютно защищенных систем не существует и стоит защищать себя самому, поэтому для него E2E тоже ничего не значит.
если обычный человек видит E2E, то это ему вообще ни о чём не говорит
Многие знают или хотя бы слышали термин и имеют ассоциацию с защитой данных, в немалой степени это заслуга РосКомПозора и недавней битвы с Telegram.
абсолютно защищенных систем не существует
В реальной жизни вообще ничего абсолютного не существует.
стоит защищать себя самому
Сделать всё самому, к сожалению, невозможно, довольно часто приходится обращаться за услугами к другим людям/организациям. Но ответственности за себя с человека этот факт, конечно, не снимает.
Мне кажется, что Вы не правы в том смысле, что E2E это принцип/механизм, а не гарантия
Справедливости ради, телеграм тоже назвал End-to-end-ом не совсем то, чего ожидаешь в таких случаях. Насколько я понял, закрытый ключ здесь всего у одного владельца, а Passport — просто хранилище зашифрованных данных, которые расшифровать можно только зная секрет. Нужно было в начале статьи разграничить понятия «End-to-end» и «хранилище зашифрованных данных без доступа» и после этого заявлять, что секрет можно сбрутить.
Без Proof of Concept, конечно, «восьмизначный пароль за 5 дней на GPU-кластере» — вывод так себе. Ежу ж ясно, что любой секрет можно гипотетически сбрутить в том случае, если этот секрет является достаточной информацией для расшифровки.
P.S мне все больше кажется что просто даже блокировка телеграмма была качественным маркетинговым ходом, чтобы сейчас люди начали вестись на подобные продукты от Telegram, потому как до сих пор работает как и работал…
P.S давайте не будем поднимать холивар на полит темы
то уже бы отработали Дурова по другомуСиловыми методами? Или на родителей бы надавили, живущих в России?
По-моему, это дикость и варварство.
И как? Потому как с запрещённми организациями особенно ничего поделать не могут. Даже победоносная войнушка не очень получилась (сначала на словах победили к выборам, а потом как-бу уже и не очень).
Ссылка на ваш продукт в конце текста, во-первых, прямо противоречит первому пункту правил Хабра («запрещена реклама в обход правил»),
а во-вторых, несколько подрывает доверие ко всему тексту: вы очень заинтересованы ругать чужую криптографию, если за счёт этого продаёте свою.
Я человек простой, в криптографии глубоко не разбираюсь, и у меня два простых вопроса. Вы пишете, что в Telegram Passport не внедрили защиту от перебора с помощью GPU, и «на это уйдёт 80 дней». Вопросы такие:
1. Правильно ли я понимаю, что такой защиты нет не только в Telegram Passport, но и в основной переписке Telegram?
2. Если это так, то почему никто не брутфорснул с помощью GPU переписку Павла Дурова, за расшифровку которой была обещана большая награда?
Основная переписка телеграма защищена по другому, там пароли не участвуют. Но она тоже не E2E, облако видит всю переписку
Не знаю, если честно, как это реализовано в сторонних клиентах, надо-бы попробовать.
Для себя лично я вижу ситуацию необходимости использования секретного чата именно с мобильного клиента, когда нужно быстро начеркать несколько очень важных слов. Или позвонить, ведь звонки так же е2е шифрованы.
Для разговоров с близкими о вечернем ужине я выберу более удобные обычные чаты, даже при наличии секретных на всех клиентах.
Не знаю, если честно, как это реализовано в сторонних клиентах, надо-бы попробовать.
Я не зря omemo упомянул — там эта проблема успешно решена.
Подход вотсапа к бэкапу истории сообщений в большинстве случаев приводит к потере е2е при заливке бэкапа в гугл-драйв/другое. В телеграме секретные чаты не бэкапятся, т.е. всегда остаются е2е. Обычные чаты хранятся и синхронизируются серверами.
Наверно тем, что при бэкапе она не зашифрована?
Добавление е2е в десктопный клиент потянет за собой вопросы начиная от «куда делись мои чаты?» до «как выбрать, на каком клиенте собеседника появится вновь созданный чат, не спалив чужих устройств?»
Поддержка «секретных чатов» (e2e) есть в десктопном клиенте для Mac, и да, из-за отсутствия синхронизации получается не очень удобно.
«как выбрать, на каком клиенте собеседника появится вновь созданный чат, не спалив чужих устройств?»
Возможно, по аналогии с SIP Proxy, активное устройство будет регистрировать свой ip.
Сколько GPU-часов надо для взлома 20-значного пароля с алфавитом на 64 символа?
Палец промахнулся раза в два по порядку, на самом деле там 10^19 лет, но это всё-равно более чем.
Для 20 — вероятно да, общая ёмкость криптовалютных вычислений такое скушает время большее жизни вселенной (10^20 лет примерно), это учитывая ASIC и всё остальное (хотя сейчас ASIC из SHA256 в SHA512 переделать нельзя, прикидка чисто по хешрейту). Но учитывая что SHA-512 2003 года выпуска, в 2008 нашли коллизии для 22 итераций, в 2016 для 27 (всего их 64 напомню). То я думаю что подбор такого пароля в итоге займёт времени значительно меньше времени жизни вселенной.
В остальном согласен, есть HMAC, есть AEAD, а это какой-то совсем уж самопал. Ещё не совсем понятно зачем в облаке зашифрованный ключ, ведь криптография всё равно выполняется на стороне клиента и ключу незачем покидать пределы устройства.
Но, к примеру, если правильно зашифровать данные не на хэш от пароля, а на публичный ключ, то никакой даже миллиардный кластер не сможет к ним и близко подобраться.
Написали бы про протокол Диффи-Хеллмана — таких вопросов бы не возникло.
если будете пользоваться Gram, то Telegram-у нужен будет ваш Passport, потому что Знай своего клиента, иначе Дуров пойдет за Винником.
В компании обещают, что Telegram не будет иметь доступа к личным данным пользователей. Они будут переходить непосредственно к получателю.
Меня больше волнует в каком виде Telegram будет раздавать наши паспорта: текстом "да, это он!" (т.е. вручную подтверждается личность с походом в какое-нибудь почтовое отделение) или солянка из скана, телефона и мыла… Потому что гладиолус GDPR. И я не хочу, чтобы у видео-салона "Рога и копыта" (или тот же "Fhloston Paradise" из были мои паспортные данные с фоткой, мылом и телефоном — зачем им оно и куда они это будут сливать?
На скриншоте показано, что некий сервис запрашивает мои личные данные, телефон и мыло. Абсолютному большинству всяких веб-сайтов нужно только мыло, которое я и так бы указал при входе или регистрации. Но вот сам интерфейс — сервис запросил личные данные и стрелка, которую никто в большинстве раскрывать не будет, а просто жмакать ОК (не все же параноики и продвинутые айтишники) — выглядит стремно. Т.е. лучше бы, если сервису нужно что-то помимо мыла, интерфейс изменить, чтобы пользователь явно подтвердил (проставил галочки как минимум), что он согласен отправить свой паспорт, вод./пенс.удостоверение и так далее этому сервису.
Q: Как восстановить пропавшие при обновлении документы?Вообще пушка, программа года.
A: К сожалению, никак. Потеря документов стала следствием необратимого технического сбоя. Мы сделали все возможное, чтобы избежать повторения ситуации в будущем.
Q: Как синхронизировать документы с iCloud/Dropbox?
A: Этот вид синхронизации больше не нужен, документы автоматически синхронизируются с нашим сервером. Ваши данные надежно защищены. Это было сделано, чтобы избежать повторения ситуации с потерей локально хранящихся данных. Возможность восстановления из резервной копии в iCloud или Dropbox сохранится до выхода новой версии ВКармане. Теперь все документы синхронизируются автоматически между всеми вашими устройствами.
Q: Почему пропал офлайн-режим работы?
A: Мы недооценили, насколько это важная функция для вас. Офлайн-доступ к документам обязательно вернется в следующей версии.
Q: Короткий код доступа — это не безопасно. Как мне вернуть длинный пароль?
A: Данная схема безопасна. Заданию короткого кода доступа предшествует авторизация по номеру телефона с кодом подтверждения из смс. Короткий код сбрасывается после трех неправильных попыток ввода. После этого требуется снова пройти полную авторизацию. Возможность задания длинного пароля вернется вместе с офлайн-режимом работы, где наличие длинного пароля необходимо для обеспечения безопасности.
> A: К сожалению, никак. Потеря документов стала следствием необратимого технического сбоя. Мы сделали все возможное, чтобы избежать повторения ситуации в будущем.
Напомнило печальную историю с одним из хостинг-провайдеров: «ребята, мы все случайно удалили, но больше такого не повторится, честно-пречестно».
Нечто подобное видел у 1Password
Очевидный KeePass имеет функцию прикрепления любого файла и позволяет вводить любые поля с любыми данными. Просто залейте скан и забейте все поля. Поиск тоже есть.
Но таки да, самодельная криптография это зло.
github.com/vk-com/kphp-kdb/blob/master/memcached/memcached-data.c#L50
github.com/vk-com/kphp-kdb/blob/master/copyexec/copyexec-commit.c#L147
github.com/vk-com/kphp-kdb/blob/master/KPHP/common.h#L135
github.com/vk-com/kphp-kdb/blob/master/text/text-data.c#L2543
Часто используется в kphp/kdb движках, особенно в функциях хэширования, одним из авторов которых является Николай Дуров.
Тогда я тоже задавался вопросом почему именно 239.
А где он учился? Для ленинградцев, в детстве увлекавшихся математикой, число 239 очень-очень знакомо =)
Как-то раз в конторе, где я работал, была проблема с очень странным поведением игрового персонажа. Выяснилось, что причиной этого был следующий код:
int random()
{
return 239;
}
На одном хорошем GPU можно перебирать чуть больше миллиарда SHA-512 в секунду. 10 GPU переберут все возможные сочетания 8-значных паролей за 80 дней.
А что имеется в виду под сочетаниями 8-значных паролей? Вся таблица юникод что-ли?
Обычные пароли из латиницы, цифр, спецсимволов вскрываются гораздо быстрее.
На обычном домашнем компе с бюджетным джефорсом при помощи хешкета и при гораздо меньшем хешрейте ушло где-то часа 2. На 8 символов.
Можете поделиться источником инфы про миллиард sha-512 в секунду? Интересно узнать, на каком оборудовании это делали и с помощью какого ПО.
Hashtype: SHA-512
Speed.Dev.#1.....: 1511.9 MH/s (77.65ms)
Speed.Dev.#2.....: 1524.0 MH/s (77.04ms)
Speed.Dev.#3.....: 1487.6 MH/s (78.90ms)
Speed.Dev.#4.....: 1504.3 MH/s (78.05ms)
Speed.Dev.#*.....: 6027.8 MH/s
Одна карточка выдаёт полтора гигахэша в секунду
Я вчера сменил пароль на учетную запись в Телеграме. Так вот, на телефоне мне даже не пришлось вводить этот новый пароль.Правильно, у приложения на телефоне есть токен и сессия остаётся валидной. Приложение на телефоне ведь не хранит ваш пароль, чтобы каждый раз авторизовываться. Оно при первом подключении (когда вы вводили логин-пароль), получило у сервера токен и авторизовывается по нему.
Это обычная практика. Позволяет легко отозвать доступ у какого-либо устройства, не меняя пароль. И повышает безопаность, потому что пароль не хранится на устройстве.
А что на счет того, что мои данные в Telegram Passport перешифровываются новым паролем? Я только что еще раз проверил. Меняю пароль через десктоп. Открываю приложение на телефоне, а в нем уже новый пароль на Passport. Как-то это не совсем похоже на End-to-End.
В облако передаются:
Хэш от персональных данных, смешанных со случайными байтами
Зашифрованный паролем почти случайный ключ
Соль
Зашифрованные данные
Когда вы поменяли пароль на десктопе, ваши данные перешифровались на том же десктопе (новым ключом, который защищён вашим новым паролем), залились в облако, откуда их подтянул смартфон. Соответственно, теперь у вас на смартфоне обновлённые зашифрованные данные, к которым подходит ваш новый пароль.
Точно так же, допустим, у меня в облачном хранилище Dropbox лежит зашифрованный паролем текстовый файл. Если я на десктопе перешифрую его с другим паролем, то файл автоматически зальётся в облако и будет доступен на других моих устройствах, где я смогу его расшифровать с новым паролем. Пароль, при этом, не уходит дальше моих устройств, где я выполняю шифрование и расшифровку.
core.telegram.org/passport/example
страница перекидывает в десктопное приложение, которое запросит пароль и предложит загрузить документ
Есть операторы связи, с которыми человек заключает договор, предоставляя свои документы подтверждающие личность, есть организация GSMA, в которую входят эти самые операторы связи и есть протокол RCS, который вскоре заменит традиционные СМС. Google уже потеет над этим вопросом jibe.google.com
Так вот протокол RCS явно не будет стоять на месте и электронное правительство, бизнес и прочие скорее будут использовать этот вариант, а не поделия Павлика Морозова, который завтра может исчезнуть вместе со своим грамом по щючьему велению.
Вы же зачем-то притянули его к этой истории с телеграмом.
Старые системы уходят, новые приходят, что тут такого? RCS к слову, мертвая технология, она нужна только операторам и больше никому.
Это всё так же смешно, как новость про закрытое ICO Telegram и участие в нём хотя бы того же Сергей Солонина.
Переход на личности? Мило.
Я даже вам сюда не буду приносить картинку с % сообщений передающихся через SMS и мессенджеры, спойлер — у SMS менее 5%.
Оператор в нынешне время — это труба для трафика, вполне понятно, что они хотят поднять прибыль за счёт дополнительных сервисов, но учесть RCS стать очередным internet explorer. Помните в 3G сетях были видео звонки? Прямо нативные, и что, где там они? Много кто использует?
Я ещё могу понять запуск шлюза в мессенджере с привязкой банковской карты, но не вот это вот всё.
Chrome тоже не входит в поставку OS по умолчанию и что?
Однако есть куча устройств, на которых SMS/RCS — единственный канал получения текстовой информации.
Пример устройства пожалуйста, где нельзя поставить мессенджер но есть RCS?
В перспективе — feature phones.
Для корпоративного общения есть Skype For B им пользуются 99.9% крупных компаний, RCS не обеспечит защищенность и интеграцию с Exchange. А ну и да, он ещё и на десктопах работает как там с этим у RCS?
Вопрос не в том, что текущий подход сложно обновить на использование нормальных алгоритмов, а в том, зачем вообще они использовали такие слабые алгоритмы — потому что единственное напрашивающееся объяснение это создание условий для дешёвого брутфорса паролей юзеров на их серверах.
Понимаете, чтобы вот так говорить, что у них не End-to-End, что они собираются расшифровывать данные пользователей и вообще сотрудничают с ФСБ, надо иметь какие-то более веские доказательства, чем неудачно выбранный алгоритм хэширования. Они завтра поменяют в одной строчке его на bscrypt/scrypt, и какие будут ваши аргументы?
Раздолбайство — это действительно более частая причина. Но есть нюансы: телеграм уже довольно много работал со сложной криптографией (так что его разработчики гарантированно в теме), и обсуждаемый Passport позиционируется как продукт ориентированный на безопасность/E2E/все дела (так что раздолбайство на таком уровне при его разработке — это для репутации ещё хуже, или по крайней мере ничем не лучше). Всё это вместе вызывает сильные сомнения в том, что дело в раздолбайстве, хотя полностью такой вариант исключить тоже нельзя.
и первый байт расшифрованного текста, который из-за использования JSON будет всегда "{" или "[".
Вот это просто facepalm. Для повышения безопасности можно добавлять к каждому сообщению рандомные байты в начало, а при дешифровании сообщения они бы отметались. Например, первый байт = количество случайных байт, и далее случайные байты.
Конкретно здесь самая большая проблема в выведении ключа из пароля. Если бы использовался PBKDF2 или argon с разумным количеством итераций, такой ключ был бы достаточно надежным (при условии, конечно, что пароль хотя бы не словарный).
Если ввести данный пароль для доступа в Passport неправильно три раза, то происходит блокировка доступа к Passport на много часов. Следовательно, это затруднит брутфорс, но это не отменяет того, что вы написали в посте.
Что мешает серверу Телеграм прикинуться «сторонним сервисом», послать свой открытый ключ, получить перс. данные, и затем уже переслать их стороннему сервису?
Вот кстати интересный вопрос. Вероятно, открытый ключ стороннего сервиса должен предоставляться не ТГ, а самим сервисом, к примеру при редиректе в ТГ в параметрах Урла указывать ссылку на свой ключ (возможно такое вообще?)
1. ТГ выступает в роли автоматизированного дропбокса
2. Вы своим открытым ключом шифруете свои данные и заливаете в ТГ.
3. При авторизации в стороннем сервисе (СС):
3.1. СС отдает вам свой открытый ключ напрямую (без посредничества ТГ) как? А хз — это один из самых сложных моментов в таких схемах.
3.2 Вы выкачиваете у телеграмма свои данные себе (не все, а только те, что нужны СС)
3.3. Расшифровываете их своим закрытым ключом, шифруете открытым ключом СС, отдаете обратно зашифрованные данные ТГ
3.4. ТГ отдает зашифрованные данные СС, они их там своим закрытым ключом расшифровывают.
Зачем в этой схеме ТГ? А не знаю.
Мне кажется, гораздо большей проблемой являются сервисы, которые запрашивают такие данные и то, как они их потом хранят. Реализации Телеграма мы все можем устроить аудит, а что там у сервиса, для которого требуется такая аутентификация мы не знаем, может они вообще все в плентексте хранят или в открытом бакете s3 (уже не один случай такой был)
В клиенте перед тем как шифровать всё телеграмовским алгоритмом — шифровать открытым ключом.
На стороне стороннего сервиса в обертке расшифровывать.
Только придется думать о независимом от телеграмма канале передачи открытого ключа от стороннего сервиса клиенту.
Хотя… *картинка с троллейбусом*
«Никогда не используйте изобретённый вами прорывной/эффективный/оригинальный метод шифрования в системах, единственной целью которых не является удовлетворение вашего любопытства».
Дополнение к написанному: «И свои собственные реализации известных алгоритмов тоже не пишите, ограничьтесь аудитом используемых библиотек и тщательно проверяйте обновления, если вы можете себе это позволить».
В двух словах, как работает Passport.
Вы локально с помощью пароля шифруете свои персональные данные (имя, email, скан паспорта, другие документы).
Зашифрованные данные + метаинформация загружаются в облако Telegram.
Когда нужно авторизоваться на сервисе, клиент скачивает данные из облака, расшифровывает их паролем, перешифровывает на публичный ключ того сервиса, который запросил информацию, и отправляет.
а в чем разница с просто зашифровать публичным ключем того сервиса, который запросил информацию и отправить :)?
Например схема «зашифровать своим публичным ключем и разместить в dropbox, google drive etc., а потом скачать данные из облака и перешифровать» кажеться несколько более разумной.
И самый главный вопрос: как это все помогает идентифицировать пользователя?
Что мешает послать «сервису который запросил» данные и паспорт совсем не те которые загружены в телеграм?
Да и использование номера телефона как uid так себе идея, не очень анонимно. Но мне в принципе эта идея и тенденция не очень нравится.
Это пока там только паспортные данные. Потом, если система взлетит и станет популярной, ничто не мешает расширить функционал и типы хранимых данных (кредитки, ключи и т. д.). "А почему бы и нет, система ведь надёжная, вон сколько народу пользуется и не опубликовано было взломов". А это уже далеко не безобидные паспортные данные. Полагаться на авось не стоит, даже когда данные не особо важные по вашему мнению. Есть уже давно проверенные алгоритмы шифрования с высокой криптостойкостью. Не нужно городить велосипед, чья криптостойкость ничем и никем не подтверждена. Ни к чему хорошему это, как правило, не приводит.
Не агитирую, каждый действует на свое усмотрение. Не надо только потом громко кричать, что кто-то куда-то слил ваши персональные данные.
«Буратино, ты сам себе враг» (с) Базилио
Возможно, пользователям будет выдаваться пароль, как, например, в леджер нано. Или любом другом криптокошельке. И тогда это будет мнемоник или длинный приватный ключ.
Support for Telegram Passport 1.1 and improved password hashing algorithm to better protect Telegram Passport data.
Я это всё к чему: при оценке времени на честный брутфорс 2^128 комбинаций для 16-символьного пароля (на самом деле, там меньше значений, т.к. в пароле у нас только читаемые текстовые символы, то есть там будет около 2^112) я даже не закладывал время на подсчёт MD5 (хотя оно довольно ощутимо, хоть функция и очень нетребовательная по меркам аналогов), а просто считал время проверки одной комбинации как несколько тактов (в любом случае, необходимы копирования значений и проверки символов в строках, даже если у нас все данные в регистрах процессора и нам не надо терять такты, ожидая более медленную RAM). Но я подсчитывал исходя из условия, что у нас одно- или максимум двухъядерный процессор с частотой не более 3 GHz.
В итоге у меня получилось несколько сотен, кажется, триллионов лет, что меня более чем удовлетворило.
Вопрос — справедливо ли то, что вы требуете от авторов схемы шифрования невозможность расшифровки на GPU? Да, нельзя гарантировать, что злоумышленник не умеет использовать GPU для взлома, также неизвестны его денежные ресурсы (сколько GPU он может купить). И всё-таки? GPU вообще создавался для несколько других операций, он не очень заточен под базовые стандартные вычисления. Кроме того, в какой-то из статей я видел упоминание, что лучший выигрыш, на который можно рассчитывать от применения GPU — это два порядка, то есть в сотню раз. Что всё ещё мало для полного перебора всех комбинаций.
Вы же утверждаете, что в указанной ситуации данные можно получить примерно за 8 дней (ок, допустим за 10-15 дней, если брать с запасом). На основе чего это утверждается? Приведите, пожалуйста, хотя бы примерное число комбинаций с учётом «неслучайностей», о которых вы писали, а также скорость перебора на GPU в паролях в секунду, желательно ещё и с указанием конкретных моделей устройств и их стоимости. Можно не производя конкретный тест, а исходя из общедоступных данных, наверняка люди уже проводили тесты на эту тему.
Потому что пока в такую «дырявость» мне верится с трудом… Всё-таки там не полные дураки сидят.
Почему Telegram Passport — никакой не End to End