О технической возможности получения ключей шифрования.

Аватар пользователя v.p.

я повторюсь, просто в силу того, что слишком много комментариев от выпускников заочного отделения заборостроительного института им. Балетного-Копытного на тему "технической невозможности предоставить ключи шифрования":

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

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

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

на компьютерах с массового рынка, к сведению, вообще не существует механизма хранения ключей который бы гарантировал невозможность для приложения получить ключ в его исходном виде при наличии пароля пользователя к виртуальному хранилищу ключей. на мобильных терминалах есть специальные области хранения оных (области в SIM, SD-Card, область спецпамяти устройства) выделенные для каждого приложения которое авторизовалось на использование этого функционала,  но и там есть в наличии встроенные механизмы управления жизненным циклом ключа, включая если и не возможности прямого чтения ключей, то их замены с чтением "старого ключа" и перекодирования с использованием "нового". на данный момент, насколько мне известно, все мобильные терминалы так или иначе позволяют приложению прямое чтение своих ключей из этих областей. для интересующихся см. https://www.globalplatform.org/specifications.asp

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

единственным классом устройств, где подобную уязвимость пытаются как-то обойти являются т.н. HSM, но и там наличие чисто технических решений признано недостаточным, и потому вводятся дополнительные организационные мероприятия при передаче мастер-ключей, как-то курьерская служба с т.н. key custodians, которые получают на руки некий набор символов, с прибытием на место каждый из них вводит свой набор в спецкомнате без свидетелей, машина затем из этих трёх или более наборов реконструирует мастер-ключ для означенной области и всё, можно работать. никакими способами ключи из этой машины не вынуть, они её никогда не покидают, по запросу к ней она вам всё что нужно зашифрует-расшифрует сама с указанным номером ключа, но ключа никто не увидит. при потере пароля доступа к машине - только factory reset и только специалистами производителя. кстати, ассиметричные алгоритмы как таковые в финсекторе, мобильной связи и промышленности (там, где используют HSM) крайне непопулярны насколько я могу судить по собственному опыту, единственное их адекватное приложение которое я наблюдаю - public-facing frontend, а всё остальное на симметрике.

ну собственно вкратце и упрощённо картинка именно такова. всё можно, все средства есть в наличии, а если и нет, то реализовать их ну ни разу не проблема. Дуров - дурит народ, как и броцуны за свободу инторентофф.

 

ранее указанную возможность просто встроить функционал требуемый ФСБ относительно чат-логов в приложение хотя-бы для рынка РФ тут даже не рассматриваем, ибо и так ясно.

 

если заметили ошибки и/или опечатки - укажите, буду благодарен.

 

Авторство: 
Авторская работа / переводика
Комментарий автора: 

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

Комментарии

Аватар пользователя woddy
woddy(11 лет 2 месяца)

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

публично передается только закрывающий ключ. открывающий есть только у тебя. подобрать открывающий ключ - 100 лет надо.

это актуально для закрытых чатов, которые нигде не хранятся.

после расшифровки - ключи удаляются. если даже СОРМ сохранил переписку, расшифровать ниче не сможете

Комментарий администрации:  
*** Неполживого чма кусок ***
Аватар пользователя v.p.
v.p.(11 лет 6 месяцев)

три вопроса:

1. ты меня зобанел. что ты делаешь в моём блоге?

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

3. ты так и не увидел описание процесса работы приложения с использованием ассиметрично-симметричниго шифрования, а я ведь об этом писал.

Аватар пользователя woddy
woddy(11 лет 2 месяца)

разбанил

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

почему? что в этом плохого?

Комментарий администрации:  
*** Неполживого чма кусок ***
Аватар пользователя Omni
Omni(11 лет 6 месяцев)

Дюже дорого по процу, хотя для чата без картинок может и хватит.

Аватар пользователя v.p.
v.p.(11 лет 6 месяцев)

собственно параметров для сравнения несколько, тем более алгоритмы различны принципиально, но если тупо померить в лоб, то вот (RSA 2048 vs AES 128, сходная криптостойкость):

Off the top of my head:

  • One raw RSA message can be at most as long as the modulus.
  • One cooked RSA message needs padding to be secure. RSA PKCS#1.5 padding needs (at least) 11 bytes of padding.

And I'm going to assume rsa2048. 2048 bits is 256 bytes raw. Minus 11 for the padding gives 245 byte usable.

The CryptoPP site gives:

  • RSA 2048 Signature 6.05 milliseconds/operation
  • RSA 2048 Verification 0.16 milliseconds/operation

