БГ
Падажжи, секунду, ты про какой ключ говоришь?
Size: a a a
2021 November 02
PZ
А они что, принципиально по разному будут храниться? Ключ шифрования для расшифровки сообщений с сервера и от респондентов методологически должны быть очень похожи.
БГ
Мне кажется мы о разных штуках говорим
БГ
Или я туплю с утра пораньше)
PZ
Мы говорим о двух разных параллельных вещах:
1) Синхронизация сообщений через сервер зашифрованным дампом.
2) Шифрование сообщений, доставляемых через сервер, открытым ключом в адрес получателя.
В чём нюанс (который мне казался столь очевидным, что я не стал его проговаривать): ключи для расшифровки этих двух видов данных ведут себя одинаково - одинаково хранятся, одинаково часто нужны. Соответственно если мы считаем п.1 защищённым от компрометации, то мы можем считать и п.2 защищённым от компрометации и храповик не нужен. Если мы считаем п.2 уязвимым, то надо считать и п.1 уязвимым.
1) Синхронизация сообщений через сервер зашифрованным дампом.
2) Шифрование сообщений, доставляемых через сервер, открытым ключом в адрес получателя.
В чём нюанс (который мне казался столь очевидным, что я не стал его проговаривать): ключи для расшифровки этих двух видов данных ведут себя одинаково - одинаково хранятся, одинаково часто нужны. Соответственно если мы считаем п.1 защищённым от компрометации, то мы можем считать и п.2 защищённым от компрометации и храповик не нужен. Если мы считаем п.2 уязвимым, то надо считать и п.1 уязвимым.
БГ
В случае 2 ключ юзера постоянный, так?
PZ
Также как в случае 1 :) Иначе не получится синхронизировать через оффлайн...
БГ
При утечке этого ключа тот кому он утёк может читать как минимум входящие сообщения жертвы
А это не есть хорошо
А это не есть хорошо
БГ
forward и backward secrecy же
одна из основных фич храповиков
одна из основных фич храповиков
PZ
Да, конечно. Вопрос в том, насколько вероятным мы считаем его утечку.
И тогда вопрос в том, что в п.1 мы не можем полагаться на то, что шифрование надёжно, как ты полагаешь тут https://t.me/distributed/224869 а должны рассчитывать на утечку.
И тогда вопрос в том, что в п.1 мы не можем полагаться на то, что шифрование надёжно, как ты полагаешь тут https://t.me/distributed/224869 а должны рассчитывать на утечку.
БГ
В случае с использованием храповиков утечка ключей гораздо менее критична
Можно даже позволить другим расшифровывать отдельные сообщения, выдавая от них ключи)
Можно даже позволить другим расшифровывать отдельные сообщения, выдавая от них ключи)
PZ
ДА! Но никакого храповика в чистом оффлайне с самим собой (ты даже не знаешь с кем из 3х) ты использовать не можешь.
И при синхронизации через сервер у тебя постоянный ключ и угроза его компрометации.
И при синхронизации через сервер у тебя постоянный ключ и угроза его компрометации.
БГ
В чистом оффлайне он всё равно работает
БГ
Ща статейку скину, там поясняются эти моменты
БГ
Тут собственно поясняется, плюс фоном делается имплементтация этих самых храповиков
https://nfil.dev/coding/encryption/python/double-ratchet-example/
https://nfil.dev/coding/encryption/python/double-ratchet-example/
БГ
И, в частности, то как начать сеанс при оффлайне собеседника так же рассмотрено
PZ
Это работает при СО-беседнике.
Это не работает чтобы зашифровать дамп, который должен быть расшифрован кем-то из 3 получаетелей (ты не знаешь кем).
Это не работает чтобы зашифровать дамп, который должен быть расшифрован кем-то из 3 получаетелей (ты не знаешь кем).
БГ
В чём проблема оставить дамп шифрованным теми ключами храповиков которыми он шифровался когда сообщения были отправлены?
PZ
В том, что тебе надо как-то передать эти ключи за время оффлайна других нод.
БГ
Подробнее, туплю