Comments 59
Спасибо, хорошая статья! Можно еще добавить, что web crypto доступен и в принципе рекомендован к использованию в воркерах, чтобы не замедлять ui во время работы с криптографией. На маленьких сообщениях это незаметно, а вот при работе с большими файлами там другая история.
Он и так в отдельном потоке исполняется, потому функции и асинхронные.
Пул потоков-то ограничен. В реальности у вас ui будет из-за subtle стоять в очереди, если не вынести в воркер
Вы бы проверили сперва, прежде чем так уверенно говорить про реальность.
У меня в приложении ui по 3 секунды висел из-за сложного pbkdf. Я научен)
Видимо вы в рендерере влепили await, из-за чего он остановился в ожидании ответа от крипто-треда. И не разобравшись подумали, что криптография исполняется в ui-треде.
Как я уже сказал, пул потоков ограничен. Почитайте что-нибудь по теме, почему криптографию выносят в воркеры
Давайте уже свои ссылки по теме, не томите общественность.
Тут я с вами соглашусь пул потоков действительно ограничен. В идеале всю тяжёлую логику стоит перенести в веб воркеры, чтобы основной поток был занят только обработкой пользовательского ввода, включая клики. Это особенно заметно на бюджетных мобильных устройствах за $100, где часто наблюдаются микролаги и прочие задержки. Воркеры могут помочь с этой проблемой.
Что касается WebCrypto, он выполняется вне основного потока и никак на него не влияет. Таким образом, если вернуться к теме статьи, шифрование и дешифрование именно сообщений обходится недорого даже для слабых устройств.
Я писал больше про тяжелые и долгие операции, которые специально замедленны, вроде pbkdf. Расшифровка/шифрование, когда необходимости в усложнении нет, т.к. токены итак затруднительно подобрать, даже при большом объеме данных не должны вызывать проблем. Максимум подготовка данных, но это на совсем слабых устройствах
Привет HabrGPT, перепиши код с промисов на асинхронные функции, вынеси функции работы с base64 в отдельный неймспейс, используй base64url кодирование, для генерации общего ключа используй функцию sharedKey, в качестве вектора инициализации используй хеш от сообщения и публичного ключа, для импорта/экспорта используй формат JWK.
Что за HabrGPT?
Не sharedKey, а deriveKey, конечно же.
Не deriveKey а deriveBits в рамках класса который в статье
Вот в рамках конкретно этого класса должен быть именно deriveKey. В отличие от $mol_crypto_sacred, который является обёрткой над буфером, а не нативным ключом.
скажите, возможно ли шифрование голоса во время звонка на кнопрочных телефонах J2ME причем не через сервер а точка - точка ?
Вы от него ещё и реал-тайм хотите? Скорее можно сказать фразу и долго-долго ждать, после того как притащите туда хоть какой-то современный кодек который по крайней мере уменьшит количество байт на зашифровку. Во время звонка я не уверен что можно с ж2ме пользоваться звуковым потоком.
ответ Алисы:
Нет, шифрование голоса на Java не сопровождается сильной задержкой. stackoverflow.comvk.com
Для реализации шифрования голосовых данных в Java используются библиотеки, которые обеспечивают быструю работу, например, класс
Cipherс алгоритмом AES. Задержка в процессе шифрования не превышает нескольких миллисекунд. sky.provk.comstackoverflow.comvk.com
Это достигается за счёт оптимизации алгоритмов и использования современных методов, таких как режим CBC (Cipher Block Chaining), который позволяет обрабатывать данные частями.
Главные шпионы в наше время - это устройства, на которых всё это замечательное «шифрование» происходит. Там и ОС закрытая, и постоянная неотключаемая связь с настоящим хозяином, и пароли все эти ваши. А так - ну, можно и пошифровать, батарейку и проц разогреть.
А как пользователи-то ключами управляют? Например, передать публичный через сервер — ещё куда ни шло, а вот приватный после логина в приложение откуда берётся на устройстве, чтобы расшифровать все сообщения, отправленные, пока ты офлайн был?
Его сохранять надо в памяти после логина на клиенте и не сохранять в бд или где то если по честному делать
Обратите внимание, что приватный ключ дополнительно шифруется. В качестве примера его можно зашифровать паролем пользователя при регистрации аккаунта или любым другим ключевым словом, известным только вам. После шифрования приватный ключ сохраняется в базе данных. При авторизации клиенту передаётся только зашифрованный приватный ключ, который он расшифровывает с помощью пароля, введённого при авторизации. Затем ключ сохраняется на устройстве пользователя до окончания сессии авторизации. Но если пользователь забудет свой пароль от своей учетной записи, возникает проблема он больше не сможет расшифровать свои старые сообщения.
т.е. если у меня два устройства - то зашифрованный приватный ключ проходит через сервер. если расшифровывать с помощью пароля, то при смене/восстановлении пароля расшифровка невозможна. какие еще варианты сохранения безопасности приватного ключа?
Да, всё верно если пароль утерян, восстановить сообщения уже не получится. Но это лишь один из возможных сценариев. Приватный ключ можно шифровать не только паролем пользователя, но и другими ключевыми словами. Например, это могут быть recovery codes, которые система случайным образом генерирует и затем использует для шифрования приватного ключа.
Допустим, сгенерировано 6 recovery codes тогда система создаёт 6 зашифрованных копий приватного ключа, каждая из которых связана с одним из этих кодов. Эти копии необходимо дополнительно хранить, например, в базе данных. При смене пароля пользователю стоит предлагать восстановить сообщения с помощью recovery codes и заранее обратить внимание на важность их сохранения ...
С тем же успехом можно и приватный ключ в открытом виде где-то "важно сохранять".
Смысл тогда заниматься шифрованием сообщений если приватные ключи где то будут храниться в открытом виде? Это будет не справедливо по отношению к пользователям которые будут думать что их сообщения шифруются енд ту енд. Если приватные ключи будут храниться в открытом виде значит кто то будет иметь возможность расшифровать любые сообщения вопрос возникает тогда кто? Админ, владелец хостинга, хакер, сотрудник который по ошибке слил базу и т д?
Приватный генерируется в моменте и удаляется после закрития сессии. Хранить надо только личные ключи, и глубоко хранить! Остальное - публичный пофиг, показывйте уому угодно, а тот приватный (не личный, а который гннериузв моменте начала сесиии, так вот тот ключ, хранится времено в памяти у обоих собеседников
После прочтения Асимметричное шифрование и ECDH магия осталась магией из-за пропущенного процесса вычисления общего секретного ключа. Потому что
Голову можно ломать долго и безрезультатно, пока не поймем, что такое асимметричное шифрование и протоколы обмена ключами.
Если не погружаться в самые дебри, то:
У Алисы есть приватный ключ (a) и публичный ключа (A). Публичный ключ высчитывается из приватного ключа A = a x G
У Боба так же приватный (b) и публичный (B = b x G)
G – это базовая точка на эллиптической кривой, общая для всех. Алиса и Боб заранее договорились какую кривую будут использовать. За нас уже всё посчитано, точка описана в стандарте, просто берем её оттуда.
Алиса и Боб обменялись публичными ключами и каждый из них умножает свой приватный ключ на публичный ключ собеседника:
Алиса: a x B => a x (b x G) = ab x G
Боб: b x A => b x (a x G) = ba x G => ab x G
Вот и вся "магия" получения общего секретного ключа
Это можно как то протестировать? Если честно ничего не понял)
более простого объяснения не знаю
from math import gcd
from sympy import primefactors
def is_primitive_root(g, p):
if gcd(g, p) != 1:
return False
order = p - 1
for q in primefactors(order):
if pow(g, order // q, p) == 1:
return False
return True
def min_primitive_root(p):
for g in range(2, p):
if is_primitive_root(g, p):
return g
if __name__ == '__main__':
sess_const = 23 # Большое простое число (в реальности 2048+ бит)
pr = min_primitive_root(sess_const) # Первообразный корень по модулю sess_const
a = 6 # Секретный ключ Алисы
A = pow(pr, a, sess_const) # Публичный ключ Алисы (отправляется Бобу).
b = 15 # Секретный ключ Боба
B = pow(pr, b, sess_const) # Публичный ключ Боба (отправляется Алисе)
K_alice = pow(B, a, sess_const)
K_bob = pow(A, b, sess_const)
print(f"Публичные параметры: p = {sess_const}, g = {pr}")
print(f"Алиса: приватный a = {a}, публичный A = {A}")
print(f"Боб: приватный b = {b}, публичный B = {B}")
print(f"Общий секретный ключ у Алисы: {K_alice}")
print(f"Общий секретный ключ у Боба: {K_bob}")
Здесь есть подробное объяснение как это работает, но без подготовки это скорее всего не осилить.
Тут можно закончить словами автора: Всё, что вам нужно понять на данном этапе, – это то, что технология работает
sess_const = 23
Почему именно 23? Одно из любимых простых чисел, просто интересно 🙂
я вообще ржу по доброму.. такое ощущение, что школьников пустили в чат (я по доброму), и они нам делают голову)))
В статье четко описано все. В комментариях уже триста раз еще проще объяснили, но они не втыкают — полагаю, очень молодые математики ворвались в чат…
Сама по себе идея обмена ключами проста для понимания, вплоть до очевидности, но автор, видимо намеренно, избрал для статьи исключительно трудный для понимания стиль, вероятно, в целях придания своему банальному тексту большей значимости, попутно расставляя тут и там дополнительные триггеры включения фокуса на поиск мнимой сложности для отвлечения внимания от целостного восприятия простой концепции. А может быть автор просто воспроизводит свои собственные слабые способности восприятия новых концепций, демонстрируя при этом хорошо отточенный навык демагогически превращать простое в сложное.
Ну конечно, загнали школьников на Хабр, и обвиняют автора… в школе учите основам.
конечно я понимаю, что школьникам интересно почитать взрослый сайт и интересные им темы, но прежде чем понять тройной интеграл, узнай основы дифферциального исчисления… ну я в узком смыле привел пример. Ну вы поняли. Им азбуку бы понять, понять как саму информацию воспринимать, но этому учат уже в старших классах и институтах.
Ой ладно
Спасибо за статью.
Делаем библиотеку для интерфесов для чатов на vue (https://github.com/mobilon-dev/chotto). Чтобы лучше показать как работает - делаем демки https://mobilon-dev.github.io/chotto-demo/ надо в одну из демок сделать пример с криптографией 👍
Насколько помню, классическое объяснение обмена ключами выглядит так: Алиса кладёт ключ от замка в посылку, вешает на посылку замок, отправляет Бобу. Получив посылку, Боб вешает на неё свой замок. И отправляет обратно. Теперь Алиса открывает свой замок и, в свою очередь, отправляет посылку Бобу. Так тот получает один ключ. Потом всё повторяет со стороны Боба и вот у них произошёл обмен ключами.
Фатальный недостаток: вы не знаете, с кем вы хендшейкаетесь, если до этого не обменялись ключом по доверенному каналу
От души Бро! Касательно твой проект ... Можно скачать на Android?
Проще поднять за пару мин Matrix+element LE TLS+E2E olm+megolm включён по умолчанию;)
Всё это шляпа... если гос органу надо посмотреть то дадут посмотреть чат )
Хорошая статья, спасибо! Я так понимаю, писал в первую очередь для себя, чтобы поглубже разобраться в вопросе? 😊
В вопросе я разобрался полностью. Статью накидал скажем так, это основа основ, чтобы те, кто вообще не в курсе, как работает end-to-end шифрование, могли получить хотя бы общее представление о том, как оно реализуется. По хорошему, стоило бы написать вторую часть статьи о том, как генерируются приватные и публичные ключи, потому что были предложения на пайтоне и описание концепции в комментарии выше, а также о методах их хранения, но это уже дело фантазии каждого. В моём проекте, например, создание приватного и публичного ключей происходит на бэкенде, написанном на Golang, там же оно и шифруется паролем пользователя, кто то может реализовать это и на устройстве клиента используя только js ...
Как мессенджеры шифруют сообщения (end-to-end) на самом деле