Calculation

  • RSA 2048 Signature 6.05 milliseconds/operation

    • (1000 ms/s) / (6.08 ms/op) == 164.47 op/s
    • 164.47 op/s * 245 byte/op == 40,296 byte/s
  • RSA 2048 Verification 0.16 milliseconds/operation

    • (1000 ms/s) / (0.16 ms/op) == 6,250 op/s
    • 6250 op/s * 245 byte/op == 1,531,250 byte/s

So: About a 1.5 MByte/s for verify (/encrypt). And 40kByte/s for sign (/decrypt).

And for "AES/CTR (128 bit key)" the CryptoPP table lists about 100 MiB/s.

 

потребление процессорных циклов принимаем максимально доступным на тестовой платформе, память и прочее достаточным в смысле отсутствия влияния на результат. в условия сравнения в реальных задачах на embedded платформах асимметрику порой даже невозможно адекватно реализовать. данные отсюда ( https://security.stackexchange.com/questions/57493/asymmetric-vs-symmetr... ), но подобных сравнений в инторнетах - тысячи.

Аватар пользователя orioncrew
orioncrew(9 лет 2 месяца)

Асимметрией шифруют не трафик, а договорной ключик симметрии:
 

Видео:

Страничка с этим видео в курсе по компьютерной безопасности: https://ulearn.me/Course/Hackerdom/Zaklyuchitel_nye_polozheniya_85fc6105...

Кстати, всем рекомендую послушать этот курс для общего развития.

Аватар пользователя Omni
Omni(11 лет 6 месяцев)

Исполнение школотой, ужас.

Аватар пользователя gridd
gridd(7 лет 9 месяцев)

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

Понятие "цифровой конверт"  существует уже лет 40:

Генерируется асимметричный ключ (секретный + публичный) им шифруется обмен симметричными ключами. А дальше всё шифруется симметричными ключами. DES, ГОСТ. Ничего нового. Все так делают. Ресурсов больших не требуется.

Аватар пользователя v.p.
v.p.(11 лет 6 месяцев)

спасибо  КО. :-)

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

Аватар пользователя Бегемот
Бегемот(8 лет 4 месяца)

Тут бесполезно это объяснять 

Аватар пользователя vitalium
vitalium(8 лет 7 месяцев)

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

Аватар пользователя Бегемот
Бегемот(8 лет 4 месяца)

Полегче, я что-то говорил по поводу использования асимметричного шифрования с генерацией ключей на стороне клиентов в чате со множеством участников? Оно используется в так называемых "секретных чатах 1 на 1".

 

 

Аватар пользователя vitalium
vitalium(8 лет 7 месяцев)

Назвать это чатом у меня язык не повернётся. Ну да ладно.

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

Аватар пользователя Бегемот
Бегемот(8 лет 4 месяца)

Назвать это чатом у меня язык не повернётся. Ну да ладно.

Почему? Субъективно неудобный? Кому как, на вкус и цвет фломастеры разные.

 

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

В Википедии  описан алгоритм, который используется в мессенджере (для т.н. "секретного чата"), согласно которому закрытые ключи никуда не передаются, клиенты обмениваются только открытыми. Свой секретный ключ хранится только у каждого из клиентов.

 

 

Аватар пользователя vitalium
vitalium(8 лет 7 месяцев)

Олд скул: чат с двумя участниками - не чат. 

Я и без вики знаю что такое ассиметричное шифрование и зачем надо обмениваться открытыми ключами. Дело-то не в этом.

Программа-клиент имеет доступ к закрытому ключу. Она не может его не иметь, а значит может и передать третьей стороне. Просто при асинхронном шифровании, для расшифровки переписки абонента N, нужен не только его закрытый ключ (что ему пишут), но и закрытые ключи всех его адресатов (что он пишет). Собрать эти ключи - чисто процедурный вопрос.

Аватар пользователя Бегемот
Бегемот(8 лет 4 месяца)

Ну так клиент опенсорсный, скомпилируйте свою версию, которая точно никуда не будет его передавать. В чём проблема?

Аватар пользователя vitalium
vitalium(8 лет 7 месяцев)

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

Аватар пользователя Бегемот
Бегемот(8 лет 4 месяца)

А, ну так сделайте свой мессенджер, который будет так делать. Удачи вам набрать пользователей.

 

Аватар пользователя vitalium
vitalium(8 лет 7 месяцев)

Dura lex, sed lex. Как бы кому этого не хотелось.

Аватар пользователя codeGray
codeGray(8 лет 5 месяцев)

Ну так чегоя тогда на АШ бузят против международных законов ? Нехотят их выполнять мол вражеские они ? Или тут играем а тут не играем а тут рыбу заворачивали ?

Комментарий администрации:  
*** Уличен в манипуляциях ***
Аватар пользователя vitalium
vitalium(8 лет 7 месяцев)

Против каких-таких "международных законов" на АШ "бузят"? Впрочем, не важно. Во-первых, "международные законы" приобретают силу только после их ратификации конкретной страной. Во-вторых, пожалуйста различайте словесную "бузу" против законов и отказ от их выполнения.

Аватар пользователя codeGray
codeGray(8 лет 5 месяцев)

В данном случае мы обсуждаем именно намерения. Надо или не надо следовать законам которые не нравятся. А среди таковых имеются ряд  международных которые на АШ гиперпатриотам не нравятся и они призывают их не исполнять. Верховенство же международного права прописано в Ельцинской конституции если вы не знали . Да что там даже собственная конституция попираемая подзаконными актами у них не в чести. Об этом я и веду речь .

Кстати о фактическом исполнении - здесь тоже нюансы. Сначала так и было - не исполняли решения международных судов . Потом Верховный суд таки сел и узаконил это. И теперь в одном месте конституции написано мерховенство международного права а по решению Верховного суда если очень хочется можно делать по национальному праву.

 

Комментарий администрации:  
*** Уличен в манипуляциях ***
Аватар пользователя vitalium
vitalium(8 лет 7 месяцев)

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

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

Аватар пользователя monk
monk(12 лет 1 месяц)

Именно цитируя эти аргументы следующим шагом потребуют доступа для ФСБ от производителей ОС и железа. А тем, кто не согласен, запретят продавать на территории РФ

Аватар пользователя rukav
rukav(7 лет 9 месяцев)

Пострашнее иллюстраций не нашлось?

Кстати, а дядя Сэм в этом деле белый и пушистый?

Инструментарий АНБ и ЦРУ

Аватар пользователя monk
monk(12 лет 1 месяц)

Дядя Сэм этот этап «производителей ОС и железа» уже прошёл. Именно поэтому Google активно продвигает шифрование на весь трафик (https, ssl). Американцам это не мешает (у них контроль на оконечных точках), а их конкурентам жизнь осложняет.

А наличие добровольных аудиожучков (известных как мобильные телефоны) почти у каждого жителя Земли позволяет знать даже то, чего нет в Интернете.

Аватар пользователя v.p.
v.p.(11 лет 6 месяцев)

уже требуют, и давно, сертификация ФСБ обязательна в РФ для промышленных криптоустройств, ещё в 2007 году уже занимался таким.

Аватар пользователя Assert
Assert(8 лет 4 месяца)

>как таковые в финсекторе

Все чиповые карточки (а других уже и нету наверное) авторизуются через RSA. Это стандарт EMV. Да и в других местах ассиметричное шифрование активно используется.

Аватар пользователя v.p.
v.p.(11 лет 6 месяцев)

да, технически ты прав, спасибо, я всё про потоковый траффик. а так, да, авторизация и аутентификация между картой и банкоматом. ну формально, кстати, банкомат это тоже public frontend.

 

https://cdn2.hubspot.net/hubfs/531679/Documents/White_Papers/Cryptomathi...

Аватар пользователя rukav
rukav(7 лет 9 месяцев)

подобрать открывающий ключ - 100 лет надо

Если пользоваться бытовыми вычислениями, то да, может и больше потребуется. А вот если брать квантовые вычисления, то с их помощью очень быстро можно подобрать ключи.

Аватар пользователя roman.kuvaldin
roman.kuvaldin(12 лет 3 месяца)

Нельзя. В лучшем случае удастся сократить сложность алгоритма на одну степень, и то при наличии достаточного количества кубитов.

Для РСА надо 2048.

Самый большой квантовый компьютер сейчас держит по моему 51 кубит. Dwave не годится, судя по производительности, там параллельно работа@т несколько восьмикубитных процессоров, что не дает всех возможностей.

Аватар пользователя rukav
rukav(7 лет 9 месяцев)

Э нет, большинство традиционных алгоритмов (RSA, DSA, ECDSA) неустойчивы к квантовым атакам.

Уже создана такая тема как постквантовая криптография, которая занимается разработкой алгоритмов, которые бы не зависили от роста квантовых вычислений.

Для РСА надо 2048.

Не спасет через лет 10-15.

Аватар пользователя gridd
gridd(7 лет 9 месяцев)

а теперь представьте как биткойн-фермы по всему миру подбирают китайцам хэши для брутфорса... биткойн - это шляпа для прикрытия. А хэши там генерятся - 15 Терахэшей в секунду. А устройств этих по миру стоят миллионы.

Аватар пользователя roman.kuvaldin
roman.kuvaldin(12 лет 3 месяца)

Только там хэши не те.

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

Аватар пользователя sfw
sfw(6 лет 2 недели)

публично передается только закрывающий ключ. открывающий есть только у тебя. подобрать открывающий ключ - 100 лет надо.

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

вот было бы оно п2п + меш - другое дело. Но тогда бы оно не взлетело. Ring.cx - живой пример :)

 

 

Аватар пользователя v.p.
v.p.(11 лет 6 месяцев)

алгоритмы не сильно важны, важен факт наличия "безопасного" хранилища ключей. HSM для паблик p2p full mesh сервиса делать - никаких денег не хватит, да и если оно ляжет, то потеряется не только текущий функционал, но и вся история.

Аватар пользователя Assert
Assert(8 лет 4 месяца)

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

Аватар пользователя HarkAlAda
HarkAlAda(8 лет 7 месяцев)

Ну, с этим всё просто: нужно только всегда находиться посередине, между корреспондентами:

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

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

Аватар пользователя Assert
Assert(8 лет 4 месяца)

А для таких вещей есть подписи.

Аватар пользователя sfw
sfw(6 лет 2 недели)

А для таких вещей есть подписи.

Ога. мало того, что ключи на каждый чих генерить, так еще и в уц жить практически :)

Аватар пользователя HarkAlAda
HarkAlAda(8 лет 7 месяцев)

Чтоб верифицировать подпись на сообщении, нужно как-то ключ для нее передать. Так или иначе, пока все передается через негодяя (пусть даже самого честного и заслуживающего абсолютного доверия) - нет ничего невозможного. Нужно как-то диверсифицировать каналы передачи. Например, передать корреспонденту ключ для подписи при личной встрече.

Аватар пользователя Maxim
Maxim(8 лет 3 месяца)

В Тор с этим так борятся.  У тебя там есть странный такой адрес из 16 букв если правильно помнью. Как-то правильно передать надо только этот адрес.  Если этот адрес правильно набираешь, все.  Свяжешся, тебе передают открытый ключ.  А сам адрес - hash от этого открытого ключа, то есть однозначно вычисляется из этого открытого ключа.  И значит по дороге заменить его другим нельзя - ключ не подходит к этому адресу.  

 

Аватар пользователя голос из Пустоты

подобрать открывающий ключ - 100 лет надо

Один нюанс, если этот алгоритм или приложение не имеет бэкдоров или в нем ЕЩЕ НЕ НАЙДЕНЫ дыры. На моей памяти из непробиваемых только трукрипт (но аудит его когда, произведенный на народные деньги, оставил больше вопросов, а сама прога вроде как больше не поддерживается, и ее разработчик неизвестен). В 2013-2014 годах об этом много писали. Конечно, может быть есть менее известные, но мне об этом неизвестно, хотя я и не слежу за этим всем.

Но любые непробиваемые алгоритмы и реализации теряют всякий смысл, когда речь заходит о среде их исполнения - это насквозь дырявые и перезапроданные писюки, ондроеды и огрызки.

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

Аватар пользователя Vladislav IV
Vladislav IV(7 лет 11 месяцев)

Емнип, в трукрипт по результатам "аудита" добавили бэкдор, о чём разработчик предупредил пользователей.

Последний "недырявый" Трукрипт - версии 7.1а

Аватар пользователя голос из Пустоты

Да, что-то такое припоминаю. Но там вся история с трукриптом мутная. Взять хотя бы то, что сборка из сырцов дает результат, отличный от выложенного.

Аватар пользователя xtotec
xtotec(7 лет 5 месяцев)

трукрипт стал теперь веракриптом, вроде совсем недавно ещё раз его проаудитили...

Аватар пользователя vlad02
vlad02(8 лет 4 месяца)

Продолжение форк VeraCript а шифровал он aes? блюфишем и чем то еще стандартным, даже гост вроде отсутствовал. И вообще truecript это не шифр а реализация, такая же как pdp

Аватар пользователя laplat
laplat(11 лет 10 месяцев)

А тем временем -2500000 адресов из адресного пространства. Проблемы с Амазон, Вайбер, Ютуб и неизвестно сколько ещё чего и где ляжет.

Борьба с телеграммом такая борьба. 

Аватар пользователя просто пользователь

Зачем РКН бегать за мессенжером? 

Пусть за ним бегают Амазон, Вайбер, Ютуб и прочие. А если будут предоставлять свои сервера(IP) для Дурова, то разделят с ним его судьбу.

Аватар пользователя голос из Пустоты

Эти гаврики, я об амазонах и проч., суть торгаши, и их в этом плане легко просчитать. Они все измеряют в бабках. Если они посчитают, что потери в бабках будут больше дохода, получаемого от Впаши, то легко выкинут Впашу. В связи с этим, надо очень осторожно примерять опыт Китая — все-таки размеры наших рынков сильно различаются. Правда тут надо учитывать, что, если пиндосня надавит на впашиных хостеров, то могут и на принцип пойти.

Страницы