Двач.hk не отвечает.
Вы видите копию треда, сохраненную 22 апреля 2021 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Вы видите копию треда, сохраненную 22 апреля 2021 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
71 Кб, 850x423Перефразированный репост отсюда: https://2ch.hk/pr/res/1651996.html#1656894 (
М)
Задача.
Условие: Есть сервер, отвечающий на запрос клиента - данными,
и есть клиент с браузером, загружающий данные, после запроса на сервер.
Проблема: данные, по пути их даставки (особенно по открытому каналу),
могут быть перехвачены - в результате MITM-атаки.
Вопрос: возможно ли как-то исключить возможность подмены данных?
Первое, что приходит в голову - это передать данные,
вычислить и них, и дать возможность клиенту сравнить этот хэш с хэшем данных на сервере.
Однако, и сам хэш может быть подменён в результате MITM-атаки.
Поэтому, можно было бы предварительно вычислить хэш строки, и опубликовать его так,
чтобы он был известен клиенту - ещё до запроса от него.
Но и в этом случае MITM-атакер может подменить хэш на свой.
Какие ещё могут быть варианты?
__________________________________
Ранее, анон >>1656896 → предлагал использовать Pre-Shared public key, и приватным ключём - подписывать данные,
а затем проверять цифровую подпись на клиенте.
Проблема в том, что исходный код сервера может быть открыт, и MITM-атакер может полностью заменить сервер.
__________________________________
Этот анон: >>1657795 → предложил использовать OTP-пароли (одноразовые пароли)
с доставкой их по совершенно-другому каналу связи.
Проблема в том, что канал связи один, и он ещё и открыт.
__________________________________
Как вариант, можно было бы использовать Gauth: https://gauth.apps.gbraad.nl/#add
но я чё-то не пойму, как там сгенерировать ключ.
__________________________________
На пикрил - MITM-атака, при обмене ключами по алгоритму Diffie-Hellman'a.
Очевидно, что MITM-атакер вынужден вычислять два ключа, в то время как обменивающиеся стороны - по одному ключу K.
Что если вместо ключа использовать длинную цепочку хэшей, как в этом вот warpwallet: https://keybase.io/warp/
hash(hash(hash(...ещё 65536 хэшей (K)))) - вычисление которой заняло бы довольно продолжительное время???
По разнице времени вычисления, и задержке отклика, можно было бы определить наличие MITM-атакера, и исключить MITM?
__________________________________
Каким ещё образом можно было бы исключить MITM-атаку, при обмене ключами?
М)Задача.
Условие: Есть сервер, отвечающий на запрос клиента - данными,
и есть клиент с браузером, загружающий данные, после запроса на сервер.
Проблема: данные, по пути их даставки (особенно по открытому каналу),
могут быть перехвачены - в результате MITM-атаки.
Вопрос: возможно ли как-то исключить возможность подмены данных?
Первое, что приходит в голову - это передать данные,
вычислить и них, и дать возможность клиенту сравнить этот хэш с хэшем данных на сервере.
Однако, и сам хэш может быть подменён в результате MITM-атаки.
Поэтому, можно было бы предварительно вычислить хэш строки, и опубликовать его так,
чтобы он был известен клиенту - ещё до запроса от него.
Но и в этом случае MITM-атакер может подменить хэш на свой.
Какие ещё могут быть варианты?
__________________________________
Ранее, анон >>1656896 → предлагал использовать Pre-Shared public key, и приватным ключём - подписывать данные,
а затем проверять цифровую подпись на клиенте.
Проблема в том, что исходный код сервера может быть открыт, и MITM-атакер может полностью заменить сервер.
__________________________________
Этот анон: >>1657795 → предложил использовать OTP-пароли (одноразовые пароли)
с доставкой их по совершенно-другому каналу связи.
Проблема в том, что канал связи один, и он ещё и открыт.
__________________________________
Как вариант, можно было бы использовать Gauth: https://gauth.apps.gbraad.nl/#add
но я чё-то не пойму, как там сгенерировать ключ.
__________________________________
На пикрил - MITM-атака, при обмене ключами по алгоритму Diffie-Hellman'a.
Очевидно, что MITM-атакер вынужден вычислять два ключа, в то время как обменивающиеся стороны - по одному ключу K.
Что если вместо ключа использовать длинную цепочку хэшей, как в этом вот warpwallet: https://keybase.io/warp/
hash(hash(hash(...ещё 65536 хэшей (K)))) - вычисление которой заняло бы довольно продолжительное время???
По разнице времени вычисления, и задержке отклика, можно было бы определить наличие MITM-атакера, и исключить MITM?
__________________________________
Каким ещё образом можно было бы исключить MITM-атаку, при обмене ключами?
>>658420 (OP)
Тебе придётся использовать https, и точка. Или смирись, что твои данные будут в открытом доступе.
Если у тебя там только http, тебе придётся реализовать tls самостоятельно, ручками, других вариантов нет.
Сервер твой атакер может и заменит, но без оригинального сертификата ему никто не поверит. Ну а если и сертификат в публичном доступе, то
Тебе придётся использовать https, и точка. Или смирись, что твои данные будут в открытом доступе.
Если у тебя там только http, тебе придётся реализовать tls самостоятельно, ручками, других вариантов нет.
Сервер твой атакер может и заменит, но без оригинального сертификата ему никто не поверит. Ну а если и сертификат в публичном доступе, то
> смирись, что твои данные будут в открытом доступе.
>>658420 (OP)
Загугли по запросу "anonymous p2p authentication", там чё-то есть в пдф-ках, в частности "zero-knowledge anonymous authentication".
Я не знаю, как это работает, самому интересно. Но, может поможет.
Загугли по запросу "anonymous p2p authentication", там чё-то есть в пдф-ках, в частности "zero-knowledge anonymous authentication".
Я не знаю, как это работает, самому интересно. Но, может поможет.
>>658420 (OP)
Ты не можешь аутентифицировать того, кого не знаешь. В этом проблема. Выкинь из схемы второй сервер вообще, пусть останешься только ты и MITM сервер, который выдаёт себя за другого.
Сможешь ты понять, что перед тобой кто-то другой? Как? Не решив эту проблему, ты не решишь и основную.
Ты не можешь аутентифицировать того, кого не знаешь. В этом проблема. Выкинь из схемы второй сервер вообще, пусть останешься только ты и MITM сервер, который выдаёт себя за другого.
Сможешь ты понять, что перед тобой кто-то другой? Как? Не решив эту проблему, ты не решишь и основную.
https действительно решает проблему. Важно, чтобы у каждого сервера был домен, подписанный корневым CA.
Имея эти сертификаты ты можешь легко реализовать защищённый обмен данными, даже без интернета.
Корневые CA есть у всех, они в поставке браузеров и многих других софтин идут.
Имея эти сертификаты ты можешь легко реализовать защищённый обмен данными, даже без интернета.
Корневые CA есть у всех, они в поставке браузеров и многих других софтин идут.
>>658420 (OP)
Мне кажется, что можно решить задачу по обнаружению перехвата канала, если ты посылаешь очень большие данные, либо какой-то медленный стрим.
Идея в том, что ты шифруешь данные и высылаешь их на сервер. И только после того, как данные доставлены, ты высылаешь ключ для расшифровки. Причём можно извратиться и с ассиметричными шифрами.
Для этого требуются две вещи:
1) чтобы время операции было синхронизировано, иначе MITM можно провернуть с отсрочкой по времени. От этого нет спасения никакого.
2) предполагается, что MITM не пойдёт на то, чтобы перехватить данные, выслать тебе мусор вместо них, и тем самым спалиться.
Мне кажется, что можно решить задачу по обнаружению перехвата канала, если ты посылаешь очень большие данные, либо какой-то медленный стрим.
Идея в том, что ты шифруешь данные и высылаешь их на сервер. И только после того, как данные доставлены, ты высылаешь ключ для расшифровки. Причём можно извратиться и с ассиметричными шифрами.
Для этого требуются две вещи:
1) чтобы время операции было синхронизировано, иначе MITM можно провернуть с отсрочкой по времени. От этого нет спасения никакого.
2) предполагается, что MITM не пойдёт на то, чтобы перехватить данные, выслать тебе мусор вместо них, и тем самым спалиться.
>>664980
А MITM-атакер может получить подпись корневого CA для домена, который уже забронирован,
а потом - изменить резолвинг на DNS-серверах, не на основной сервер,
а на сервер MITM-атакера, поставив его ещё и - физически поближе.
То-то же.
>>664980
Изначально, я искал именно "алгоритмы анонимной аутентификации".
И мне кажется, что это наиболее подходящая схема: >>658420 (OP)
Но, MITM-атакер может попросту вставить задержку при пинговке сервера, и откликаться чуть позже.
Тогда, соединение, следовало бы прервать нафиг, исключив тем самым и MITM.
Заметь, эта схема позволяет определить сервер ли на связи, или MITM-атакер,
разумеется, при условии что в обычном железе у MITM-атакера не встроены различные ускорители (accelerators),
вроде сверхбыстрых optical FPGA, множества ASIC's или какие-то квантовых со-процессоров,
более того, в этой схеме, ключи генерируются рандомно - как клиентом, так и сервером,
а значит, в отличие от схемы "Pre-Shared Public Key" - исключена и возможность деанона,
по наличию определнённых ключей в их железе, а также исключена - необходимость регистрации этих ключей.
Ведь как ты написал ранее:
Значит, надо зарегистрироваться, нужна регистрация, блядь, а это - уже неанонимно.
В общем, хотелось бы как-то развить предыдущую схему,
в нечто более математически и алгоритмически сложное, и надёжное.
>>665045
Передача ключа дешифрования, по отрытому каналу (пусть это будет HTTP),
даже через некое время, после отправки данных - уже чревата если не подменой самих данных,
то перехватом этого ключа, с последующим дешифрованием данных.
Не обязательно MITM-атакером, а кем угодно, любым сниффером.
Более того, как без аутентификациии и/или обмена ключами,
быть уверенным в том, что данные, с ключём,
передаются именно на реальный сервер, а не на сервер MITM-атакера?
Асимметричные шифры тоже могут быть подвержены MITM-атаке.
Например, Server <-> Client:
(ClientPrivKey -> ClientPubKey) -> ClientPubKey to Server
(ServerPrivKey -> ServerPubKey) -> ServerPubKey to Client
Всё хорошо и прекрасно, клиент с сервером - обменялись публичными ключами,
могут шифровать и дешифровать данные ключами приватными, а расшифровывать их - публичными.
Но, пусть по средине будет MITM-attacker: Server <-> MITM-attacker <-> Client:
(ClientPrivKey -> ClientPubKey) -> ClientPubKey to MITM-attacker
(MITMPrivKeyForServer -> MITMPubKeyForServer) -> MITMPrivKeyForServer to Server
(ServerPrivKey -> ServerPubKey) -> ServerPubKey to MITM-attacker
(MITMPrivKeyForClient -> MITMPubKeyForClient) -> MITMPrivKeyForClient to Client.
То же самое, блядь! Только MITM-атакер теперь может и читать, и менять данные, как от клиента, так и от сервера.
Так что и асимметричные шифры тут нихуя не дают.
Вот здесь, не очень понятно. Хочешь сказать, что достаточно использовать некий алго,
вроде "синхронизируемых по времени одноразовых паролей" https://ru.wikipedia.org/wiki/Одноразовый_пароль#Синхронизированные_по_времени
и сверить часы с какой-либо точностью, чтобы исключить MITM и распознать MITM-атакера?
Вообще-то можно было бы и обмен ключами сделать, вроде того же Diffie-Hellman,
затем, синтезировать общий ключ для симметричного шифрования, и гнать шифротрафик.
Но, как видишь, из OP-пикчи, DH подвержен MITM-атаке,
поэтому, опять же, возвращаюсь к необходимости развития,
этой вот, наиболее подходящей схемы, позволяющей исключить MITM, в этом случае.
>Корневые CA есть у всех, они в поставке браузеров и многих других софтин идут.
>https действительно решает проблему.
А MITM-атакер может получить подпись корневого CA для домена, который уже забронирован,
а потом - изменить резолвинг на DNS-серверах, не на основной сервер,
а на сервер MITM-атакера, поставив его ещё и - физически поближе.
То-то же.
>>664980
>Ты не можешь аутентифицировать того, кого не знаешь. В этом проблема.
>Выкинь из схемы второй сервер вообще, пусть останешься только ты и MITM сервер,
>который выдаёт себя за другого.
>Сможешь ты понять, что перед тобой кто-то другой? Как?
>Не решив эту проблему, ты не решишь и основную.
Изначально, я искал именно "алгоритмы анонимной аутентификации".
И мне кажется, что это наиболее подходящая схема: >>658420 (OP)
>На пикрил - MITM-атака, при обмене ключами по алгоритму Diffie-Hellman'a.
>Очевидно, что MITM-атакер вынужден вычислять два ключа, в то время как обменивающиеся стороны - по одному ключу K.
>Что если вместо ключа использовать длинную цепочку хэшей, как в этом вот warpwallet: https://keybase.io/warp/
>hash(hash(hash(...ещё 65536 хэшей (K)))) - вычисление которой заняло бы довольно продолжительное время???
>По разнице времени вычисления, и задержке отклика, можно было бы определить наличие MITM-атакера, и исключить MITM?
Но, MITM-атакер может попросту вставить задержку при пинговке сервера, и откликаться чуть позже.
Тогда, соединение, следовало бы прервать нафиг, исключив тем самым и MITM.
Заметь, эта схема позволяет определить сервер ли на связи, или MITM-атакер,
разумеется, при условии что в обычном железе у MITM-атакера не встроены различные ускорители (accelerators),
вроде сверхбыстрых optical FPGA, множества ASIC's или какие-то квантовых со-процессоров,
более того, в этой схеме, ключи генерируются рандомно - как клиентом, так и сервером,
а значит, в отличие от схемы "Pre-Shared Public Key" - исключена и возможность деанона,
по наличию определнённых ключей в их железе, а также исключена - необходимость регистрации этих ключей.
Ведь как ты написал ранее:
>Ты не можешь аутентифицировать того, кого не знаешь. В этом проблема.
Значит, надо зарегистрироваться, нужна регистрация, блядь, а это - уже неанонимно.
В общем, хотелось бы как-то развить предыдущую схему,
в нечто более математически и алгоритмически сложное, и надёжное.
>>665045
>Идея в том, что ты шифруешь данные и высылаешь их на сервер.
>И только после того, как данные доставлены, ты высылаешь ключ для расшифровки.
Передача ключа дешифрования, по отрытому каналу (пусть это будет HTTP),
даже через некое время, после отправки данных - уже чревата если не подменой самих данных,
то перехватом этого ключа, с последующим дешифрованием данных.
Не обязательно MITM-атакером, а кем угодно, любым сниффером.
Более того, как без аутентификациии и/или обмена ключами,
быть уверенным в том, что данные, с ключём,
передаются именно на реальный сервер, а не на сервер MITM-атакера?
> Причём можно извратиться и с ассиметричными шифрами.
Асимметричные шифры тоже могут быть подвержены MITM-атаке.
Например, Server <-> Client:
(ClientPrivKey -> ClientPubKey) -> ClientPubKey to Server
(ServerPrivKey -> ServerPubKey) -> ServerPubKey to Client
Всё хорошо и прекрасно, клиент с сервером - обменялись публичными ключами,
могут шифровать и дешифровать данные ключами приватными, а расшифровывать их - публичными.
Но, пусть по средине будет MITM-attacker: Server <-> MITM-attacker <-> Client:
(ClientPrivKey -> ClientPubKey) -> ClientPubKey to MITM-attacker
(MITMPrivKeyForServer -> MITMPubKeyForServer) -> MITMPrivKeyForServer to Server
(ServerPrivKey -> ServerPubKey) -> ServerPubKey to MITM-attacker
(MITMPrivKeyForClient -> MITMPubKeyForClient) -> MITMPrivKeyForClient to Client.
То же самое, блядь! Только MITM-атакер теперь может и читать, и менять данные, как от клиента, так и от сервера.
Так что и асимметричные шифры тут нихуя не дают.
>Для этого требуются две вещи:
>1) чтобы время операции было синхронизировано, иначе MITM можно провернуть с отсрочкой по времени. От этого нет спасения никакого.
Вот здесь, не очень понятно. Хочешь сказать, что достаточно использовать некий алго,
вроде "синхронизируемых по времени одноразовых паролей" https://ru.wikipedia.org/wiki/Одноразовый_пароль#Синхронизированные_по_времени
и сверить часы с какой-либо точностью, чтобы исключить MITM и распознать MITM-атакера?
>2) предполагается, что MITM(-аттакер) не пойдёт на то, чтобы перехватить данные, выслать тебе мусор вместо них, и тем самым спалиться.
Вообще-то можно было бы и обмен ключами сделать, вроде того же Diffie-Hellman,
затем, синтезировать общий ключ для симметричного шифрования, и гнать шифротрафик.
Но, как видишь, из OP-пикчи, DH подвержен MITM-атаке,
поэтому, опять же, возвращаюсь к необходимости развития,
этой вот, наиболее подходящей схемы, позволяющей исключить MITM, в этом случае.
>>664980
А MITM-атакер может получить подпись корневого CA для домена, который уже забронирован,
а потом - изменить резолвинг на DNS-серверах, не на основной сервер,
а на сервер MITM-атакера, поставив его ещё и - физически поближе.
То-то же.
>>664980
Изначально, я искал именно "алгоритмы анонимной аутентификации".
И мне кажется, что это наиболее подходящая схема: >>658420 (OP)
Но, MITM-атакер может попросту вставить задержку при пинговке сервера, и откликаться чуть позже.
Тогда, соединение, следовало бы прервать нафиг, исключив тем самым и MITM.
Заметь, эта схема позволяет определить сервер ли на связи, или MITM-атакер,
разумеется, при условии что в обычном железе у MITM-атакера не встроены различные ускорители (accelerators),
вроде сверхбыстрых optical FPGA, множества ASIC's или какие-то квантовых со-процессоров,
более того, в этой схеме, ключи генерируются рандомно - как клиентом, так и сервером,
а значит, в отличие от схемы "Pre-Shared Public Key" - исключена и возможность деанона,
по наличию определнённых ключей в их железе, а также исключена - необходимость регистрации этих ключей.
Ведь как ты написал ранее:
Значит, надо зарегистрироваться, нужна регистрация, блядь, а это - уже неанонимно.
В общем, хотелось бы как-то развить предыдущую схему,
в нечто более математически и алгоритмически сложное, и надёжное.
>>665045
Передача ключа дешифрования, по отрытому каналу (пусть это будет HTTP),
даже через некое время, после отправки данных - уже чревата если не подменой самих данных,
то перехватом этого ключа, с последующим дешифрованием данных.
Не обязательно MITM-атакером, а кем угодно, любым сниффером.
Более того, как без аутентификациии и/или обмена ключами,
быть уверенным в том, что данные, с ключём,
передаются именно на реальный сервер, а не на сервер MITM-атакера?
Асимметричные шифры тоже могут быть подвержены MITM-атаке.
Например, Server <-> Client:
(ClientPrivKey -> ClientPubKey) -> ClientPubKey to Server
(ServerPrivKey -> ServerPubKey) -> ServerPubKey to Client
Всё хорошо и прекрасно, клиент с сервером - обменялись публичными ключами,
могут шифровать и дешифровать данные ключами приватными, а расшифровывать их - публичными.
Но, пусть по средине будет MITM-attacker: Server <-> MITM-attacker <-> Client:
(ClientPrivKey -> ClientPubKey) -> ClientPubKey to MITM-attacker
(MITMPrivKeyForServer -> MITMPubKeyForServer) -> MITMPrivKeyForServer to Server
(ServerPrivKey -> ServerPubKey) -> ServerPubKey to MITM-attacker
(MITMPrivKeyForClient -> MITMPubKeyForClient) -> MITMPrivKeyForClient to Client.
То же самое, блядь! Только MITM-атакер теперь может и читать, и менять данные, как от клиента, так и от сервера.
Так что и асимметричные шифры тут нихуя не дают.
Вот здесь, не очень понятно. Хочешь сказать, что достаточно использовать некий алго,
вроде "синхронизируемых по времени одноразовых паролей" https://ru.wikipedia.org/wiki/Одноразовый_пароль#Синхронизированные_по_времени
и сверить часы с какой-либо точностью, чтобы исключить MITM и распознать MITM-атакера?
Вообще-то можно было бы и обмен ключами сделать, вроде того же Diffie-Hellman,
затем, синтезировать общий ключ для симметричного шифрования, и гнать шифротрафик.
Но, как видишь, из OP-пикчи, DH подвержен MITM-атаке,
поэтому, опять же, возвращаюсь к необходимости развития,
этой вот, наиболее подходящей схемы, позволяющей исключить MITM, в этом случае.
>Корневые CA есть у всех, они в поставке браузеров и многих других софтин идут.
>https действительно решает проблему.
А MITM-атакер может получить подпись корневого CA для домена, который уже забронирован,
а потом - изменить резолвинг на DNS-серверах, не на основной сервер,
а на сервер MITM-атакера, поставив его ещё и - физически поближе.
То-то же.
>>664980
>Ты не можешь аутентифицировать того, кого не знаешь. В этом проблема.
>Выкинь из схемы второй сервер вообще, пусть останешься только ты и MITM сервер,
>который выдаёт себя за другого.
>Сможешь ты понять, что перед тобой кто-то другой? Как?
>Не решив эту проблему, ты не решишь и основную.
Изначально, я искал именно "алгоритмы анонимной аутентификации".
И мне кажется, что это наиболее подходящая схема: >>658420 (OP)
>На пикрил - MITM-атака, при обмене ключами по алгоритму Diffie-Hellman'a.
>Очевидно, что MITM-атакер вынужден вычислять два ключа, в то время как обменивающиеся стороны - по одному ключу K.
>Что если вместо ключа использовать длинную цепочку хэшей, как в этом вот warpwallet: https://keybase.io/warp/
>hash(hash(hash(...ещё 65536 хэшей (K)))) - вычисление которой заняло бы довольно продолжительное время???
>По разнице времени вычисления, и задержке отклика, можно было бы определить наличие MITM-атакера, и исключить MITM?
Но, MITM-атакер может попросту вставить задержку при пинговке сервера, и откликаться чуть позже.
Тогда, соединение, следовало бы прервать нафиг, исключив тем самым и MITM.
Заметь, эта схема позволяет определить сервер ли на связи, или MITM-атакер,
разумеется, при условии что в обычном железе у MITM-атакера не встроены различные ускорители (accelerators),
вроде сверхбыстрых optical FPGA, множества ASIC's или какие-то квантовых со-процессоров,
более того, в этой схеме, ключи генерируются рандомно - как клиентом, так и сервером,
а значит, в отличие от схемы "Pre-Shared Public Key" - исключена и возможность деанона,
по наличию определнённых ключей в их железе, а также исключена - необходимость регистрации этих ключей.
Ведь как ты написал ранее:
>Ты не можешь аутентифицировать того, кого не знаешь. В этом проблема.
Значит, надо зарегистрироваться, нужна регистрация, блядь, а это - уже неанонимно.
В общем, хотелось бы как-то развить предыдущую схему,
в нечто более математически и алгоритмически сложное, и надёжное.
>>665045
>Идея в том, что ты шифруешь данные и высылаешь их на сервер.
>И только после того, как данные доставлены, ты высылаешь ключ для расшифровки.
Передача ключа дешифрования, по отрытому каналу (пусть это будет HTTP),
даже через некое время, после отправки данных - уже чревата если не подменой самих данных,
то перехватом этого ключа, с последующим дешифрованием данных.
Не обязательно MITM-атакером, а кем угодно, любым сниффером.
Более того, как без аутентификациии и/или обмена ключами,
быть уверенным в том, что данные, с ключём,
передаются именно на реальный сервер, а не на сервер MITM-атакера?
> Причём можно извратиться и с ассиметричными шифрами.
Асимметричные шифры тоже могут быть подвержены MITM-атаке.
Например, Server <-> Client:
(ClientPrivKey -> ClientPubKey) -> ClientPubKey to Server
(ServerPrivKey -> ServerPubKey) -> ServerPubKey to Client
Всё хорошо и прекрасно, клиент с сервером - обменялись публичными ключами,
могут шифровать и дешифровать данные ключами приватными, а расшифровывать их - публичными.
Но, пусть по средине будет MITM-attacker: Server <-> MITM-attacker <-> Client:
(ClientPrivKey -> ClientPubKey) -> ClientPubKey to MITM-attacker
(MITMPrivKeyForServer -> MITMPubKeyForServer) -> MITMPrivKeyForServer to Server
(ServerPrivKey -> ServerPubKey) -> ServerPubKey to MITM-attacker
(MITMPrivKeyForClient -> MITMPubKeyForClient) -> MITMPrivKeyForClient to Client.
То же самое, блядь! Только MITM-атакер теперь может и читать, и менять данные, как от клиента, так и от сервера.
Так что и асимметричные шифры тут нихуя не дают.
>Для этого требуются две вещи:
>1) чтобы время операции было синхронизировано, иначе MITM можно провернуть с отсрочкой по времени. От этого нет спасения никакого.
Вот здесь, не очень понятно. Хочешь сказать, что достаточно использовать некий алго,
вроде "синхронизируемых по времени одноразовых паролей" https://ru.wikipedia.org/wiki/Одноразовый_пароль#Синхронизированные_по_времени
и сверить часы с какой-либо точностью, чтобы исключить MITM и распознать MITM-атакера?
>2) предполагается, что MITM(-аттакер) не пойдёт на то, чтобы перехватить данные, выслать тебе мусор вместо них, и тем самым спалиться.
Вообще-то можно было бы и обмен ключами сделать, вроде того же Diffie-Hellman,
затем, синтезировать общий ключ для симметричного шифрования, и гнать шифротрафик.
Но, как видишь, из OP-пикчи, DH подвержен MITM-атаке,
поэтому, опять же, возвращаюсь к необходимости развития,
этой вот, наиболее подходящей схемы, позволяющей исключить MITM, в этом случае.
>>666026
самофикс
>(MITMPrivKeyForServer -> MITMPubKeyForServer) -> MITMPubKeyForServer to Server
>(MITMPrivKeyForClient -> MITMPubKeyForClient) -> MITMPubKeyForClient to Client.
самофикс
>>658420 (OP)
Очевидный OpenVPN
Очевидный OpenVPN
>>667500
Если нету общего секрета, то решить задачу невозможно. Ищи защищённый канал, я бы dns использовал.
Если нету общего секрета, то решить задачу невозможно. Ищи защищённый канал, я бы dns использовал.
>>658420 (OP)
Как вариант аутентификации - HMAC,
там имитовставка MAC на основе общего секретного ключа генерируется.
Но этот ключ, опять же, должен быть уже у обоих сторон,
либо должен быть получен в результате обмена ключами,
при котором может быть проведена MITM-атака.
Как вариант аутентификации - HMAC,
там имитовставка MAC на основе общего секретного ключа генерируется.
Но этот ключ, опять же, должен быть уже у обоих сторон,
либо должен быть получен в результате обмена ключами,
при котором может быть проведена MITM-атака.
>>658420 (OP)
С паблик ключем хорошая идея
И чё? Сервер не знает приватных ключей ни одного, ни другого клиента.
С паблик ключем хорошая идея
>Проблема в том, что исходный код сервера может быть открыт, и MITM-атакер может полностью заменить сервер.
И чё? Сервер не знает приватных ключей ни одного, ни другого клиента.
>>703046
Нет, ты не совсем так всё понял.
Если исходный код софтины - открыт,
и если публичный ключ, там, внутри прописан,
то очевидно, что программа должна бы что-то подписывать приватным ключём, который тоже нужно прописать в коде.
А тогда, он станет попросту известным, по причине того, что исходник открыт.
Если же приватный ключ генерировать случайно, то будет изменяться публичный ключ, из него полученный,
а значит, сгенерировать ДРУГОЙ приватный ключ может тот же MITM-атакер,
ставая, в соединении между клиентом и сервером - посередине,
и выдавая себя, клиенту - за сервер, а серверу - за клиента.
Нет, ты не совсем так всё понял.
Если исходный код софтины - открыт,
и если публичный ключ, там, внутри прописан,
то очевидно, что программа должна бы что-то подписывать приватным ключём, который тоже нужно прописать в коде.
А тогда, он станет попросту известным, по причине того, что исходник открыт.
Если же приватный ключ генерировать случайно, то будет изменяться публичный ключ, из него полученный,
а значит, сгенерировать ДРУГОЙ приватный ключ может тот же MITM-атакер,
ставая, в соединении между клиентом и сервером - посередине,
и выдавая себя, клиенту - за сервер, а серверу - за клиента.
>>704127
Станет известным, опять же, тому же MITM-атакеру, поднявшему сервер на открытом коде.
>А тогда, он станет попросту известным, по причине того, что исходник открыт.
Станет известным, опять же, тому же MITM-атакеру, поднявшему сервер на открытом коде.
>>704127
Сейчас бы прописывать ключи и пароли в коде. Никто так не делает. Читай из файла или базы.
Думаешь, опенсорс вообще существовал бы, если бы никто не мог решить эту проблему? Давно придумали SSL.
Сейчас бы прописывать ключи и пароли в коде. Никто так не делает. Читай из файла или базы.
Думаешь, опенсорс вообще существовал бы, если бы никто не мог решить эту проблему? Давно придумали SSL.
>>704204
Но ssl вообще про другое и не решает проблему ОПа, поскольку она не решаема, а про opensource это вообще кек-пук.
>Думаешь, опенсорс вообще существовал бы, если бы никто не мог решить эту проблему? Давно придумали SSL.
Но ssl вообще про другое и не решает проблему ОПа, поскольку она не решаема, а про opensource это вообще кек-пук.
>>704217
Проблема ОПа в том, что он не хочет его использовать и изобретает свой велосипед на радость MItM-щику.
> Но ssl вообще про другое и не решает проблему ОПа
Проблема ОПа в том, что он не хочет его использовать и изобретает свой велосипед на радость MItM-щику.
>>704223
В чём проблема MITM-щику,
подписать свой SSL-сертификат,
одним из доверенных центров сертификации,
с последующим резолвингом своего фейко-сервера,
через систему DNS?
В чём проблема MITM-щику,
подписать свой SSL-сертификат,
одним из доверенных центров сертификации,
с последующим резолвингом своего фейко-сервера,
через систему DNS?
>>704127
Ничего не очевидно. Очевидно что клиенты хранят приватные ключи у себя и ни с кем их не шарят.
То есть если клиент А хочет что-то отправить, предназначающееся для прочтением клиентом B, он берёт публичный ключ клиента B и енкодит им сообщение и отправляет. Клиент B получает заекоженое сообщение и декодит его своим приватным клюём, который есть только у него.
>то очевидно, что программа должна бы что-то подписывать приватным ключём, который тоже нужно прописать в коде
Ничего не очевидно. Очевидно что клиенты хранят приватные ключи у себя и ни с кем их не шарят.
То есть если клиент А хочет что-то отправить, предназначающееся для прочтением клиентом B, он берёт публичный ключ клиента B и енкодит им сообщение и отправляет. Клиент B получает заекоженое сообщение и декодит его своим приватным клюём, который есть только у него.
>>704259
на то они и доверенные центры чтоб всякому скаму не подписывать, но казахов вроде заставляют добавлять сертификат чтоб майор мог читать твой ssl траффик, но это какбы ты сам должен этот сертификат на свой страх и риск добавить
>подписать свой SSL-сертификат,
>одним из доверенных центров сертификации
на то они и доверенные центры чтоб всякому скаму не подписывать, но казахов вроде заставляют добавлять сертификат чтоб майор мог читать твой ssl траффик, но это какбы ты сам должен этот сертификат на свой страх и риск добавить
>>704269
Ну ок. А теперь, вместо клиента B - сервер, с открытым кодом.
Ну ок. А теперь, вместо клиента B - сервер, с открытым кодом.
>>704272
браузер проверит что этот ключ подписан реальным центром сертификации, а не митм, там же цепочка сертификатов типа как биткоин, просто так не вставишь
> вместо Б ему пришлет публичный ключ митмщик
браузер проверит что этот ключ подписан реальным центром сертификации, а не митм, там же цепочка сертификатов типа как биткоин, просто так не вставишь
>>704271
Чтобы доказать, что ты владелец доменного имени, достаточно перехватить подменить сервер, привязанный к домену в системе DNS, или же заменить там IP, в который резолвится доменное имя.
Чтобы доказать, что ты владелец доменного имени, достаточно перехватить подменить сервер, привязанный к домену в системе DNS, или же заменить там IP, в который резолвится доменное имя.
>>704279
Потому что Б подписан международным центром сертификации, а митм подписан васяном, митм не может подписать свой сертификат потому что у каждой оси есть список доверенных центров сертификации
>Как ты проверишь что это Б а не МИТМ?
Потому что Б подписан международным центром сертификации, а митм подписан васяном, митм не может подписать свой сертификат потому что у каждой оси есть список доверенных центров сертификации
>>704282
Хотя вроде касперский тоже свой сертификат добавлял в систему чтобы читать твой ssl траффик, пока их не словили, ну они там чета высрали объяснительную
Хотя вроде касперский тоже свой сертификат добавлял в систему чтобы читать твой ssl траффик, пока их не словили, ну они там чета высрали объяснительную
>>704272
Так для этого есть нетворк оф траст и всё такое.
Так для этого есть нетворк оф траст и всё такое.
>>704282
Как ты определишь, что тебе написал пользователь Б, а не В? Они оба получили подпись.
Как ты определишь, что тебе написал пользователь Б, а не В? Они оба получили подпись.
>>704311
Потому что в Б в сертификате будет написано, что он - Б, и что сертификат выдан центром сертификации. А у В будет написано, что он - Б, и что сертификат выдан васяном.
Потому что в Б в сертификате будет написано, что он - Б, и что сертификат выдан центром сертификации. А у В будет написано, что он - Б, и что сертификат выдан васяном.
>>704315
Как этим пользоваться? То есть условный мессенджер, и чтобы залогиниться Б должен сначала в каком то центре сертификации для браузеров должен купить серт? Предоставив видимо им паспорт? А они честно проверят что это паспорт Б, а не фотошоп или скан из интернета?
Как этим пользоваться? То есть условный мессенджер, и чтобы залогиниться Б должен сначала в каком то центре сертификации для браузеров должен купить серт? Предоставив видимо им паспорт? А они честно проверят что это паспорт Б, а не фотошоп или скан из интернета?
>>704340
Вроде того.
Некоторые действительно требуют документы. Есть те, кто не требует, но полностью анонимно сертификаты почти нигде не выдают. Даже let's encrypt собирает какие-то данные.
И они действительно указанные данные проверяют. Смотрят, что указанный домен принадлежит именно тебе. Также могут проверить данные об организации.
Вроде того.
Некоторые действительно требуют документы. Есть те, кто не требует, но полностью анонимно сертификаты почти нигде не выдают. Даже let's encrypt собирает какие-то данные.
И они действительно указанные данные проверяют. Смотрят, что указанный домен принадлежит именно тебе. Также могут проверить данные об организации.
>>704357
https://letsencrypt.org/ru/getting-started/
Просто загружаешь файл
на сервер, на IP которого резолвится доменное имя,
Let's Encrypt проверяет его наличие,
сверяет домен и выдаёт сертификат как владельцу домена,
поскольку владение доменов - потверждено таким образом, и файл этот там есть.
Как Let's Encrypt будет уверен в том, что это реальный сервер, а не сервер митмщика,
что это реальный владелей, а не митмщик,
и что доверенным центром сертификации,
подписывается сертификат реального владельца, а не сертификат митмщика?
https://letsencrypt.org/ru/getting-started/
Просто загружаешь файл
на сервер, на IP которого резолвится доменное имя,
Let's Encrypt проверяет его наличие,
сверяет домен и выдаёт сертификат как владельцу домена,
поскольку владение доменов - потверждено таким образом, и файл этот там есть.
Как Let's Encrypt будет уверен в том, что это реальный сервер, а не сервер митмщика,
что это реальный владелей, а не митмщик,
и что доверенным центром сертификации,
подписывается сертификат реального владельца, а не сертификат митмщика?
>>704420
Кто первый получает сертификат - тот и реальный владелец. Чтобы возникла проблема, нужно, чтобы MItM-щик попытался получить сертификат до реального владельца. Но в таком случае и реальный владелец сертификат не получит.
Кто первый получает сертификат - тот и реальный владелец. Чтобы возникла проблема, нужно, чтобы MItM-щик попытался получить сертификат до реального владельца. Но в таком случае и реальный владелец сертификат не получит.
>>704340
например в java есть файл с ключами доверенных центров сертификации, в каждом браузере и оси есть тоже списки доверенных центров
>? То есть условный мессенджер, и чтобы залогиниться Б должен сначала в каком то центре сертификации для браузеров должен купить серт?
например в java есть файл с ключами доверенных центров сертификации, в каждом браузере и оси есть тоже списки доверенных центров
>>704435
К чему ты это написал? Я могу подписать этим ключом что угодно?
К чему ты это написал? Я могу подписать этим ключом что угодно?
>>704431
Даже если доверенный центр сертификации Let's Encrypt'а не подишет второй сертификат, в чём проблема подписать его другим доверенным центром сертификации?
На то их и несколько, доверенных, не?
Даже если доверенный центр сертификации Let's Encrypt'а не подишет второй сертификат, в чём проблема подписать его другим доверенным центром сертификации?
На то их и несколько, доверенных, не?
>>658420 (OP)
Pre-shared public key может быть тоже подменён MITM-атакером, ещё на этапе получения публичного ключа.
Как вариант, для защиты от подмены, public key диверсифицирован по множеству мест хранения, и выгружаться из децентрализованной сети.
Если просто по носителям диверсифицировать pub, то они могут просто синхронно изменить его.
Но public key, также, может быть опубликован, в виде обычного текстового примечания к транзакции в блокчейне.
Пофиг в каком блокчейне, это может и быть любой шиткоин,
но лучше - популярный, чтобы было дофига нод у него. Диверсификация же!
Если надо изменить ключи - то перегенерируется приватный ключ,
новый публичный ключ публикуется в примечании к другой транзакции и всё.
Ну а дальше, в код прописывается адрес владельца ключей, и ссылка на общедоступный block-explorer,
где из последней транзакции, выгруженной в JSON-виде, и из её примечания - извлекается публичный ключ, и сверяется с ключём на сервере.
При этом, подменить опубликованный ключ нельзя, подтверждённые транзакции, попавшие в блокчейн - не мочерируются, и сохраняются там.
Можно только новый задать, другой транзакцией, которая будет последней по конкретному адресу.
Однако, митм-атакер, может подменить сам код, и адрес, и свои ключи генерировать, причём таким же образом,
но в этом случае, уже не будет совпадать хэш кода.
Впочем, и хэш кода, кстати, он может тоже попросту подменить, на какой-нибудь - свой.
Возможно, через блокчейн как-то можно зарегистрировать паблик-кеи и клиентов, но тогда это будет нечто вроде регистрации, и нихуя не анонимно.
>Ранее, анон >>1656896 → → предлагал использовать Pre-Shared public key, и приватным ключём - подписывать данные,
>а затем проверять цифровую подпись на клиенте.
>Проблема в том, что исходный код сервера может быть открыт, и MITM-атакер может полностью заменить сервер.
Pre-shared public key может быть тоже подменён MITM-атакером, ещё на этапе получения публичного ключа.
Как вариант, для защиты от подмены, public key диверсифицирован по множеству мест хранения, и выгружаться из децентрализованной сети.
Если просто по носителям диверсифицировать pub, то они могут просто синхронно изменить его.
Но public key, также, может быть опубликован, в виде обычного текстового примечания к транзакции в блокчейне.
Пофиг в каком блокчейне, это может и быть любой шиткоин,
но лучше - популярный, чтобы было дофига нод у него. Диверсификация же!
Если надо изменить ключи - то перегенерируется приватный ключ,
новый публичный ключ публикуется в примечании к другой транзакции и всё.
Ну а дальше, в код прописывается адрес владельца ключей, и ссылка на общедоступный block-explorer,
где из последней транзакции, выгруженной в JSON-виде, и из её примечания - извлекается публичный ключ, и сверяется с ключём на сервере.
При этом, подменить опубликованный ключ нельзя, подтверждённые транзакции, попавшие в блокчейн - не мочерируются, и сохраняются там.
Можно только новый задать, другой транзакцией, которая будет последней по конкретному адресу.
Однако, митм-атакер, может подменить сам код, и адрес, и свои ключи генерировать, причём таким же образом,
но в этом случае, уже не будет совпадать хэш кода.
Впочем, и хэш кода, кстати, он может тоже попросту подменить, на какой-нибудь - свой.
Возможно, через блокчейн как-то можно зарегистрировать паблик-кеи и клиентов, но тогда это будет нечто вроде регистрации, и нихуя не анонимно.
>>711116
Раз ОП верит, что можно наебать доверенный центр, то вряд ли вероятность атаки через 51 процент его устроит.
> блокчейн
Раз ОП верит, что можно наебать доверенный центр, то вряд ли вероятность атаки через 51 процент его устроит.
>>705507
Другой доверенный центр посмотрит на твой домен, увидит сертификат другого центра и пошлёт тебя нахуй.
Другой доверенный центр посмотрит на твой домен, увидит сертификат другого центра и пошлёт тебя нахуй.
>>711131
Атака 51%, подразумевает контроль над 51% хешрейта всей сети,
что позволяет осуществлять двойные траты будущих транзакций,
сначала подтверждая их в одном блокчейне,
затем генерируя более длинную цепочку блоков с определённого блока,
и отпрасывая первую цепочку после оверрайда, как орфан-блоки.
Таким образом, даже все другие майнеры, со своими 49% хешрейта сети,
не могут сгенерировать более длинную цепочку,
и манипулятор может генерировать сколь угодно много цепочек, которые будут длинее ихней цепочки,
а значит его цепочка будет основной, а все более короткие - будут отброшены.
Он может делать так сколь угодно много раз, в каждой цепочке производя трату своих монет,
и отменяя транзакции свои в новой цепочке, и снова продолжая их тратить.
Но это относится только к новым транзакциям, включённым в новые блоки блокчейна,
а транзакции старые, которые включены в блоки, блокчейна до прописанных в коде checkpoints,
такой атакер уже не сможет отменить, без переписывания исходного кода.
Атака 51%, подразумевает контроль над 51% хешрейта всей сети,
что позволяет осуществлять двойные траты будущих транзакций,
сначала подтверждая их в одном блокчейне,
затем генерируя более длинную цепочку блоков с определённого блока,
и отпрасывая первую цепочку после оверрайда, как орфан-блоки.
Таким образом, даже все другие майнеры, со своими 49% хешрейта сети,
не могут сгенерировать более длинную цепочку,
и манипулятор может генерировать сколь угодно много цепочек, которые будут длинее ихней цепочки,
а значит его цепочка будет основной, а все более короткие - будут отброшены.
Он может делать так сколь угодно много раз, в каждой цепочке производя трату своих монет,
и отменяя транзакции свои в новой цепочке, и снова продолжая их тратить.
Но это относится только к новым транзакциям, включённым в новые блоки блокчейна,
а транзакции старые, которые включены в блоки, блокчейна до прописанных в коде checkpoints,
такой атакер уже не сможет отменить, без переписывания исходного кода.
>>711135
А разве сертиф не на сервере прописывается, вгружаясь потом, оттуда? Да, цифровая подпись соответствует СА, но сам-то сертиф с паблик-кеем - с подставного сервера может быть вгружен.
А разве сертиф не на сервере прописывается, вгружаясь потом, оттуда? Да, цифровая подпись соответствует СА, но сам-то сертиф с паблик-кеем - с подставного сервера может быть вгружен.
>>711424
Не совсем понял. То есть атакующий попытается изменить публичный ключ в сертификате? Но подпись проверяет не только CA, но и другие данные, включая публичный ключ. Изменишь его - подпись не совпадёт.
Не совсем понял. То есть атакующий попытается изменить публичный ключ в сертификате? Но подпись проверяет не только CA, но и другие данные, включая публичный ключ. Изменишь его - подпись не совпадёт.
>>711452
Нет, атакующий просто подменит сервер, и с этого подставного сервера - свой сертификат, вгрузит, подписанный доверенным СА.
Нет, атакующий просто подменит сервер, и с этого подставного сервера - свой сертификат, вгрузит, подписанный доверенным СА.
Информация к размышлению.
> https://ordina-jworks.github.io/security/2018/02/12/HPKP-deprecated-what-now.html
> Recently Google announced their intent to deprecate support for Public Key Pinning (HPKP). Let’s have a look at the reasons for this and what technologies we can use to replace it
>>658420 (OP)
Если так подумать, то обычный обрыв соединения, с последующим соединением через MITM,
может позволить митмщику перехватить любой управляемый дрон.
Как там реализуется шифрование?
Если так подумать, то обычный обрыв соединения, с последующим соединением через MITM,
может позволить митмщику перехватить любой управляемый дрон.
Как там реализуется шифрование?
>>714728
Шифрование на то и шифрование, чтобы никто за разумное время не мог понять смысл передаваемых данных, даже если их вся планета увидит.
В криптографии достаточно много сложных для понимания концепций, но на уровне того, кто юзает эти методы, хватит понимания, как их использовать, не задумываясь об их реализации. Симетричное шифрование (в частности, AES), шифрование с открытым ключом (RSA), TLS, хеш-функции, цифровые подписи, вот это вод всё.
> Если так подумать, то обычный обрыв соединения, с последующим соединением через MITM, может позволить митмщику перехватить любой управляемый дрон.
Шифрование на то и шифрование, чтобы никто за разумное время не мог понять смысл передаваемых данных, даже если их вся планета увидит.
> Как там реализуется шифрование?
В криптографии достаточно много сложных для понимания концепций, но на уровне того, кто юзает эти методы, хватит понимания, как их использовать, не задумываясь об их реализации. Симетричное шифрование (в частности, AES), шифрование с открытым ключом (RSA), TLS, хеш-функции, цифровые подписи, вот это вод всё.
>>714749
ну это если "полезность" данных кончится раньше, чем пройдет "разумное время"
>разумное время не мог понять смысл передаваемых данных
ну это если "полезность" данных кончится раньше, чем пройдет "разумное время"
>>714752
Ага, всё для этого.
Ага, всё для этого.
>>714749
А что мешает, пока дрон летает, перехватить шифросигнал сниффером, записать его,
и тупо сбрутить симметричный ключ на суперкомпах,
или в реальном времени - на квантовых компах,
с последующим декодированием сигналов, и реализацией митм-атаки?
Тут разве что pre-shared public key, может исключить mitm,
то есть внутри дрона должен быть pub управляющего командного пункта, а там - pub дрона.
Шифрование секретными ключами, дешифрование публичными.
Иначе же, митмщик может сгенерить свой приватный ключ, с него получить публичный,
и наебать обе стороны, подставляя им свои ключи.
Та же песня. mitm можно и на tls заебенить.
Митмщик может подменить хэш.
Опять же, подпись асимметричным ключём может быть подделана, если митмщик при обмене ключами свои ключи сунет.
>Шифрование на то и шифрование,
>чтобы никто за разумное время
>не мог понять смысл передаваемых данных,
>даже если их вся планета увидит.
>Симетричное шифрование (в частности, AES)
А что мешает, пока дрон летает, перехватить шифросигнал сниффером, записать его,
и тупо сбрутить симметричный ключ на суперкомпах,
или в реальном времени - на квантовых компах,
с последующим декодированием сигналов, и реализацией митм-атаки?
>шифрование с открытым ключом (RSA)
Тут разве что pre-shared public key, может исключить mitm,
то есть внутри дрона должен быть pub управляющего командного пункта, а там - pub дрона.
Шифрование секретными ключами, дешифрование публичными.
Иначе же, митмщик может сгенерить свой приватный ключ, с него получить публичный,
и наебать обе стороны, подставляя им свои ключи.
>TLS
Та же песня. mitm можно и на tls заебенить.
>хеш-функции
Митмщик может подменить хэш.
>цифровые подписи
Опять же, подпись асимметричным ключём может быть подделана, если митмщик при обмене ключами свои ключи сунет.
>>714749
А что мешает, пока дрон летает, перехватить шифросигнал сниффером, записать его,
и тупо сбрутить симметричный ключ на суперкомпах,
или в реальном времени - на квантовых компах,
с последующим декодированием сигналов, и реализацией митм-атаки?
Тут разве что pre-shared public key, может исключить mitm,
то есть внутри дрона должен быть pub управляющего командного пункта, а там - pub дрона.
Шифрование секретными ключами, дешифрование публичными.
Иначе же, митмщик может сгенерить свой приватный ключ, с него получить публичный,
и наебать обе стороны, подставляя им свои ключи.
Та же песня. mitm можно и на tls заебенить.
Митмщик может подменить хэш.
Опять же, подпись асимметричным ключём может быть подделана, если митмщик при обмене ключами свои ключи сунет.
>Шифрование на то и шифрование,
>чтобы никто за разумное время
>не мог понять смысл передаваемых данных,
>даже если их вся планета увидит.
>Симетричное шифрование (в частности, AES)
А что мешает, пока дрон летает, перехватить шифросигнал сниффером, записать его,
и тупо сбрутить симметричный ключ на суперкомпах,
или в реальном времени - на квантовых компах,
с последующим декодированием сигналов, и реализацией митм-атаки?
>шифрование с открытым ключом (RSA)
Тут разве что pre-shared public key, может исключить mitm,
то есть внутри дрона должен быть pub управляющего командного пункта, а там - pub дрона.
Шифрование секретными ключами, дешифрование публичными.
Иначе же, митмщик может сгенерить свой приватный ключ, с него получить публичный,
и наебать обе стороны, подставляя им свои ключи.
>TLS
Та же песня. mitm можно и на tls заебенить.
>хеш-функции
Митмщик может подменить хэш.
>цифровые подписи
Опять же, подпись асимметричным ключём может быть подделана, если митмщик при обмене ключами свои ключи сунет.
>>714805
Но опять же, есть атаки на RSA, и при достаточном объёме перехваченного шифротрафика, можно сбрутить ключ,
в частности, с квантовыми компами, можно юзнуть - квантовый алгоритм Шора.
А дальше уже - mitm, с перехватом управления.
>Тут разве что pre-shared public key, может исключить mitm,
>то есть внутри дрона должен быть pub управляющего командного пункта, а там - pub дрона.
Но опять же, есть атаки на RSA, и при достаточном объёме перехваченного шифротрафика, можно сбрутить ключ,
в частности, с квантовыми компами, можно юзнуть - квантовый алгоритм Шора.
А дальше уже - mitm, с перехватом управления.
>>714805
А, это ты.
А, это ты.
>>704420
Let's Encrypt реализует сложный протокол, который подтверждает, что ты владеешь сервером, можешь шарить нам на 80-м порту нужные данные.
Вряд ли даже хостер сможет провернуть MitM атаку. Учти, что корневой сертификат Let's Encrypt уже предустановлен в системе, если у тебя линукс, то он просто в дистрибутиве будет.
Значит система на твоей машине сможет устанавливать надёжное соединение с сервером и сможет понять, что у неё сертификат поддельный.
В общем нет такой проблемы. Проще на сервер физически забраться и тупо скопировать твой секретный ключ.
Let's Encrypt реализует сложный протокол, который подтверждает, что ты владеешь сервером, можешь шарить нам на 80-м порту нужные данные.
Вряд ли даже хостер сможет провернуть MitM атаку. Учти, что корневой сертификат Let's Encrypt уже предустановлен в системе, если у тебя линукс, то он просто в дистрибутиве будет.
Значит система на твоей машине сможет устанавливать надёжное соединение с сервером и сможет понять, что у неё сертификат поддельный.
В общем нет такой проблемы. Проще на сервер физически забраться и тупо скопировать твой секретный ключ.
>>704420
Как это блядь просто загружаешь?
> Просто загружаешь файл
> на сервер, на IP которого резолвится доменное имя,
Как это блядь просто загружаешь?
>>658420 (OP)
1. Сервер однократно генерирует ServerPrivateKey. Получает с него ServerPublicKey и расшаривает его, и его хэш - в публичный доступ.
2. Клиент: тук-тук, хочу шифр.
3. Сервер:
Уже имеет сгенерированный ServerPrivateKey, клиент знает ServerPublicKey и его хэш,
генерирует значение, подписывает его ServerPrivateKey, отправляет подпись с цифровой подписью - клиенту.
4. Клиент:
Знает ServerPublicKey, проверяет цифровую подпись, сверяет publicKey из подписи c ServerPublicKey, извлекает сгенерированное сервером значение,
генерирует ClientPrivateKey, получает с него ClientPublicKey, берёт значение, клеет к нему свой ClientPublicKey,
подписывает (значение+ClientPublicKey), и отправляет всё это, с цифровой подписью - на сервер.
5. Сервер: извлекает значение, извлекает ClientPublicKey, проверяет цифровую подпись, сверяет паб из подписи и ClientPublicKey, а также - значение.
6. Сервер имеет прив сервера, и паб клиента, клиент имеет прив клиента и паб сервера. Можно произвести обмен ключами:
Общий ключ = KeyExchange(ServerPrivateKey, ClientPublicKey) === KeyExchange(ClientPrivateKey, ServerPublicKey);
7. Дальше, течёт шифр по общему ключу.
При таком раскладе, покуда ServerPublicKey и hash заранее известен всем, в том числе и клиенту,
mitm-атакер уже не сможет подменить подписанное значение, поскольку не сможет знать ServerPrivateKey.
Но при большом количестве обращений, возможен перехват подписей,
и брутфорс ServerPrivateKey, по известным ServerPublicKey и разным подписям.
Если же генерировать ServerPublicKey регулярно, то ServerPublicKey и его хэш не будут постоянными,
и при очередном запросе их, mitm-атакер может оплностью подмениь серер,
затем сунуть свои ключи и хэш - клиенту, выдавая себя ему за сервер, а серверу себя - за клиента.
1. Сервер однократно генерирует ServerPrivateKey. Получает с него ServerPublicKey и расшаривает его, и его хэш - в публичный доступ.
2. Клиент: тук-тук, хочу шифр.
3. Сервер:
Уже имеет сгенерированный ServerPrivateKey, клиент знает ServerPublicKey и его хэш,
генерирует значение, подписывает его ServerPrivateKey, отправляет подпись с цифровой подписью - клиенту.
4. Клиент:
Знает ServerPublicKey, проверяет цифровую подпись, сверяет publicKey из подписи c ServerPublicKey, извлекает сгенерированное сервером значение,
генерирует ClientPrivateKey, получает с него ClientPublicKey, берёт значение, клеет к нему свой ClientPublicKey,
подписывает (значение+ClientPublicKey), и отправляет всё это, с цифровой подписью - на сервер.
5. Сервер: извлекает значение, извлекает ClientPublicKey, проверяет цифровую подпись, сверяет паб из подписи и ClientPublicKey, а также - значение.
6. Сервер имеет прив сервера, и паб клиента, клиент имеет прив клиента и паб сервера. Можно произвести обмен ключами:
Общий ключ = KeyExchange(ServerPrivateKey, ClientPublicKey) === KeyExchange(ClientPrivateKey, ServerPublicKey);
7. Дальше, течёт шифр по общему ключу.
При таком раскладе, покуда ServerPublicKey и hash заранее известен всем, в том числе и клиенту,
mitm-атакер уже не сможет подменить подписанное значение, поскольку не сможет знать ServerPrivateKey.
Но при большом количестве обращений, возможен перехват подписей,
и брутфорс ServerPrivateKey, по известным ServerPublicKey и разным подписям.
Если же генерировать ServerPublicKey регулярно, то ServerPublicKey и его хэш не будут постоянными,
и при очередном запросе их, mitm-атакер может оплностью подмениь серер,
затем сунуть свои ключи и хэш - клиенту, выдавая себя ему за сервер, а серверу себя - за клиента.
>>658420 (OP)
1. Сервер однократно генерирует ServerPrivateKey. Получает с него ServerPublicKey и расшаривает его, и его хэш - в публичный доступ.
2. Клиент: тук-тук, хочу шифр.
3. Сервер:
Уже имеет сгенерированный ServerPrivateKey, клиент знает ServerPublicKey и его хэш,
генерирует значение, подписывает его ServerPrivateKey, отправляет подпись с цифровой подписью - клиенту.
4. Клиент:
Знает ServerPublicKey, проверяет цифровую подпись, сверяет publicKey из подписи c ServerPublicKey, извлекает сгенерированное сервером значение,
генерирует ClientPrivateKey, получает с него ClientPublicKey, берёт значение, клеет к нему свой ClientPublicKey,
подписывает (значение+ClientPublicKey), и отправляет всё это, с цифровой подписью - на сервер.
5. Сервер: извлекает значение, извлекает ClientPublicKey, проверяет цифровую подпись, сверяет паб из подписи и ClientPublicKey, а также - значение.
6. Сервер имеет прив сервера, и паб клиента, клиент имеет прив клиента и паб сервера. Можно произвести обмен ключами:
Общий ключ = KeyExchange(ServerPrivateKey, ClientPublicKey) === KeyExchange(ClientPrivateKey, ServerPublicKey);
7. Дальше, течёт шифр по общему ключу.
При таком раскладе, покуда ServerPublicKey и hash заранее известен всем, в том числе и клиенту,
mitm-атакер уже не сможет подменить подписанное значение, поскольку не сможет знать ServerPrivateKey.
Но при большом количестве обращений, возможен перехват подписей,
и брутфорс ServerPrivateKey, по известным ServerPublicKey и разным подписям.
Если же генерировать ServerPublicKey регулярно, то ServerPublicKey и его хэш не будут постоянными,
и при очередном запросе их, mitm-атакер может оплностью подмениь серер,
затем сунуть свои ключи и хэш - клиенту, выдавая себя ему за сервер, а серверу себя - за клиента.
1. Сервер однократно генерирует ServerPrivateKey. Получает с него ServerPublicKey и расшаривает его, и его хэш - в публичный доступ.
2. Клиент: тук-тук, хочу шифр.
3. Сервер:
Уже имеет сгенерированный ServerPrivateKey, клиент знает ServerPublicKey и его хэш,
генерирует значение, подписывает его ServerPrivateKey, отправляет подпись с цифровой подписью - клиенту.
4. Клиент:
Знает ServerPublicKey, проверяет цифровую подпись, сверяет publicKey из подписи c ServerPublicKey, извлекает сгенерированное сервером значение,
генерирует ClientPrivateKey, получает с него ClientPublicKey, берёт значение, клеет к нему свой ClientPublicKey,
подписывает (значение+ClientPublicKey), и отправляет всё это, с цифровой подписью - на сервер.
5. Сервер: извлекает значение, извлекает ClientPublicKey, проверяет цифровую подпись, сверяет паб из подписи и ClientPublicKey, а также - значение.
6. Сервер имеет прив сервера, и паб клиента, клиент имеет прив клиента и паб сервера. Можно произвести обмен ключами:
Общий ключ = KeyExchange(ServerPrivateKey, ClientPublicKey) === KeyExchange(ClientPrivateKey, ServerPublicKey);
7. Дальше, течёт шифр по общему ключу.
При таком раскладе, покуда ServerPublicKey и hash заранее известен всем, в том числе и клиенту,
mitm-атакер уже не сможет подменить подписанное значение, поскольку не сможет знать ServerPrivateKey.
Но при большом количестве обращений, возможен перехват подписей,
и брутфорс ServerPrivateKey, по известным ServerPublicKey и разным подписям.
Если же генерировать ServerPublicKey регулярно, то ServerPublicKey и его хэш не будут постоянными,
и при очередном запросе их, mitm-атакер может оплностью подмениь серер,
затем сунуть свои ключи и хэш - клиенту, выдавая себя ему за сервер, а серверу себя - за клиента.
>>724331
И как это представить? Если клиент заранее ничего не знает и узнаёт ключ и хеш через сеть, то клиент может получить через сеть ключ и корректный хеш от митм-щика и так и не узнать, что он был подменён, потому что митм-щик перепаковывает весь трафик своим ключом. Ну а если клиент заранее знает ключ (например, пришёл в офис сервера лично и получил бумажку с ключом), то и подписи никакие не нужны.
> заранее известен всем
И как это представить? Если клиент заранее ничего не знает и узнаёт ключ и хеш через сеть, то клиент может получить через сеть ключ и корректный хеш от митм-щика и так и не узнать, что он был подменён, потому что митм-щик перепаковывает весь трафик своим ключом. Ну а если клиент заранее знает ключ (например, пришёл в офис сервера лично и получил бумажку с ключом), то и подписи никакие не нужны.
>>724337
Подразумевается, что ServerPublicKey и его хэш (не обязательно даже),
он уже общедоступен и опубликован, а также, заранее известен клиенту.
Это может быть тред на борде, это может быть первый пост топикстартера на форуме,
это может быть транзакция в блокчейне с примечанием в виде этого ключа,
это может быть публиный ключ опубликованный на сайте сервера, на каком-нибудь onion-домене,
можно также просто сунуть его в исходный код или в README.md куда-нибудь, на github'e...
Можно высылать его на email на телефон клиента (что неанонимно для клиента),
и по любому другому открытому каналу связи,
и тут не так важно то, что этот публичный ключ может быть прочитан и перехвачен,
сколько важно то, что он может быть таки подменён,
поэтому, лучше бы использовать любой другой зашифрованный и защищённый канал связи.
Тогда, митмщику придётся полностью подменить сервер,
и перехватить трафик для возможности его подмены, по всем возможным ссылкам,
где может быть опубликован тот самый ключ,
для подмены его на ключ митмщика.
Дело в том, что публичный ключ, позволяет проверять цифровую подпись различных значний, сгенерированных сервером,
и подписанных скрытым на сервере ключём - приватным.
Генерация именно различных значений на сервере,
позволяет менять общий ключ шифрования для различных сессий зашифрованного обмена данными,
для чего достаточно один раз, корректно, передать клиенту только публичный ключ, в том же офисе,
причём так, чтобы он не был подменён.
То есть он может быть даже быть перехвачен и прочитан, по мере доставки его клиентом - домой.
Не пойму, с чего ты решил, что подписи никакие не нужны,
ведь если общий ключ выдавать клиенту в том же офисе, его могут просто переписать, по пути его доставки,
или втихую извлечь из памяти компьютера клиента.
Вообще, моя задача в предыдущем посте, состояла в том,
чтобы совместить схему pre-shared public key с анонимностью клиентов.
Ведь схема pre-shared public key, в случае статичных privkey и pubkey у клиента - она не анонимна,
так как по наличию известного pubkey клиента, и по наличию privkey на железе клиента,
можно проверить соответствие privkey этому pubkey, и так вот задеанонить клиента.
При этом, сам процесс генерации ClientPrivateKey и публикации ClientPublicKey, является чем-то вроде регистрации клиента.
Решение выше, позволяет клиенту оставаться анонимным,
по причине динамической генерации его ключей и смены их, для каждой шифросессии.
Более того, чтобы не быть задеаненным в течении шифросессии,
ещё на шаге 4, клиент может ещё и дополнительно зашифровать,
подписанное им (значение+ClientPublicKey), при помощи известного ему ServerPublicKey,
с последующей дешифровкой всего этого шифра, скрытым на сервере ServerPrivateKey.
>И как это представить?
Подразумевается, что ServerPublicKey и его хэш (не обязательно даже),
он уже общедоступен и опубликован, а также, заранее известен клиенту.
Это может быть тред на борде, это может быть первый пост топикстартера на форуме,
это может быть транзакция в блокчейне с примечанием в виде этого ключа,
это может быть публиный ключ опубликованный на сайте сервера, на каком-нибудь onion-домене,
можно также просто сунуть его в исходный код или в README.md куда-нибудь, на github'e...
Можно высылать его на email на телефон клиента (что неанонимно для клиента),
и по любому другому открытому каналу связи,
и тут не так важно то, что этот публичный ключ может быть прочитан и перехвачен,
сколько важно то, что он может быть таки подменён,
поэтому, лучше бы использовать любой другой зашифрованный и защищённый канал связи.
>Если клиент заранее ничего не знает и узнаёт ключ и хеш через сеть,
>то клиент может получить через сеть ключ и корректный хеш от митм-щика и так и не узнать,
>что он был подменён, потому что митм-щик перепаковывает весь трафик своим ключом.
Тогда, митмщику придётся полностью подменить сервер,
и перехватить трафик для возможности его подмены, по всем возможным ссылкам,
где может быть опубликован тот самый ключ,
для подмены его на ключ митмщика.
>Ну а если клиент заранее знает ключ (например, пришёл в офис сервера лично и получил бумажку с ключом), то и подписи никакие не нужны.
Дело в том, что публичный ключ, позволяет проверять цифровую подпись различных значний, сгенерированных сервером,
и подписанных скрытым на сервере ключём - приватным.
Генерация именно различных значений на сервере,
позволяет менять общий ключ шифрования для различных сессий зашифрованного обмена данными,
для чего достаточно один раз, корректно, передать клиенту только публичный ключ, в том же офисе,
причём так, чтобы он не был подменён.
То есть он может быть даже быть перехвачен и прочитан, по мере доставки его клиентом - домой.
Не пойму, с чего ты решил, что подписи никакие не нужны,
ведь если общий ключ выдавать клиенту в том же офисе, его могут просто переписать, по пути его доставки,
или втихую извлечь из памяти компьютера клиента.
Вообще, моя задача в предыдущем посте, состояла в том,
чтобы совместить схему pre-shared public key с анонимностью клиентов.
Ведь схема pre-shared public key, в случае статичных privkey и pubkey у клиента - она не анонимна,
так как по наличию известного pubkey клиента, и по наличию privkey на железе клиента,
можно проверить соответствие privkey этому pubkey, и так вот задеанонить клиента.
При этом, сам процесс генерации ClientPrivateKey и публикации ClientPublicKey, является чем-то вроде регистрации клиента.
Решение выше, позволяет клиенту оставаться анонимным,
по причине динамической генерации его ключей и смены их, для каждой шифросессии.
Более того, чтобы не быть задеаненным в течении шифросессии,
ещё на шаге 4, клиент может ещё и дополнительно зашифровать,
подписанное им (значение+ClientPublicKey), при помощи известного ему ServerPublicKey,
с последующей дешифровкой всего этого шифра, скрытым на сервере ServerPrivateKey.
>>724337
Подразумевается, что ServerPublicKey и его хэш (не обязательно даже),
он уже общедоступен и опубликован, а также, заранее известен клиенту.
Это может быть тред на борде, это может быть первый пост топикстартера на форуме,
это может быть транзакция в блокчейне с примечанием в виде этого ключа,
это может быть публиный ключ опубликованный на сайте сервера, на каком-нибудь onion-домене,
можно также просто сунуть его в исходный код или в README.md куда-нибудь, на github'e...
Можно высылать его на email на телефон клиента (что неанонимно для клиента),
и по любому другому открытому каналу связи,
и тут не так важно то, что этот публичный ключ может быть прочитан и перехвачен,
сколько важно то, что он может быть таки подменён,
поэтому, лучше бы использовать любой другой зашифрованный и защищённый канал связи.
Тогда, митмщику придётся полностью подменить сервер,
и перехватить трафик для возможности его подмены, по всем возможным ссылкам,
где может быть опубликован тот самый ключ,
для подмены его на ключ митмщика.
Дело в том, что публичный ключ, позволяет проверять цифровую подпись различных значний, сгенерированных сервером,
и подписанных скрытым на сервере ключём - приватным.
Генерация именно различных значений на сервере,
позволяет менять общий ключ шифрования для различных сессий зашифрованного обмена данными,
для чего достаточно один раз, корректно, передать клиенту только публичный ключ, в том же офисе,
причём так, чтобы он не был подменён.
То есть он может быть даже быть перехвачен и прочитан, по мере доставки его клиентом - домой.
Не пойму, с чего ты решил, что подписи никакие не нужны,
ведь если общий ключ выдавать клиенту в том же офисе, его могут просто переписать, по пути его доставки,
или втихую извлечь из памяти компьютера клиента.
Вообще, моя задача в предыдущем посте, состояла в том,
чтобы совместить схему pre-shared public key с анонимностью клиентов.
Ведь схема pre-shared public key, в случае статичных privkey и pubkey у клиента - она не анонимна,
так как по наличию известного pubkey клиента, и по наличию privkey на железе клиента,
можно проверить соответствие privkey этому pubkey, и так вот задеанонить клиента.
При этом, сам процесс генерации ClientPrivateKey и публикации ClientPublicKey, является чем-то вроде регистрации клиента.
Решение выше, позволяет клиенту оставаться анонимным,
по причине динамической генерации его ключей и смены их, для каждой шифросессии.
Более того, чтобы не быть задеаненным в течении шифросессии,
ещё на шаге 4, клиент может ещё и дополнительно зашифровать,
подписанное им (значение+ClientPublicKey), при помощи известного ему ServerPublicKey,
с последующей дешифровкой всего этого шифра, скрытым на сервере ServerPrivateKey.
>И как это представить?
Подразумевается, что ServerPublicKey и его хэш (не обязательно даже),
он уже общедоступен и опубликован, а также, заранее известен клиенту.
Это может быть тред на борде, это может быть первый пост топикстартера на форуме,
это может быть транзакция в блокчейне с примечанием в виде этого ключа,
это может быть публиный ключ опубликованный на сайте сервера, на каком-нибудь onion-домене,
можно также просто сунуть его в исходный код или в README.md куда-нибудь, на github'e...
Можно высылать его на email на телефон клиента (что неанонимно для клиента),
и по любому другому открытому каналу связи,
и тут не так важно то, что этот публичный ключ может быть прочитан и перехвачен,
сколько важно то, что он может быть таки подменён,
поэтому, лучше бы использовать любой другой зашифрованный и защищённый канал связи.
>Если клиент заранее ничего не знает и узнаёт ключ и хеш через сеть,
>то клиент может получить через сеть ключ и корректный хеш от митм-щика и так и не узнать,
>что он был подменён, потому что митм-щик перепаковывает весь трафик своим ключом.
Тогда, митмщику придётся полностью подменить сервер,
и перехватить трафик для возможности его подмены, по всем возможным ссылкам,
где может быть опубликован тот самый ключ,
для подмены его на ключ митмщика.
>Ну а если клиент заранее знает ключ (например, пришёл в офис сервера лично и получил бумажку с ключом), то и подписи никакие не нужны.
Дело в том, что публичный ключ, позволяет проверять цифровую подпись различных значний, сгенерированных сервером,
и подписанных скрытым на сервере ключём - приватным.
Генерация именно различных значений на сервере,
позволяет менять общий ключ шифрования для различных сессий зашифрованного обмена данными,
для чего достаточно один раз, корректно, передать клиенту только публичный ключ, в том же офисе,
причём так, чтобы он не был подменён.
То есть он может быть даже быть перехвачен и прочитан, по мере доставки его клиентом - домой.
Не пойму, с чего ты решил, что подписи никакие не нужны,
ведь если общий ключ выдавать клиенту в том же офисе, его могут просто переписать, по пути его доставки,
или втихую извлечь из памяти компьютера клиента.
Вообще, моя задача в предыдущем посте, состояла в том,
чтобы совместить схему pre-shared public key с анонимностью клиентов.
Ведь схема pre-shared public key, в случае статичных privkey и pubkey у клиента - она не анонимна,
так как по наличию известного pubkey клиента, и по наличию privkey на железе клиента,
можно проверить соответствие privkey этому pubkey, и так вот задеанонить клиента.
При этом, сам процесс генерации ClientPrivateKey и публикации ClientPublicKey, является чем-то вроде регистрации клиента.
Решение выше, позволяет клиенту оставаться анонимным,
по причине динамической генерации его ключей и смены их, для каждой шифросессии.
Более того, чтобы не быть задеаненным в течении шифросессии,
ещё на шаге 4, клиент может ещё и дополнительно зашифровать,
подписанное им (значение+ClientPublicKey), при помощи известного ему ServerPublicKey,
с последующей дешифровкой всего этого шифра, скрытым на сервере ServerPrivateKey.
>>724337
Вообще, если клиент анонимен, то
по самому определению анонимного клиента,
к серверу может обращаться связка (MITM-щик+анон),
в которой MITM-щик выдаёт себя за анона, и ретранслирует ответ анону (с возможностью перехвата и подмены данных),
при этом, аутентифицировать анона нельзя, он же анон.
Вообще, если клиент анонимен, то
по самому определению анонимного клиента,
к серверу может обращаться связка (MITM-щик+анон),
в которой MITM-щик выдаёт себя за анона, и ретранслирует ответ анону (с возможностью перехвата и подмены данных),
при этом, аутентифицировать анона нельзя, он же анон.
>>725021
Вышеописанная схема, исключает такую MITM-атаку, даже при наличии MITM-щика.
Даже без шифрования публичным ключем сервера, подписанных клиентом данных,
на шаге 4, как было предложено тут >>724638, митмщик, максимум что может,
так это перехватить подписанное клиентом и открытое, незашифрованное (значение+ClientPublicKey),
извлечь значение + ClientPublicKey.
Но MITM-щик не сможет перехватить сами данные, и подменить их,
разве что, он сможет только испортить их или разорвать шифросессию.
И в то время как "значение" нифига не даст MITM-щику, ClientPublicKey он может сохранить,
а тогда, в течении сессии, клиент может быть деанонимизирован по наличию приватного ключа,
на железе клиента, который соответвует сохранённому MITM-щиком ClientPublicKey.
Если же подписанное (значение+ClientPublicKey), на шаге 4, зашифровать на клиенте при помощи ServerPublicKey,
то митмщик не сможет извлечь ClientPublicKey, и клиент останется анонимным даже в течении шифросессии...
Однако, если client-side операции на клиенте, осуществляются при помощи скриптов (например с помощью JavaScript)
то в связке (MITM-щик+анон), MITM-щик может просто подменить скрипты,
установить зашифрованную сессию между клиентом и сервером,
а с самим аноном - взаимодействовать прозрачно, без шифрования.
Поэтому, очевидно, что клиент, должен бы получить скрипты не с сервера
(где ему, вместо сервера, их может выдать MITM-щик),
а качнуть где-нибудь, например, с того же github'a, в виде архива какого-нибудь.
Вышеописанная схема, исключает такую MITM-атаку, даже при наличии MITM-щика.
Даже без шифрования публичным ключем сервера, подписанных клиентом данных,
на шаге 4, как было предложено тут >>724638, митмщик, максимум что может,
так это перехватить подписанное клиентом и открытое, незашифрованное (значение+ClientPublicKey),
извлечь значение + ClientPublicKey.
Но MITM-щик не сможет перехватить сами данные, и подменить их,
разве что, он сможет только испортить их или разорвать шифросессию.
И в то время как "значение" нифига не даст MITM-щику, ClientPublicKey он может сохранить,
а тогда, в течении сессии, клиент может быть деанонимизирован по наличию приватного ключа,
на железе клиента, который соответвует сохранённому MITM-щиком ClientPublicKey.
Если же подписанное (значение+ClientPublicKey), на шаге 4, зашифровать на клиенте при помощи ServerPublicKey,
то митмщик не сможет извлечь ClientPublicKey, и клиент останется анонимным даже в течении шифросессии...
Однако, если client-side операции на клиенте, осуществляются при помощи скриптов (например с помощью JavaScript)
то в связке (MITM-щик+анон), MITM-щик может просто подменить скрипты,
установить зашифрованную сессию между клиентом и сервером,
а с самим аноном - взаимодействовать прозрачно, без шифрования.
Поэтому, очевидно, что клиент, должен бы получить скрипты не с сервера
(где ему, вместо сервера, их может выдать MITM-щик),
а качнуть где-нибудь, например, с того же github'a, в виде архива какого-нибудь.
>>725021
>>725077
Дейтвительно, в случае если скрипты у анона не подменены MITM-щиком,
то MITM-щик в связке (MITM-щик+анон), выдавая себя за анона,
хотя и сможет перехватить и записать шифр,
но он не сможет прочитать данные между аноном и сервером,
но в то же время, он сможет разорвать соединение,
а ещё - подменить байты шифроданных так,
чтобы они херово дешифровались, с ошибками, либо на клиенте, либо на сервере.
Существует ли от этого защита???
Я знаю, что существуют помехоустойчивые коды,
в частности - самокорректирующиеся коды: https://ru.wikipedia.org/wiki/Код_Хэмминга
Но они лишь одиночные биты могут исправлять, а и выявлять ошибки двух бит,
в шумных каналах связи, с помехами.
Если же к данным, дополнительно, клеить хэши или контрольные суммы какие-то, то MITM-щик может подменить и их.
Хотелось бы сделать так.
Если данные успешно дешифрованы, без ошибок, то заебись. Если ошибка, то запрос этих же данных снова.
И сделать это так, чтобы митмщик, на проводе - нихуя не смог накуролесить.
>к серверу может обращаться связка (MITM-щик+анон)
>>725077
>Вышеописанная схема, исключает такую MITM-атаку, даже при наличии MITM-щика.
>MITM-щик не сможет перехватить сами данные, и подменить их
>разве что, он сможет только испортить их или разорвать шифросессию.
Дейтвительно, в случае если скрипты у анона не подменены MITM-щиком,
то MITM-щик в связке (MITM-щик+анон), выдавая себя за анона,
хотя и сможет перехватить и записать шифр,
но он не сможет прочитать данные между аноном и сервером,
но в то же время, он сможет разорвать соединение,
а ещё - подменить байты шифроданных так,
чтобы они херово дешифровались, с ошибками, либо на клиенте, либо на сервере.
Существует ли от этого защита???
Я знаю, что существуют помехоустойчивые коды,
в частности - самокорректирующиеся коды: https://ru.wikipedia.org/wiki/Код_Хэмминга
Но они лишь одиночные биты могут исправлять, а и выявлять ошибки двух бит,
в шумных каналах связи, с помехами.
Если же к данным, дополнительно, клеить хэши или контрольные суммы какие-то, то MITM-щик может подменить и их.
Хотелось бы сделать так.
Если данные успешно дешифрованы, без ошибок, то заебись. Если ошибка, то запрос этих же данных снова.
И сделать это так, чтобы митмщик, на проводе - нихуя не смог накуролесить.
>>726592
А надо их приклеить не к шифру, а к данным и потом - зашифровать их.
>Если же к данным, дополнительно, клеить хэши или контрольные суммы какие-то, то MITM-щик может подменить и их.
А надо их приклеить не к шифру, а к данным и потом - зашифровать их.
>>725077
>>726592
Просто оставлю это здесь:
>Однако, если client-side операции на клиенте, осуществляются при помощи скриптов (например с помощью JavaScript)
>то в связке (MITM-щик+анон), MITM-щик может просто подменить скрипты,
>установить зашифрованную сессию между клиентом и сервером,
>а с самим аноном - взаимодействовать прозрачно, без шифрования.
>Поэтому, очевидно, что клиент, должен бы получить скрипты не с сервера
>(где ему, вместо сервера, их может выдать MITM-щик),
>а качнуть где-нибудь, например, с того же github'a, в виде архива какого-нибудь.
>>726592
>Дейтвительно, в случае если скрипты у анона не подменены MITM-щиком,
>то MITM-щик в связке (MITM-щик+анон), выдавая себя за анона,
>хотя и сможет перехватить и записать шифр,
>но он не сможет прочитать данные между аноном и сервером,
>но в то же время, он сможет разорвать соединение,
>а ещё - подменить байты шифроданных так,
>чтобы они херово дешифровались, с ошибками, либо на клиенте, либо на сервере.
Просто оставлю это здесь:
>>Есть клиент, который заходит на сайт.
>>Сервер сайта вгружает клиенту скрипты.
>>Задача - защитить скрипты от подмены.
>>Пока, ничего лучше атрибута integrity не нашёл: https://ru.stackoverflow.com/a/495788
>>Но значение этого атрибута, хэш, может быть также подменено.
>>
>>Пиздец какой-то. Что делать? Есть решения?
>Как вариант - не отдавать скрипты с сервера, а дать возможность их закачать единожды,
>проверить хэш и цифровую подпись, а потом запускать их на клиенте, и исполнять их - client-side.
>Отдавать по HTTPS, не?
>Или через Tor, с onion-домена.
>Можно также получить EV-сертификат для .onion, вроде
>Но и HTTP может сгодится, т.к. трафик к hidden сервисам на именах в зоне .onion, и так зашифрован.
>Ну и integrity просто всунуть туда, для надёжности, и заебца.
>>725077
>>726592
Просто оставлю это здесь:
>Однако, если client-side операции на клиенте, осуществляются при помощи скриптов (например с помощью JavaScript)
>то в связке (MITM-щик+анон), MITM-щик может просто подменить скрипты,
>установить зашифрованную сессию между клиентом и сервером,
>а с самим аноном - взаимодействовать прозрачно, без шифрования.
>Поэтому, очевидно, что клиент, должен бы получить скрипты не с сервера
>(где ему, вместо сервера, их может выдать MITM-щик),
>а качнуть где-нибудь, например, с того же github'a, в виде архива какого-нибудь.
>>726592
>Дейтвительно, в случае если скрипты у анона не подменены MITM-щиком,
>то MITM-щик в связке (MITM-щик+анон), выдавая себя за анона,
>хотя и сможет перехватить и записать шифр,
>но он не сможет прочитать данные между аноном и сервером,
>но в то же время, он сможет разорвать соединение,
>а ещё - подменить байты шифроданных так,
>чтобы они херово дешифровались, с ошибками, либо на клиенте, либо на сервере.
Просто оставлю это здесь:
>>Есть клиент, который заходит на сайт.
>>Сервер сайта вгружает клиенту скрипты.
>>Задача - защитить скрипты от подмены.
>>Пока, ничего лучше атрибута integrity не нашёл: https://ru.stackoverflow.com/a/495788
>>Но значение этого атрибута, хэш, может быть также подменено.
>>
>>Пиздец какой-то. Что делать? Есть решения?
>Как вариант - не отдавать скрипты с сервера, а дать возможность их закачать единожды,
>проверить хэш и цифровую подпись, а потом запускать их на клиенте, и исполнять их - client-side.
>Отдавать по HTTPS, не?
>Или через Tor, с onion-домена.
>Можно также получить EV-сертификат для .onion, вроде
>Но и HTTP может сгодится, т.к. трафик к hidden сервисам на именах в зоне .onion, и так зашифрован.
>Ну и integrity просто всунуть туда, для надёжности, и заебца.
>>658420 (OP)
У Шнайера, примерно в середине книги "Прикладная криптография", рассматривается способ установки секьюрного соединения без предварительного обмена ключами, защищенный при этом от MITM. Если ты достаточно смелый - можешь реализовать сам.
> Каким ещё образом можно было бы исключить MITM-атаку, при обмене ключами?
У Шнайера, примерно в середине книги "Прикладная криптография", рассматривается способ установки секьюрного соединения без предварительного обмена ключами, защищенный при этом от MITM. Если ты достаточно смелый - можешь реализовать сам.
>>658420 (OP)
Есть всего два варианта решения проблемы:
1. Прешаренный ключ и Envelope Encryption c AEAD. Про подмену сервера ты написал какую-то хуйню оторванную от жизни.
2. PKI (tls, blockchain, whatever).
Оба полагаются на доверие - в первом случае доверие у источнику и транспорту ключей, во втором - к CA или тому что его заменяет. Без доверия задача не решаема, сорян.
Вот тут анон правильно написал - >>664969
Есть всего два варианта решения проблемы:
1. Прешаренный ключ и Envelope Encryption c AEAD. Про подмену сервера ты написал какую-то хуйню оторванную от жизни.
2. PKI (tls, blockchain, whatever).
Оба полагаются на доверие - в первом случае доверие у источнику и транспорту ключей, во втором - к CA или тому что его заменяет. Без доверия задача не решаема, сорян.
Вот тут анон правильно написал - >>664969
>>741419
Где именно, там много букв. Дай ключевое слово и параграф, и ссылку на книгу, а то там - несколько изданий.
>>741441
Что такое Envelope Encryption? Реквестирую годное чтиво об этом. Почему именно Envelope Encryption?
Вижу, что к шифру - клеется MAC, для аутентификации.
Но MAC требует общего ключа и на клиенте и на сервере, а значит надо произвести обмен ключами,
продумав эту схему при наличии MITM-атакера.
Почему же "хуйню, оторванную от жизни"?
Смотри. Пусть есть сервер. И пусть исходный код его открыт. Пусть в код вшит privkey и пусть pubkey, из него полученный будет Pre-shared.
MITM-щик, берёт код, перебивает вшитые ключи на свои, поднимает сервер, подключает его между клиентом и сервером,
и прозрачно ретранслирует запросы от клиента - на реальный сервер, под видом клиента,
а ответы от сервера - клиенту. При этом, MITM-щик может дешифровывать трафик, записывать его, и даже подменять его.
То есть MITM-щик, просто полностью подменяет весь сервер - на свой.
Ну, а тут, MITM-щик может просто подменить pre-shared public key на этапе получения ответа от сервера - клиентом,
так как не клиент, на самом деле получает ответ от сервера, напрямую, а MITM-щик...
Вот в том-то и весь прикол, ведь в связка (сервер <-> anon) может быть в любой момент подменена на (сервер <-> (MITM <-> anon)),
даже изначально. И ни сервер не определит это, ни анон. Потому что сервер попросту не знает нифига, о аноне.
Но здесь: >>724331 была описана схема, которая может исключить возможность MITM-щика,
дешифровать и записывать данные, а также подменять их, но не исключить его наличие.
При этом, клиент остаётся либо полу-анонимным (если на этапе 4 его ключ открытым текстом шлётся на серв), либо анонимным, если он шифруется публичным ключём сервера, и дешифруется приватным на нём.
Единственное что может сделать MITM-щик, при таком раскладе,
так это подменить сам шифр, вызывая ошибки дешифрования, на одной из сторон,
но с таким же успехом, он может подменять биты-байты, при использовании любого другого шифра.
Также, в этой схеме, MITM-щик может подменить скрипты, на этапе их выгрузки клиентом с сервера,
так как, на старте, они могут выгружаться - открытым текстом, а потом уже вся эта шняга,
по генерации ключей, шифрованию-дешифрованию, и так далее - может работать, на них, на скриптах этих.
Ну так вот, чтобы MITM-щик не подменил скрипты, их можно просто повесить в архиве >>739516 с хэшем его,
и выполнять client-side из какого-нибудь html-файла, вместо того, чтобы их выгружать,
и передавать по каналу связи, где может хулиганить MITM-щик.
>У Шнайера, примерно в середине книги "Прикладная криптография", рассматривается способ установки секьюрного соединения без предварительного обмена ключами, защищенный при этом от MITM.
Где именно, там много букв. Дай ключевое слово и параграф, и ссылку на книгу, а то там - несколько изданий.
>>741441
>1. Прешаренный ключ и Envelope Encryption c AEAD.
Что такое Envelope Encryption? Реквестирую годное чтиво об этом. Почему именно Envelope Encryption?
>AEAD
>https://ru.wikipedia.org/wiki/AEAD-режим_блочного_шифрования
Вижу, что к шифру - клеется MAC, для аутентификации.
Но MAC требует общего ключа и на клиенте и на сервере, а значит надо произвести обмен ключами,
продумав эту схему при наличии MITM-атакера.
>Про подмену сервера ты написал какую-то хуйню оторванную от жизни.
Почему же "хуйню, оторванную от жизни"?
Смотри. Пусть есть сервер. И пусть исходный код его открыт. Пусть в код вшит privkey и пусть pubkey, из него полученный будет Pre-shared.
MITM-щик, берёт код, перебивает вшитые ключи на свои, поднимает сервер, подключает его между клиентом и сервером,
и прозрачно ретранслирует запросы от клиента - на реальный сервер, под видом клиента,
а ответы от сервера - клиенту. При этом, MITM-щик может дешифровывать трафик, записывать его, и даже подменять его.
То есть MITM-щик, просто полностью подменяет весь сервер - на свой.
>2. PKI (tls, blockchain, whatever).
Ну, а тут, MITM-щик может просто подменить pre-shared public key на этапе получения ответа от сервера - клиентом,
так как не клиент, на самом деле получает ответ от сервера, напрямую, а MITM-щик...
>Оба полагаются на доверие - в первом случае доверие у источнику и транспорту ключей,
>во втором - к CA или тому что его заменяет. Без доверия задача не решаема, сорян.
Вот в том-то и весь прикол, ведь в связка (сервер <-> anon) может быть в любой момент подменена на (сервер <-> (MITM <-> anon)),
даже изначально. И ни сервер не определит это, ни анон. Потому что сервер попросту не знает нифига, о аноне.
Но здесь: >>724331 была описана схема, которая может исключить возможность MITM-щика,
дешифровать и записывать данные, а также подменять их, но не исключить его наличие.
При этом, клиент остаётся либо полу-анонимным (если на этапе 4 его ключ открытым текстом шлётся на серв), либо анонимным, если он шифруется публичным ключём сервера, и дешифруется приватным на нём.
Единственное что может сделать MITM-щик, при таком раскладе,
так это подменить сам шифр, вызывая ошибки дешифрования, на одной из сторон,
но с таким же успехом, он может подменять биты-байты, при использовании любого другого шифра.
Также, в этой схеме, MITM-щик может подменить скрипты, на этапе их выгрузки клиентом с сервера,
так как, на старте, они могут выгружаться - открытым текстом, а потом уже вся эта шняга,
по генерации ключей, шифрованию-дешифрованию, и так далее - может работать, на них, на скриптах этих.
Ну так вот, чтобы MITM-щик не подменил скрипты, их можно просто повесить в архиве >>739516 с хэшем его,
и выполнять client-side из какого-нибудь html-файла, вместо того, чтобы их выгружать,
и передавать по каналу связи, где может хулиганить MITM-щик.
>>741419
Где именно, там много букв. Дай ключевое слово и параграф, и ссылку на книгу, а то там - несколько изданий.
>>741441
Что такое Envelope Encryption? Реквестирую годное чтиво об этом. Почему именно Envelope Encryption?
Вижу, что к шифру - клеется MAC, для аутентификации.
Но MAC требует общего ключа и на клиенте и на сервере, а значит надо произвести обмен ключами,
продумав эту схему при наличии MITM-атакера.
Почему же "хуйню, оторванную от жизни"?
Смотри. Пусть есть сервер. И пусть исходный код его открыт. Пусть в код вшит privkey и пусть pubkey, из него полученный будет Pre-shared.
MITM-щик, берёт код, перебивает вшитые ключи на свои, поднимает сервер, подключает его между клиентом и сервером,
и прозрачно ретранслирует запросы от клиента - на реальный сервер, под видом клиента,
а ответы от сервера - клиенту. При этом, MITM-щик может дешифровывать трафик, записывать его, и даже подменять его.
То есть MITM-щик, просто полностью подменяет весь сервер - на свой.
Ну, а тут, MITM-щик может просто подменить pre-shared public key на этапе получения ответа от сервера - клиентом,
так как не клиент, на самом деле получает ответ от сервера, напрямую, а MITM-щик...
Вот в том-то и весь прикол, ведь в связка (сервер <-> anon) может быть в любой момент подменена на (сервер <-> (MITM <-> anon)),
даже изначально. И ни сервер не определит это, ни анон. Потому что сервер попросту не знает нифига, о аноне.
Но здесь: >>724331 была описана схема, которая может исключить возможность MITM-щика,
дешифровать и записывать данные, а также подменять их, но не исключить его наличие.
При этом, клиент остаётся либо полу-анонимным (если на этапе 4 его ключ открытым текстом шлётся на серв), либо анонимным, если он шифруется публичным ключём сервера, и дешифруется приватным на нём.
Единственное что может сделать MITM-щик, при таком раскладе,
так это подменить сам шифр, вызывая ошибки дешифрования, на одной из сторон,
но с таким же успехом, он может подменять биты-байты, при использовании любого другого шифра.
Также, в этой схеме, MITM-щик может подменить скрипты, на этапе их выгрузки клиентом с сервера,
так как, на старте, они могут выгружаться - открытым текстом, а потом уже вся эта шняга,
по генерации ключей, шифрованию-дешифрованию, и так далее - может работать, на них, на скриптах этих.
Ну так вот, чтобы MITM-щик не подменил скрипты, их можно просто повесить в архиве >>739516 с хэшем его,
и выполнять client-side из какого-нибудь html-файла, вместо того, чтобы их выгружать,
и передавать по каналу связи, где может хулиганить MITM-щик.
>У Шнайера, примерно в середине книги "Прикладная криптография", рассматривается способ установки секьюрного соединения без предварительного обмена ключами, защищенный при этом от MITM.
Где именно, там много букв. Дай ключевое слово и параграф, и ссылку на книгу, а то там - несколько изданий.
>>741441
>1. Прешаренный ключ и Envelope Encryption c AEAD.
Что такое Envelope Encryption? Реквестирую годное чтиво об этом. Почему именно Envelope Encryption?
>AEAD
>https://ru.wikipedia.org/wiki/AEAD-режим_блочного_шифрования
Вижу, что к шифру - клеется MAC, для аутентификации.
Но MAC требует общего ключа и на клиенте и на сервере, а значит надо произвести обмен ключами,
продумав эту схему при наличии MITM-атакера.
>Про подмену сервера ты написал какую-то хуйню оторванную от жизни.
Почему же "хуйню, оторванную от жизни"?
Смотри. Пусть есть сервер. И пусть исходный код его открыт. Пусть в код вшит privkey и пусть pubkey, из него полученный будет Pre-shared.
MITM-щик, берёт код, перебивает вшитые ключи на свои, поднимает сервер, подключает его между клиентом и сервером,
и прозрачно ретранслирует запросы от клиента - на реальный сервер, под видом клиента,
а ответы от сервера - клиенту. При этом, MITM-щик может дешифровывать трафик, записывать его, и даже подменять его.
То есть MITM-щик, просто полностью подменяет весь сервер - на свой.
>2. PKI (tls, blockchain, whatever).
Ну, а тут, MITM-щик может просто подменить pre-shared public key на этапе получения ответа от сервера - клиентом,
так как не клиент, на самом деле получает ответ от сервера, напрямую, а MITM-щик...
>Оба полагаются на доверие - в первом случае доверие у источнику и транспорту ключей,
>во втором - к CA или тому что его заменяет. Без доверия задача не решаема, сорян.
Вот в том-то и весь прикол, ведь в связка (сервер <-> anon) может быть в любой момент подменена на (сервер <-> (MITM <-> anon)),
даже изначально. И ни сервер не определит это, ни анон. Потому что сервер попросту не знает нифига, о аноне.
Но здесь: >>724331 была описана схема, которая может исключить возможность MITM-щика,
дешифровать и записывать данные, а также подменять их, но не исключить его наличие.
При этом, клиент остаётся либо полу-анонимным (если на этапе 4 его ключ открытым текстом шлётся на серв), либо анонимным, если он шифруется публичным ключём сервера, и дешифруется приватным на нём.
Единственное что может сделать MITM-щик, при таком раскладе,
так это подменить сам шифр, вызывая ошибки дешифрования, на одной из сторон,
но с таким же успехом, он может подменять биты-байты, при использовании любого другого шифра.
Также, в этой схеме, MITM-щик может подменить скрипты, на этапе их выгрузки клиентом с сервера,
так как, на старте, они могут выгружаться - открытым текстом, а потом уже вся эта шняга,
по генерации ключей, шифрованию-дешифрованию, и так далее - может работать, на них, на скриптах этих.
Ну так вот, чтобы MITM-щик не подменил скрипты, их можно просто повесить в архиве >>739516 с хэшем его,
и выполнять client-side из какого-нибудь html-файла, вместо того, чтобы их выгружать,
и передавать по каналу связи, где может хулиганить MITM-щик.
>>742166
Пусть, этот MITM-щик, будет ещё и придурошным.
>>742167
Дело в том, что asymmetric encryption ( https://ru.wikipedia.org/wiki/Криптосистема_с_открытым_ключом )
работает с двумя ключами - публичным и приватным,
и на серверной части, цифровая подпись данных и шифрование/дешифрование их,
производятся приватным ключём (privkey), с помощью алгоритмов, функций и методов, код которых открыт.
Поэтому, поначалу, мне подумалось, что именно поэтому,
для того чтобы сделать pre-shared public key,
надо вшить в код и сам privkey, а потом уже повесить хэш всего кода, в виде открытого исходника.
Но действительно, privkey может быть выгружен из файла, а pubkey - захардкожен, плюс код и хэш кода - в публичный доступ.
Но будет ли это опенсорц тогда, или же какая-то проприетарная хуйня?
Ясное дело, что если MITM-щик сменить pubkey, то сразу же - сменится и хэш кода.
>вместо того, чтобы их выгружать, и передавать по каналу связи, где может хулиганить MITM-щик
Пусть, этот MITM-щик, будет ещё и придурошным.
>>742167
>Нахуя?
Дело в том, что asymmetric encryption ( https://ru.wikipedia.org/wiki/Криптосистема_с_открытым_ключом )
работает с двумя ключами - публичным и приватным,
и на серверной части, цифровая подпись данных и шифрование/дешифрование их,
производятся приватным ключём (privkey), с помощью алгоритмов, функций и методов, код которых открыт.
Поэтому, поначалу, мне подумалось, что именно поэтому,
для того чтобы сделать pre-shared public key,
надо вшить в код и сам privkey, а потом уже повесить хэш всего кода, в виде открытого исходника.
Но действительно, privkey может быть выгружен из файла, а pubkey - захардкожен, плюс код и хэш кода - в публичный доступ.
Но будет ли это опенсорц тогда, или же какая-то проприетарная хуйня?
Ясное дело, что если MITM-щик сменить pubkey, то сразу же - сменится и хэш кода.
>>741419
Где имено рассматривается, в какой книге, какого издания, в какой главе и параграфе?
>У Шнайера, примерно в середине книги "Прикладная криптография", рассматривается способ установки секьюрного соединения без предварительного обмена ключами, защищенный при этом от MITM. Если ты достаточно смелый - можешь реализовать сам.
Где имено рассматривается, в какой книге, какого издания, в какой главе и параграфе?
>>741419
Если ты имел в виду главу 2.7 на странице 45, отсюда: http://www.dut.edu.ua/uploads/l_1134_27449793.pdf
то это можно реализовать с помощью pgp: https://username1565.github.io/pgp/
Ведь там можно и подписывать и шифровать с помощью RSA-ключей.
Но я, опять же, повторюсь, и скажу следующее...
Для работы этой схемы, и Алиса и Боб, должны:
во-первых, заранее сгенерировать private keys,
и во-вторых, их public keys должны быть pre-shared public keys.
То есть, Алиса, должна знать заранее - публичный ключ Боба (чтобы ним шифровать сообщение, подписанное ею),
а Боб - дожен знать публичный ключ Алисы (чтобы проверить её цифровую подпись).
То есть и Алиса с Бобом, должны обменяться ключами, перед установкой соединения.
А между ними - MITM-атакер, Кэрол.
Она может подменить их ключи, а следовательно, перехватить данные, и даже подменить их. И в этом проблема.
Более того, даже если ключи не подменены, но перехвачены,
приватные ключи Алисы и Боба, жестко соответствуют переданным ключам публичным, а это делает подобную схему - не анонимной.
Поскольку Кэрол, как MITM-щик, может устроить физическую или хакерскую атаку на железо Алисы, или Боба,
вытащить из их памяти приватные ключи, и зная их публичные ключи, проверить соответствие приватных ключей - публичным,
и так задеанонить либо Алису, либо Боба, ещё и дешифруя ихнюю переписку, при помощи приватных ключей.
Схема же, предложенная здесь: >>724331
реализует некую полу-анонимность (возможен деанон лишь в течении сессии, из-за регулярной перегенерации ключа анонимного клиента),
и эта полу-анонимность имеет место быть, только если в пункте 4, ClientPublicKey передаётся по открытому каналу, и его можно перехватить.
Если же, на этом этапе, всё это дело зашифровать публичным ключём сервера,
то перехватить значение ClientPublicKey, в открытом канале, MITM-атакер не сможет,
а значит он не сможет задеанонить клиента в течении сессии, и клиент, останется - полностью "анонимным".
Ясное дело, что эта "анонимность", анонимна до тех пор, пока MITM-атакер не взломал ServerPublicKey
(брутфорсом, скажем, или же физическим взломом, после trace route, например),
ведь тогда, станет возможным, устроить физическую атаку на клиента,
и затем задеанонить его, зная сессионный - публичный ключ его,
расшифрованный взломанным, и известным уже, приватным ключём сервера - ServerPublicKey.
И чтобы такой хуйни не было, сервер можно попросту вывесить - в TOR'e, на onion-домене,
где трафик ещё и дополнительно шифруется.
Такие дела.
Если ты имел в виду главу 2.7 на странице 45, отсюда: http://www.dut.edu.ua/uploads/l_1134_27449793.pdf
то это можно реализовать с помощью pgp: https://username1565.github.io/pgp/
Ведь там можно и подписывать и шифровать с помощью RSA-ключей.
Но я, опять же, повторюсь, и скажу следующее...
Для работы этой схемы, и Алиса и Боб, должны:
во-первых, заранее сгенерировать private keys,
и во-вторых, их public keys должны быть pre-shared public keys.
То есть, Алиса, должна знать заранее - публичный ключ Боба (чтобы ним шифровать сообщение, подписанное ею),
а Боб - дожен знать публичный ключ Алисы (чтобы проверить её цифровую подпись).
То есть и Алиса с Бобом, должны обменяться ключами, перед установкой соединения.
А между ними - MITM-атакер, Кэрол.
Она может подменить их ключи, а следовательно, перехватить данные, и даже подменить их. И в этом проблема.
Более того, даже если ключи не подменены, но перехвачены,
приватные ключи Алисы и Боба, жестко соответствуют переданным ключам публичным, а это делает подобную схему - не анонимной.
Поскольку Кэрол, как MITM-щик, может устроить физическую или хакерскую атаку на железо Алисы, или Боба,
вытащить из их памяти приватные ключи, и зная их публичные ключи, проверить соответствие приватных ключей - публичным,
и так задеанонить либо Алису, либо Боба, ещё и дешифруя ихнюю переписку, при помощи приватных ключей.
Схема же, предложенная здесь: >>724331
реализует некую полу-анонимность (возможен деанон лишь в течении сессии, из-за регулярной перегенерации ключа анонимного клиента),
и эта полу-анонимность имеет место быть, только если в пункте 4, ClientPublicKey передаётся по открытому каналу, и его можно перехватить.
Если же, на этом этапе, всё это дело зашифровать публичным ключём сервера,
то перехватить значение ClientPublicKey, в открытом канале, MITM-атакер не сможет,
а значит он не сможет задеанонить клиента в течении сессии, и клиент, останется - полностью "анонимным".
Ясное дело, что эта "анонимность", анонимна до тех пор, пока MITM-атакер не взломал ServerPublicKey
(брутфорсом, скажем, или же физическим взломом, после trace route, например),
ведь тогда, станет возможным, устроить физическую атаку на клиента,
и затем задеанонить его, зная сессионный - публичный ключ его,
расшифрованный взломанным, и известным уже, приватным ключём сервера - ServerPublicKey.
И чтобы такой хуйни не было, сервер можно попросту вывесить - в TOR'e, на onion-домене,
где трафик ещё и дополнительно шифруется.
Такие дела.
>>741419
Если ты имел в виду главу 2.7 на странице 45, отсюда: http://www.dut.edu.ua/uploads/l_1134_27449793.pdf
то это можно реализовать с помощью pgp: https://username1565.github.io/pgp/
Ведь там можно и подписывать и шифровать с помощью RSA-ключей.
Но я, опять же, повторюсь, и скажу следующее...
Для работы этой схемы, и Алиса и Боб, должны:
во-первых, заранее сгенерировать private keys,
и во-вторых, их public keys должны быть pre-shared public keys.
То есть, Алиса, должна знать заранее - публичный ключ Боба (чтобы ним шифровать сообщение, подписанное ею),
а Боб - дожен знать публичный ключ Алисы (чтобы проверить её цифровую подпись).
То есть и Алиса с Бобом, должны обменяться ключами, перед установкой соединения.
А между ними - MITM-атакер, Кэрол.
Она может подменить их ключи, а следовательно, перехватить данные, и даже подменить их. И в этом проблема.
Более того, даже если ключи не подменены, но перехвачены,
приватные ключи Алисы и Боба, жестко соответствуют переданным ключам публичным, а это делает подобную схему - не анонимной.
Поскольку Кэрол, как MITM-щик, может устроить физическую или хакерскую атаку на железо Алисы, или Боба,
вытащить из их памяти приватные ключи, и зная их публичные ключи, проверить соответствие приватных ключей - публичным,
и так задеанонить либо Алису, либо Боба, ещё и дешифруя ихнюю переписку, при помощи приватных ключей.
Схема же, предложенная здесь: >>724331
реализует некую полу-анонимность (возможен деанон лишь в течении сессии, из-за регулярной перегенерации ключа анонимного клиента),
и эта полу-анонимность имеет место быть, только если в пункте 4, ClientPublicKey передаётся по открытому каналу, и его можно перехватить.
Если же, на этом этапе, всё это дело зашифровать публичным ключём сервера,
то перехватить значение ClientPublicKey, в открытом канале, MITM-атакер не сможет,
а значит он не сможет задеанонить клиента в течении сессии, и клиент, останется - полностью "анонимным".
Ясное дело, что эта "анонимность", анонимна до тех пор, пока MITM-атакер не взломал ServerPublicKey
(брутфорсом, скажем, или же физическим взломом, после trace route, например),
ведь тогда, станет возможным, устроить физическую атаку на клиента,
и затем задеанонить его, зная сессионный - публичный ключ его,
расшифрованный взломанным, и известным уже, приватным ключём сервера - ServerPublicKey.
И чтобы такой хуйни не было, сервер можно попросту вывесить - в TOR'e, на onion-домене,
где трафик ещё и дополнительно шифруется.
Такие дела.
Если ты имел в виду главу 2.7 на странице 45, отсюда: http://www.dut.edu.ua/uploads/l_1134_27449793.pdf
то это можно реализовать с помощью pgp: https://username1565.github.io/pgp/
Ведь там можно и подписывать и шифровать с помощью RSA-ключей.
Но я, опять же, повторюсь, и скажу следующее...
Для работы этой схемы, и Алиса и Боб, должны:
во-первых, заранее сгенерировать private keys,
и во-вторых, их public keys должны быть pre-shared public keys.
То есть, Алиса, должна знать заранее - публичный ключ Боба (чтобы ним шифровать сообщение, подписанное ею),
а Боб - дожен знать публичный ключ Алисы (чтобы проверить её цифровую подпись).
То есть и Алиса с Бобом, должны обменяться ключами, перед установкой соединения.
А между ними - MITM-атакер, Кэрол.
Она может подменить их ключи, а следовательно, перехватить данные, и даже подменить их. И в этом проблема.
Более того, даже если ключи не подменены, но перехвачены,
приватные ключи Алисы и Боба, жестко соответствуют переданным ключам публичным, а это делает подобную схему - не анонимной.
Поскольку Кэрол, как MITM-щик, может устроить физическую или хакерскую атаку на железо Алисы, или Боба,
вытащить из их памяти приватные ключи, и зная их публичные ключи, проверить соответствие приватных ключей - публичным,
и так задеанонить либо Алису, либо Боба, ещё и дешифруя ихнюю переписку, при помощи приватных ключей.
Схема же, предложенная здесь: >>724331
реализует некую полу-анонимность (возможен деанон лишь в течении сессии, из-за регулярной перегенерации ключа анонимного клиента),
и эта полу-анонимность имеет место быть, только если в пункте 4, ClientPublicKey передаётся по открытому каналу, и его можно перехватить.
Если же, на этом этапе, всё это дело зашифровать публичным ключём сервера,
то перехватить значение ClientPublicKey, в открытом канале, MITM-атакер не сможет,
а значит он не сможет задеанонить клиента в течении сессии, и клиент, останется - полностью "анонимным".
Ясное дело, что эта "анонимность", анонимна до тех пор, пока MITM-атакер не взломал ServerPublicKey
(брутфорсом, скажем, или же физическим взломом, после trace route, например),
ведь тогда, станет возможным, устроить физическую атаку на клиента,
и затем задеанонить его, зная сессионный - публичный ключ его,
расшифрованный взломанным, и известным уже, приватным ключём сервера - ServerPublicKey.
И чтобы такой хуйни не было, сервер можно попросту вывесить - в TOR'e, на onion-домене,
где трафик ещё и дополнительно шифруется.
Такие дела.
>>742179
На самом деле, MITM-щиков может быть овер-дохера,
пиздатые каскады и целые пирамиды из MITM-щиков,
каждый из которых может быть ебанутым на всю головушку,
и они могут автоматически MITM-ать даже другие MITM-ы,
в нелепой конкуренции за то, кто быстрее и энергоэффективнее, сMITM'мит, всю-всю инфу.
>Пусть, этот MITM-щик, будет ещё и придурошным.
На самом деле, MITM-щиков может быть овер-дохера,
пиздатые каскады и целые пирамиды из MITM-щиков,
каждый из которых может быть ебанутым на всю головушку,
и они могут автоматически MITM-ать даже другие MITM-ы,
в нелепой конкуренции за то, кто быстрее и энергоэффективнее, сMITM'мит, всю-всю инфу.
>>658420 (OP)
>>667552
Может, Шифр Шамира? Вот описание протокола: https://ru.wikipedia.org/wiki/Протокол_Шамира
Но тут, стороны A и B, они вообще ничего не знают друг о друге, с самого начала.
>>667552
>Если нету общего секрета, то решить задачу невозможно.
Может, Шифр Шамира? Вот описание протокола: https://ru.wikipedia.org/wiki/Протокол_Шамира
Но тут, стороны A и B, они вообще ничего не знают друг о друге, с самого начала.
>>755674
Так-так... Если A и B ничего не знают друг о друге,
то зачем MITM-щику перехватывать их данные,
и пытаться что-то там дискретно логарифмировать,
если он может просто стать посреди A <-> B?
Получится что-то вроде A <-> MITM <-> B,
где A <-> B', и B' - это (MITM <-> B), и по факту A <-> (MITM <-> B),
и наоборот, A' <-> B, и A' - это (A <-> MITM), и по факту (A <-> MITM) <-> B...
Ни A ни B, они же ничего не знают друг о друге,
и B может общаться как с A напрямую, так и с A' (где сидит MITM-щик)
и наоборот, A может общаться как с B напрямую, так и с B' (где сидит MITM-щик).
Так-так... Если A и B ничего не знают друг о друге,
то зачем MITM-щику перехватывать их данные,
и пытаться что-то там дискретно логарифмировать,
если он может просто стать посреди A <-> B?
Получится что-то вроде A <-> MITM <-> B,
где A <-> B', и B' - это (MITM <-> B), и по факту A <-> (MITM <-> B),
и наоборот, A' <-> B, и A' - это (A <-> MITM), и по факту (A <-> MITM) <-> B...
Ни A ни B, они же ничего не знают друг о друге,
и B может общаться как с A напрямую, так и с A' (где сидит MITM-щик)
и наоборот, A может общаться как с B напрямую, так и с B' (где сидит MITM-щик).
>>658420 (OP)
Вопрос к формулировке "есть клиент с браузером".
Если под браузером понимать web-браузер, то единственная возможность установить начальное соединение с сервером - это http(s). Самый смак в том, что классический ход работы браузера - это "получить код от сервера -> исполнить его", что при MITM-атаке позволяет делать намного более интересные вещи, чем перехват данных, т.к. может подсунуть браузеру вообще любой код. Для защиты используем классические же средства браузера (см https, сертификаты и далее по списку). Если злоумышленник смог их поломать - штош, у тебя большие проблемы, которые скрипт, отдаваемый твоим сервером, не решит (он просто не доберется до клиента, лол).
Если под браузером понимать вообде любую программу, которая коннектится к твоему серверу по tcp/udp, то клиенту для начала работы нужно, опять же:
а. получить бинарь;
б. получить инфу о сервере (как минимум айпишник или домен).
Аналогично, при передаче этих данных по незащищенному каналу злоумышленник может подменить их на любые другие, и клиент об этом не узнает, т.к. канал незащищенный.
А вот при передаче данных по защищенному каналу или по каналу, который злоумышленник может только прослушать (пр.: сорцы выложены на условный гитлаб, доступ к которому можно получить по различным каналам), можно уже поиграться с криптографией: например, передавать клиенту помимо адреса еще и открытый ключ сервера. Ну и дальше уже выстраивать протокол по науке.
Понятно, что закрытый ключ сервера нужно держать в тайне будь исходный код сервера открыт или закрыт.
Вот, вроде рассмотрел все возможные случаи и ничего не упустил.
Вопрос к формулировке "есть клиент с браузером".
Если под браузером понимать web-браузер, то единственная возможность установить начальное соединение с сервером - это http(s). Самый смак в том, что классический ход работы браузера - это "получить код от сервера -> исполнить его", что при MITM-атаке позволяет делать намного более интересные вещи, чем перехват данных, т.к. может подсунуть браузеру вообще любой код. Для защиты используем классические же средства браузера (см https, сертификаты и далее по списку). Если злоумышленник смог их поломать - штош, у тебя большие проблемы, которые скрипт, отдаваемый твоим сервером, не решит (он просто не доберется до клиента, лол).
Если под браузером понимать вообде любую программу, которая коннектится к твоему серверу по tcp/udp, то клиенту для начала работы нужно, опять же:
а. получить бинарь;
б. получить инфу о сервере (как минимум айпишник или домен).
Аналогично, при передаче этих данных по незащищенному каналу злоумышленник может подменить их на любые другие, и клиент об этом не узнает, т.к. канал незащищенный.
А вот при передаче данных по защищенному каналу или по каналу, который злоумышленник может только прослушать (пр.: сорцы выложены на условный гитлаб, доступ к которому можно получить по различным каналам), можно уже поиграться с криптографией: например, передавать клиенту помимо адреса еще и открытый ключ сервера. Ну и дальше уже выстраивать протокол по науке.
Понятно, что закрытый ключ сервера нужно держать в тайне будь исходный код сервера открыт или закрыт.
Вот, вроде рассмотрел все возможные случаи и ничего не упустил.
>>768638
Мне почему-то кажется,
что если, на сервере, использовать,
один и тот же privkey и соответствующий ему pre-shared public-key (который может быть перехвачен),
и если этим сверхсекретным privkey'ем,
шифровать и подписывать много разных данных,
то перехват этих зашифрованных и подписанных данных,
позволит сбрутфорсить privkey прямым перебором,
но не простым, а оптимизированным,
например методом ветвей и границ, или методом последовательных приближений как-то,
а критерием успешного подбора privkey'я,
может служить просто его соотстветствие pre-shared public-key'ю, который открыт, и известен злоумышленнику.
Вот, например, атаки на RSA: http://algolist.ru/defence/attack/rsa.php
Чем больше разношёрстных шифров шлётся, подписанных и зашифрованных одним и тем же привкеем,
тем больше вероятность его сбрутить и сломать,
приложив достаточное количество вычислительных мощностей...
Поэтому, по идее, privkey и pre-shared-public-key,
их тоже надо бы менять, на сервере,
хотя-бы периодически,
чтобы усложнить подобного рода атаки,
и сделать их энергетически и экономически нецелесообразными.
Но, здесь встаёт вопрос о том, как же передать новый pre-shared-public-key именно в клиенту,
чтобы MITM-щик не подменил его на свой.
Такие дела.
Мне почему-то кажется,
что если, на сервере, использовать,
один и тот же privkey и соответствующий ему pre-shared public-key (который может быть перехвачен),
и если этим сверхсекретным privkey'ем,
шифровать и подписывать много разных данных,
то перехват этих зашифрованных и подписанных данных,
позволит сбрутфорсить privkey прямым перебором,
но не простым, а оптимизированным,
например методом ветвей и границ, или методом последовательных приближений как-то,
а критерием успешного подбора privkey'я,
может служить просто его соотстветствие pre-shared public-key'ю, который открыт, и известен злоумышленнику.
Вот, например, атаки на RSA: http://algolist.ru/defence/attack/rsa.php
Чем больше разношёрстных шифров шлётся, подписанных и зашифрованных одним и тем же привкеем,
тем больше вероятность его сбрутить и сломать,
приложив достаточное количество вычислительных мощностей...
Поэтому, по идее, privkey и pre-shared-public-key,
их тоже надо бы менять, на сервере,
хотя-бы периодически,
чтобы усложнить подобного рода атаки,
и сделать их энергетически и экономически нецелесообразными.
Но, здесь встаёт вопрос о том, как же передать новый pre-shared-public-key именно в клиенту,
чтобы MITM-щик не подменил его на свой.
Такие дела.
>>768638
Мне почему-то кажется,
что если, на сервере, использовать,
один и тот же privkey и соответствующий ему pre-shared public-key (который может быть перехвачен),
и если этим сверхсекретным privkey'ем,
шифровать и подписывать много разных данных,
то перехват этих зашифрованных и подписанных данных,
позволит сбрутфорсить privkey прямым перебором,
но не простым, а оптимизированным,
например методом ветвей и границ, или методом последовательных приближений как-то,
а критерием успешного подбора privkey'я,
может служить просто его соотстветствие pre-shared public-key'ю, который открыт, и известен злоумышленнику.
Вот, например, атаки на RSA: http://algolist.ru/defence/attack/rsa.php
Чем больше разношёрстных шифров шлётся, подписанных и зашифрованных одним и тем же привкеем,
тем больше вероятность его сбрутить и сломать,
приложив достаточное количество вычислительных мощностей...
Поэтому, по идее, privkey и pre-shared-public-key,
их тоже надо бы менять, на сервере,
хотя-бы периодически,
чтобы усложнить подобного рода атаки,
и сделать их энергетически и экономически нецелесообразными.
Но, здесь встаёт вопрос о том, как же передать новый pre-shared-public-key именно в клиенту,
чтобы MITM-щик не подменил его на свой.
Такие дела.
Мне почему-то кажется,
что если, на сервере, использовать,
один и тот же privkey и соответствующий ему pre-shared public-key (который может быть перехвачен),
и если этим сверхсекретным privkey'ем,
шифровать и подписывать много разных данных,
то перехват этих зашифрованных и подписанных данных,
позволит сбрутфорсить privkey прямым перебором,
но не простым, а оптимизированным,
например методом ветвей и границ, или методом последовательных приближений как-то,
а критерием успешного подбора privkey'я,
может служить просто его соотстветствие pre-shared public-key'ю, который открыт, и известен злоумышленнику.
Вот, например, атаки на RSA: http://algolist.ru/defence/attack/rsa.php
Чем больше разношёрстных шифров шлётся, подписанных и зашифрованных одним и тем же привкеем,
тем больше вероятность его сбрутить и сломать,
приложив достаточное количество вычислительных мощностей...
Поэтому, по идее, privkey и pre-shared-public-key,
их тоже надо бы менять, на сервере,
хотя-бы периодически,
чтобы усложнить подобного рода атаки,
и сделать их энергетически и экономически нецелесообразными.
Но, здесь встаёт вопрос о том, как же передать новый pre-shared-public-key именно в клиенту,
чтобы MITM-щик не подменил его на свой.
Такие дела.
>>658420 (OP)
Ну чё там, есть какие-нить прорывы в технологиях анонимной аутентификации?
Ну чё там, есть какие-нить прорывы в технологиях анонимной аутентификации?
>>838276
ПОПРОБУЙТЕ ЗА-MITM-АТЬ ЭТУ ПОЕБНЮ:
0. Сервер:
Однократно генерирует два ключа RSA:
ServerPriv (сохраняет в секрете) и ServerPub - публикует в открытый доступ.
1. Клиент:
Хочет установить соединение.
Генерирует два новых ключа RSA. ClientPriv (сохраняет в секрете) и ClientPub.
EncryptedClientPub = RSAEncrypt(ClientPub, ServerPub);
SignedEncryptedClientPub = RSAEncrypt(EncryptedClientPub, ClientPriv); //подписывает сообщение приватным ключем
(EncryptedClientPub, SignedEncryptedClientPub) -> отправляет на Сервер зашифрованное сообщение и цифровую подпись.
Без первого, Сервер не получит пабкей клиента.
2. Сервер:
Принимает (EncryptedClientPub, SignedEncryptedClientPub) от клиента.
ClientPub = RSADecrypt(EncryptedClientPub, ServerPriv);
EncryptedClientPub2 = RSADecrypt(SignedEncryptedClientPub, ClientPub);
(EncryptedClientPub2 == EncryptedClientPub) //true - ClientPub OK, false - ClientPub - NOT OK.
Генерирует SymmetricKey;
EncryptedKey = RSAEncrypt(RSAEncrypt(SymmetricKey, ClientPub), ServerPriv); //шифрует публичным ключем клиента, и подписывает приватным ключем сервера
EncryptedKey -> отправляет клиенту только подпись, зашифрованное сообщение не обязательно, у клиента уже есть пабкей сервера.
3. Клиент:
SymmetricKey = RSADecrypt(RSADecrypt(EncryptedKey, ClientPriv), ServerPub); //извлекает зашифрованное сообщение из подписи и дешифрует его в SymmetricKey.
Дальше, уже, и клиент и сервер, имея общий SymmetricKey,
синхронно шифруют-дешифруют трафик, при помощи SymmetricKey,
Каким-нибудь Rijndael (AES), или Salsa20,
а лучше - Шифром Вернама, обладающим доказанной - абсолютной криптостойкостью.
Эта схема - полуанонимна. Сервер можно задеанонить по наличию приватного ключа на его железе.
Клиента, можно задеанонить только в течении сессии, если получить доступ к серверу, и узнать пабкей клиента (а ещё его сделать trace route для его IP).
Пабкей сервера - прешаренный, известен клиенту заранее, поэтому MITM-щик не может его подменить, пушо будет палево тогда.
На этапе 1, при каждом новом соединении с сервером, клиент генерирует, каждый раз - разные ключи, сохраняя таким образом свою анонимность.
Клиент не шлёт свой паб-кей открыто на сервер, чтобы клиента нельзя было задеанонить,
по наличию приватника на железе клиента, соответствующего - публичному ключу клиента.
Только сервер знает (если, конечно, с сервера, не спиздили приватник, лол),
актуальный на данный момент - публичный ключ клиента,
который сразу же теряет актуальность, при разрыве соединения,
так как при новом соединении, ключи клиента - перегенерируются.
Если MITM-щик присунется под видом клиента на этапе 1, и сунет СВОЙ пабкей серверу,
то реальный клиент не сможет дешифровать своим приватным ключем, SymmetricKey сервера, а только MITM-щик.
MITM-щик же, не сможет подписать зашифрованный SymmetricKey, без ClientPub (который открыто не передаётся), и уж тем более - без ServerPriv.
Но...
При большом количестве перехваченных значений EncryptedKey, при постоянных ServerPriv и ServerPub,
наверняка, можно будет, в долгосроке, подобрать ServerPriv, по известному ServerPub,
каким-нибудь брутфорсом, или квантовой факторизацией алгоритмом Шора...
Если же сервер будет регулярно менять ключи ServerPriv и ServerPub,
то ServerPub уже не будет pre-shared, и MITM-щик,
может просто сунуть свои ключи, при следующем обновлении. Лол.
ПОПРОБУЙТЕ ЗА-MITM-АТЬ ЭТУ ПОЕБНЮ:
0. Сервер:
Однократно генерирует два ключа RSA:
ServerPriv (сохраняет в секрете) и ServerPub - публикует в открытый доступ.
1. Клиент:
Хочет установить соединение.
Генерирует два новых ключа RSA. ClientPriv (сохраняет в секрете) и ClientPub.
EncryptedClientPub = RSAEncrypt(ClientPub, ServerPub);
SignedEncryptedClientPub = RSAEncrypt(EncryptedClientPub, ClientPriv); //подписывает сообщение приватным ключем
(EncryptedClientPub, SignedEncryptedClientPub) -> отправляет на Сервер зашифрованное сообщение и цифровую подпись.
Без первого, Сервер не получит пабкей клиента.
2. Сервер:
Принимает (EncryptedClientPub, SignedEncryptedClientPub) от клиента.
ClientPub = RSADecrypt(EncryptedClientPub, ServerPriv);
EncryptedClientPub2 = RSADecrypt(SignedEncryptedClientPub, ClientPub);
(EncryptedClientPub2 == EncryptedClientPub) //true - ClientPub OK, false - ClientPub - NOT OK.
Генерирует SymmetricKey;
EncryptedKey = RSAEncrypt(RSAEncrypt(SymmetricKey, ClientPub), ServerPriv); //шифрует публичным ключем клиента, и подписывает приватным ключем сервера
EncryptedKey -> отправляет клиенту только подпись, зашифрованное сообщение не обязательно, у клиента уже есть пабкей сервера.
3. Клиент:
SymmetricKey = RSADecrypt(RSADecrypt(EncryptedKey, ClientPriv), ServerPub); //извлекает зашифрованное сообщение из подписи и дешифрует его в SymmetricKey.
Дальше, уже, и клиент и сервер, имея общий SymmetricKey,
синхронно шифруют-дешифруют трафик, при помощи SymmetricKey,
Каким-нибудь Rijndael (AES), или Salsa20,
а лучше - Шифром Вернама, обладающим доказанной - абсолютной криптостойкостью.
Эта схема - полуанонимна. Сервер можно задеанонить по наличию приватного ключа на его железе.
Клиента, можно задеанонить только в течении сессии, если получить доступ к серверу, и узнать пабкей клиента (а ещё его сделать trace route для его IP).
Пабкей сервера - прешаренный, известен клиенту заранее, поэтому MITM-щик не может его подменить, пушо будет палево тогда.
На этапе 1, при каждом новом соединении с сервером, клиент генерирует, каждый раз - разные ключи, сохраняя таким образом свою анонимность.
Клиент не шлёт свой паб-кей открыто на сервер, чтобы клиента нельзя было задеанонить,
по наличию приватника на железе клиента, соответствующего - публичному ключу клиента.
Только сервер знает (если, конечно, с сервера, не спиздили приватник, лол),
актуальный на данный момент - публичный ключ клиента,
который сразу же теряет актуальность, при разрыве соединения,
так как при новом соединении, ключи клиента - перегенерируются.
Если MITM-щик присунется под видом клиента на этапе 1, и сунет СВОЙ пабкей серверу,
то реальный клиент не сможет дешифровать своим приватным ключем, SymmetricKey сервера, а только MITM-щик.
MITM-щик же, не сможет подписать зашифрованный SymmetricKey, без ClientPub (который открыто не передаётся), и уж тем более - без ServerPriv.
Но...
При большом количестве перехваченных значений EncryptedKey, при постоянных ServerPriv и ServerPub,
наверняка, можно будет, в долгосроке, подобрать ServerPriv, по известному ServerPub,
каким-нибудь брутфорсом, или квантовой факторизацией алгоритмом Шора...
Если же сервер будет регулярно менять ключи ServerPriv и ServerPub,
то ServerPub уже не будет pre-shared, и MITM-щик,
может просто сунуть свои ключи, при следующем обновлении. Лол.
>>838276
ПОПРОБУЙТЕ ЗА-MITM-АТЬ ЭТУ ПОЕБНЮ:
0. Сервер:
Однократно генерирует два ключа RSA:
ServerPriv (сохраняет в секрете) и ServerPub - публикует в открытый доступ.
1. Клиент:
Хочет установить соединение.
Генерирует два новых ключа RSA. ClientPriv (сохраняет в секрете) и ClientPub.
EncryptedClientPub = RSAEncrypt(ClientPub, ServerPub);
SignedEncryptedClientPub = RSAEncrypt(EncryptedClientPub, ClientPriv); //подписывает сообщение приватным ключем
(EncryptedClientPub, SignedEncryptedClientPub) -> отправляет на Сервер зашифрованное сообщение и цифровую подпись.
Без первого, Сервер не получит пабкей клиента.
2. Сервер:
Принимает (EncryptedClientPub, SignedEncryptedClientPub) от клиента.
ClientPub = RSADecrypt(EncryptedClientPub, ServerPriv);
EncryptedClientPub2 = RSADecrypt(SignedEncryptedClientPub, ClientPub);
(EncryptedClientPub2 == EncryptedClientPub) //true - ClientPub OK, false - ClientPub - NOT OK.
Генерирует SymmetricKey;
EncryptedKey = RSAEncrypt(RSAEncrypt(SymmetricKey, ClientPub), ServerPriv); //шифрует публичным ключем клиента, и подписывает приватным ключем сервера
EncryptedKey -> отправляет клиенту только подпись, зашифрованное сообщение не обязательно, у клиента уже есть пабкей сервера.
3. Клиент:
SymmetricKey = RSADecrypt(RSADecrypt(EncryptedKey, ClientPriv), ServerPub); //извлекает зашифрованное сообщение из подписи и дешифрует его в SymmetricKey.
Дальше, уже, и клиент и сервер, имея общий SymmetricKey,
синхронно шифруют-дешифруют трафик, при помощи SymmetricKey,
Каким-нибудь Rijndael (AES), или Salsa20,
а лучше - Шифром Вернама, обладающим доказанной - абсолютной криптостойкостью.
Эта схема - полуанонимна. Сервер можно задеанонить по наличию приватного ключа на его железе.
Клиента, можно задеанонить только в течении сессии, если получить доступ к серверу, и узнать пабкей клиента (а ещё его сделать trace route для его IP).
Пабкей сервера - прешаренный, известен клиенту заранее, поэтому MITM-щик не может его подменить, пушо будет палево тогда.
На этапе 1, при каждом новом соединении с сервером, клиент генерирует, каждый раз - разные ключи, сохраняя таким образом свою анонимность.
Клиент не шлёт свой паб-кей открыто на сервер, чтобы клиента нельзя было задеанонить,
по наличию приватника на железе клиента, соответствующего - публичному ключу клиента.
Только сервер знает (если, конечно, с сервера, не спиздили приватник, лол),
актуальный на данный момент - публичный ключ клиента,
который сразу же теряет актуальность, при разрыве соединения,
так как при новом соединении, ключи клиента - перегенерируются.
Если MITM-щик присунется под видом клиента на этапе 1, и сунет СВОЙ пабкей серверу,
то реальный клиент не сможет дешифровать своим приватным ключем, SymmetricKey сервера, а только MITM-щик.
MITM-щик же, не сможет подписать зашифрованный SymmetricKey, без ClientPub (который открыто не передаётся), и уж тем более - без ServerPriv.
Но...
При большом количестве перехваченных значений EncryptedKey, при постоянных ServerPriv и ServerPub,
наверняка, можно будет, в долгосроке, подобрать ServerPriv, по известному ServerPub,
каким-нибудь брутфорсом, или квантовой факторизацией алгоритмом Шора...
Если же сервер будет регулярно менять ключи ServerPriv и ServerPub,
то ServerPub уже не будет pre-shared, и MITM-щик,
может просто сунуть свои ключи, при следующем обновлении. Лол.
ПОПРОБУЙТЕ ЗА-MITM-АТЬ ЭТУ ПОЕБНЮ:
0. Сервер:
Однократно генерирует два ключа RSA:
ServerPriv (сохраняет в секрете) и ServerPub - публикует в открытый доступ.
1. Клиент:
Хочет установить соединение.
Генерирует два новых ключа RSA. ClientPriv (сохраняет в секрете) и ClientPub.
EncryptedClientPub = RSAEncrypt(ClientPub, ServerPub);
SignedEncryptedClientPub = RSAEncrypt(EncryptedClientPub, ClientPriv); //подписывает сообщение приватным ключем
(EncryptedClientPub, SignedEncryptedClientPub) -> отправляет на Сервер зашифрованное сообщение и цифровую подпись.
Без первого, Сервер не получит пабкей клиента.
2. Сервер:
Принимает (EncryptedClientPub, SignedEncryptedClientPub) от клиента.
ClientPub = RSADecrypt(EncryptedClientPub, ServerPriv);
EncryptedClientPub2 = RSADecrypt(SignedEncryptedClientPub, ClientPub);
(EncryptedClientPub2 == EncryptedClientPub) //true - ClientPub OK, false - ClientPub - NOT OK.
Генерирует SymmetricKey;
EncryptedKey = RSAEncrypt(RSAEncrypt(SymmetricKey, ClientPub), ServerPriv); //шифрует публичным ключем клиента, и подписывает приватным ключем сервера
EncryptedKey -> отправляет клиенту только подпись, зашифрованное сообщение не обязательно, у клиента уже есть пабкей сервера.
3. Клиент:
SymmetricKey = RSADecrypt(RSADecrypt(EncryptedKey, ClientPriv), ServerPub); //извлекает зашифрованное сообщение из подписи и дешифрует его в SymmetricKey.
Дальше, уже, и клиент и сервер, имея общий SymmetricKey,
синхронно шифруют-дешифруют трафик, при помощи SymmetricKey,
Каким-нибудь Rijndael (AES), или Salsa20,
а лучше - Шифром Вернама, обладающим доказанной - абсолютной криптостойкостью.
Эта схема - полуанонимна. Сервер можно задеанонить по наличию приватного ключа на его железе.
Клиента, можно задеанонить только в течении сессии, если получить доступ к серверу, и узнать пабкей клиента (а ещё его сделать trace route для его IP).
Пабкей сервера - прешаренный, известен клиенту заранее, поэтому MITM-щик не может его подменить, пушо будет палево тогда.
На этапе 1, при каждом новом соединении с сервером, клиент генерирует, каждый раз - разные ключи, сохраняя таким образом свою анонимность.
Клиент не шлёт свой паб-кей открыто на сервер, чтобы клиента нельзя было задеанонить,
по наличию приватника на железе клиента, соответствующего - публичному ключу клиента.
Только сервер знает (если, конечно, с сервера, не спиздили приватник, лол),
актуальный на данный момент - публичный ключ клиента,
который сразу же теряет актуальность, при разрыве соединения,
так как при новом соединении, ключи клиента - перегенерируются.
Если MITM-щик присунется под видом клиента на этапе 1, и сунет СВОЙ пабкей серверу,
то реальный клиент не сможет дешифровать своим приватным ключем, SymmetricKey сервера, а только MITM-щик.
MITM-щик же, не сможет подписать зашифрованный SymmetricKey, без ClientPub (который открыто не передаётся), и уж тем более - без ServerPriv.
Но...
При большом количестве перехваченных значений EncryptedKey, при постоянных ServerPriv и ServerPub,
наверняка, можно будет, в долгосроке, подобрать ServerPriv, по известному ServerPub,
каким-нибудь брутфорсом, или квантовой факторизацией алгоритмом Шора...
Если же сервер будет регулярно менять ключи ServerPriv и ServerPub,
то ServerPub уже не будет pre-shared, и MITM-щик,
может просто сунуть свои ключи, при следующем обновлении. Лол.
>>839162
Ну и откуда клиент его узнает? Из SSL-сертификата?)))000
> Пабкей сервера - прешаренный, известен клиенту заранее
Ну и откуда клиент его узнает? Из SSL-сертификата?)))000
6 Кб, 275x183>>658420 (OP)
Самый очевидный путь: создать шифрованный канал связи поверх существующего. Пускай митмер помитмует из-под TLS.
> Проблема в том, что канал связи один, и он ещё и открыт.
Самый очевидный путь: создать шифрованный канал связи поверх существующего. Пускай митмер помитмует из-под TLS.
>>839657
TLS уже предлагали и не раз, ОП считает, что можно взять и наебать удостоверяющий центр.
TLS уже предлагали и не раз, ОП считает, что можно взять и наебать удостоверяющий центр.
Я прочитал тут ваши умные мысли и задумался, а что мешает CA операторам наябывать честных граждан, спуфя приватные ключи от их же центров? Кто владеет CA - тот владеет секьюрным трафиком? Помогите разобраться, не хочется верить в конспирологические теории.
>>839735
Ничто. Только то что пацаны уважать перестанут. Может государство вмешаться (случай с DigiNotar например).
> мешает
Ничто. Только то что пацаны уважать перестанут. Может государство вмешаться (случай с DigiNotar например).
>>839735
Теории заговора тем и хороши, что их практически невозможно опровергнуть. Что, например, мешает правительству заиметь квантовый компьютер, о котором никому не говорить, и расшифровывать через него RSA?
Теории заговора тем и хороши, что их практически невозможно опровергнуть. Что, например, мешает правительству заиметь квантовый компьютер, о котором никому не говорить, и расшифровывать через него RSA?
>>839735
Наебать получится только один раз.
Наебать получится только один раз.
>>839244
На двоще, бейсом можно впостить. Или в бЛОХчейн какой-нибудь вшить, чтобы на века.
На двоще, бейсом можно впостить. Или в бЛОХчейн какой-нибудь вшить, чтобы на века.
>>839899
Ты это(и то) скажи тому кто на тебя такую нерешабельную задачу повесил. В общем, вот если совсем в общем, то виртуальный мир пересекается с реальным. Поэтому сети передачи данных защищают ещё и физически.
Ты это(и то) скажи тому кто на тебя такую нерешабельную задачу повесил. В общем, вот если совсем в общем, то виртуальный мир пересекается с реальным. Поэтому сети передачи данных защищают ещё и физически.
Конечно, если я выдерну провод из банкомата и воткну в свой ноут, то банкомат будет полностью под моим контролем, никакие паблик кеи не спасут. Но смогу ли я это сделать?
Дополнение. Проблема опа(даже теоретическая) не в том как защититься от злоумышленника, а в том что злоумышленник уже спалил что его канал нужно перехватывать. Оп в этом месте проебался. Если бы он сразу использовал защищённый канал связи, то у него всё было бы хорошо. Но он не понимает зачем нужна защита.
Оп, зачем из миллионов защищённых связей, злоумышленник должен подключаться именно к твоей?
Всё, проблема решена?
Всё, проблема решена?
И вот если бы оп защитил свой канал связи последним и самым надёжным методом шифрования, то у него бы таких проблем не было. Он бы просто сказал - я использовал самый надёжный метод шифрования который есть. Это вы проебались и именно из-за вашего проёба сейчас нас прослушивают.
Ещё одно крайне положительное качество хорошей защиты. Можно делать ловушки, если не уверен в партнёре, убери защиту. Если у тебя стало всё плохо после этого, значит он тебе враг.
На дваче мои друзья, я знаю.
>>839908
Даже если сможешь - не будет. Мало того, что тот же TLS - это не просто паблик кеи, но и их валидация, так ещё в банкомат можно вшить симметричный пре-шаред кей. TLS - это когда заранее не знаешь, с кем захочешь установить соединение, но с банкоматами таких проблем нет.
>>839909
Если бы не спалил, это не повод ослаблять бдительность. Надо с самого начала предполагать, что злоумышленник захочет влезть, даже если передаются бесполезные картинки с котиками. И тогда не будет разницы, спалили или нет.
>>839915
Ну так оп сомневается, что эти методы шифрования действительно настолько хороши.
>>839917
"Партнёры" тут не при чём, здесь обсуждается более конкретная проблема, а не безопасность как таковая: пока пакет идёт от клиента к серверу, он проходит через множество посредников, один из которых может запросто оказаться крысой - вот проблема.
> Конечно, если я выдерну провод из банкомата и воткну в свой ноут, то банкомат будет полностью под моим контролем, никакие паблик кеи не спасут. Но смогу ли я это сделать?
Даже если сможешь - не будет. Мало того, что тот же TLS - это не просто паблик кеи, но и их валидация, так ещё в банкомат можно вшить симметричный пре-шаред кей. TLS - это когда заранее не знаешь, с кем захочешь установить соединение, но с банкоматами таких проблем нет.
>>839909
> Дополнение. Проблема опа(даже теоретическая) не в том как защититься от злоумышленника, а в том что злоумышленник уже спалил что его канал нужно перехватывать. Оп в этом месте проебался. Если бы он сразу использовал защищённый канал связи, то у него всё было бы хорошо. Но он не понимает зачем нужна защита.
Если бы не спалил, это не повод ослаблять бдительность. Надо с самого начала предполагать, что злоумышленник захочет влезть, даже если передаются бесполезные картинки с котиками. И тогда не будет разницы, спалили или нет.
>>839915
> И вот если бы оп защитил свой канал связи последним и самым надёжным методом шифрования, то у него бы таких проблем не было. Он бы просто сказал - я использовал самый надёжный метод шифрования который есть.
Ну так оп сомневается, что эти методы шифрования действительно настолько хороши.
>>839917
> Ещё одно крайне положительное качество хорошей защиты. Можно делать ловушки, если не уверен в партнёре, убери защиту. Если у тебя стало всё плохо после этого, значит он тебе враг.
"Партнёры" тут не при чём, здесь обсуждается более конкретная проблема, а не безопасность как таковая: пока пакет идёт от клиента к серверу, он проходит через множество посредников, один из которых может запросто оказаться крысой - вот проблема.
>>839946
Тоже не понимаешь что такое защита.
Защита это увеличение время доступа, всё. Нет ни одной защиты в мире, с бесконечным временем доступа. Поэтому, если у меня будет достаточно времени и доступ к банкомату, то любой TLS ляжет.
Мимо твоей двери проходит много людей, один из них может её взломать, почему этого не произошло. Потому что у него не хватает времени доступа? Нет?
Тоже не понимаешь что такое защита.
Защита это увеличение время доступа, всё. Нет ни одной защиты в мире, с бесконечным временем доступа. Поэтому, если у меня будет достаточно времени и доступ к банкомату, то любой TLS ляжет.
>он проходит через множество посредников, один из которых может запросто оказаться крысой - вот проблема.
Мимо твоей двери проходит много людей, один из них может её взломать, почему этого не произошло. Потому что у него не хватает времени доступа? Нет?
>>839977
Слишком большое время доступа = бесконечное время доступа.
Слишком большое время доступа = бесконечное время доступа.
Суть безопасности и защиты - если захотят то взломают, надо делать так чтобы не захотели.
>>839993
Да я не про это. Вот у Скруджа Макдака был такой банк, помните? Вот если этот банк поставить в чистое поле, наполнить его 300млн. баксов и не приезжать туда никогда. И поставить дверь, в этот банк, сложность взлома которой будет 50 млн.баксов(инструменты, работа там). То этот банк взломают.
А если поставить дверь со сложностью взлома 500млн. баксов, то не взломают. Потому что потратят 500, а получат 300, 200 в минусе ёпт.
Так вот, в примере опа, цена двери упала с 500 до 50. И не просто так. Обязаталеньно это случилось по чьей то вине. Если это случилось по вине опа, то пусть теперь бегает вдоль линии передачи данных и отбивает этих митмщиков. А если не оп виноват и всё правильно сделал, то пусть нахуй шлёт этих товарщией, им уже ничего не поможет.
Да я не про это. Вот у Скруджа Макдака был такой банк, помните? Вот если этот банк поставить в чистое поле, наполнить его 300млн. баксов и не приезжать туда никогда. И поставить дверь, в этот банк, сложность взлома которой будет 50 млн.баксов(инструменты, работа там). То этот банк взломают.
А если поставить дверь со сложностью взлома 500млн. баксов, то не взломают. Потому что потратят 500, а получат 300, 200 в минусе ёпт.
Так вот, в примере опа, цена двери упала с 500 до 50. И не просто так. Обязаталеньно это случилось по чьей то вине. Если это случилось по вине опа, то пусть теперь бегает вдоль линии передачи данных и отбивает этих митмщиков. А если не оп виноват и всё правильно сделал, то пусть нахуй шлёт этих товарщией, им уже ничего не поможет.
>>839998
То есть кто-то пизданул, например, что этот канал связи стоящий. И если оп всё делал правильно, предпринимал все меры безопасности, то пусть шлёт нахуй этих быдланов, которые ещё с него и спрашивают. Это уже за пределами его компетенции. Это может быть и конкуренты, но опять же, это не проблемы опа. Оп обеспечит безопасность в своей компетенции, надо TLS сделает TLS, надо VPN будет VPN. Но если всем пиздеть что за этим TLS миллиарды долларов, то никакая защита не поможет. И это будет не вина ОПа, если это не он всем пиздел.
> цена двери упала с 500 до 50
То есть кто-то пизданул, например, что этот канал связи стоящий. И если оп всё делал правильно, предпринимал все меры безопасности, то пусть шлёт нахуй этих быдланов, которые ещё с него и спрашивают. Это уже за пределами его компетенции. Это может быть и конкуренты, но опять же, это не проблемы опа. Оп обеспечит безопасность в своей компетенции, надо TLS сделает TLS, надо VPN будет VPN. Но если всем пиздеть что за этим TLS миллиарды долларов, то никакая защита не поможет. И это будет не вина ОПа, если это не он всем пиздел.
>>839998
А если наступит коммунизм, то дверь можно снимать с петель и нести на прием цветмета. Всё равно деньги будут никому не нужны.
А если наступит коммунизм, то дверь можно снимать с петель и нести на прием цветмета. Всё равно деньги будут никому не нужны.
Это вот типично-коммунистический подход к решению проблемы. Сначала создать проблему которая может быть решена только при коммунизме(который невозможен), а потом спрашивать решение.
Купить бронированную дверь, потом всем распиздеть что за ней квартира с деньгами, уехать в отпуск на год. Потом приехать и спрашивать с других почему проклятая капиталистическая дверь не защитила квартиру. А вот при коммунизме и защищать не надо было бы.
Так ты изначально не создавай проблему и капиталистическая дверь тебя нормально защитит.
Купить бронированную дверь, потом всем распиздеть что за ней квартира с деньгами, уехать в отпуск на год. Потом приехать и спрашивать с других почему проклятая капиталистическая дверь не защитила квартиру. А вот при коммунизме и защищать не надо было бы.
Так ты изначально не создавай проблему и капиталистическая дверь тебя нормально защитит.
Коммунизм через мгновенье после своей постройки превращается в анархо-капитализм, а затем через некоторое время в капитализм обычный. И придётся опять включать TLS.
>>840077
А как же мороженое?
А как же мороженое?
294 Кб, 450x600>>839598
>>839899
Анус себе отсоси, пёс.
>>839907
Поздравляю, ты только что поговорил с двумя мемными пастами.
http://lurkmore.to/Соси_хуй,_быдло и пикрил.
Тащемта задача проста - как угол дома. Синхронизировать JSON, между серверами, в децентрализованной сети.
Очевидно, что трафик следовало бы шифровать, а так как сеть децентрализованная,
то сервера могут подключаться непонятно откуда, из различных мест планеты, непонятно где находящихся,
и непонятно как (в том числе через локальные сети, LAN внутри VPN, через TOR), и так далее.
По умолчанию, системам шифрования нет ни малейшего доверия, так как JSON передаётся по HTTP.
Поэтому, встала задача анонимной или же полу-анонимной аутентификации,
для реализации схемы обмена симметричными ключами, схемы - устойчивой к MITM-атакам.
Дальше уже, можно шифровать HTTP-трафик, конвертируя байты в какую-нибудь кодировку iso-8859-1,
способную кодировать все 256 байт - 256-ю символами, и гнать эту инфу по http, в обе стороны,
с mime-type - "application/octet-stream".
>Соси хуй, быдло.
>>839899
Анус себе отсоси, пёс.
>>839907
>Ты это(и то) скажи тому кто на тебя такую нерешабельную задачу повесил.
>В общем, вот если совсем в общем, то виртуальный мир пересекается с реальным.
>Поэтому сети передачи данных защищают ещё и физически.
Поздравляю, ты только что поговорил с двумя мемными пастами.
http://lurkmore.to/Соси_хуй,_быдло и пикрил.
Тащемта задача проста - как угол дома. Синхронизировать JSON, между серверами, в децентрализованной сети.
Очевидно, что трафик следовало бы шифровать, а так как сеть децентрализованная,
то сервера могут подключаться непонятно откуда, из различных мест планеты, непонятно где находящихся,
и непонятно как (в том числе через локальные сети, LAN внутри VPN, через TOR), и так далее.
По умолчанию, системам шифрования нет ни малейшего доверия, так как JSON передаётся по HTTP.
Поэтому, встала задача анонимной или же полу-анонимной аутентификации,
для реализации схемы обмена симметричными ключами, схемы - устойчивой к MITM-атакам.
Дальше уже, можно шифровать HTTP-трафик, конвертируя байты в какую-нибудь кодировку iso-8859-1,
способную кодировать все 256 байт - 256-ю символами, и гнать эту инфу по http, в обе стороны,
с mime-type - "application/octet-stream".
>>840250
Это когда сервер не знает кто именно является клиентом, и принимает любого анонимного клиента, при этом клиент может перегенерировать ключи, оставаясь анонимным, и исключая тем самым возможность деанонимизации по наличию ключей на его железе.
Это когда сервер не знает кто именно является клиентом, и принимает любого анонимного клиента, при этом клиент может перегенерировать ключи, оставаясь анонимным, и исключая тем самым возможность деанонимизации по наличию ключей на его железе.
>>840256
Не, стоп. Если только сервер знает новосгенерированный публичный ключ клиента, то это, походу, полностью анонимная схема.
Хотя её тоже можно назвать "полу-анонимной", потому что пабкей сервера прешаренный, а значит по привкею на железе сервера, можно задеанонить сервер, и сервер не анон, получается, а как-бы персонализированная поебень какая-то, которой аноны, как-бы доверяют. А если можно задеанонить, то значить, можно и железо отжать, или перехвать контроль над ним и спиздить привкей, зная где именно он лежит, у какого задеанонненного "юзера" (одмина сервера, например).
Ну ты понел.
С другой стороны, я уже писал ранее своё понимание "полу-анонимной" схемы.
Это когда клиент шлёт свой пабкей открытым текстом, и митмщик нихуя не может сделать с шифром от сервера,
(разве что мусор зашифровать какой-то, известным пабкеем клиента, и загнать ему прямо на порты, через замитмченое соеднение, бггг...).
Ну дык вот, сервер с шифром нихуя не может сделать, а с пабкеем может.
Он может пробить соединения, и зная куда они физически ведут, устроить облаву на сервер,
извлечь привкей (соответствующий известному пабкею),
или обнаружить на железе пабкей (который у митмщика уже есть), и таким образом, по ЗАДЕАНОНИТЬ КЛИЕНТА.
Но так как ключ актуален лишь в течении сессии обмена данными, то эта схема - полуанонимна, как-бы,
и пока клиент на связи, он как-бы деанонимизирован,
а как только переподключится - он будет уже другим деанонимизированным клиентом, и вцелом - анонимным.
Ну ты понел.
Не, стоп. Если только сервер знает новосгенерированный публичный ключ клиента, то это, походу, полностью анонимная схема.
Хотя её тоже можно назвать "полу-анонимной", потому что пабкей сервера прешаренный, а значит по привкею на железе сервера, можно задеанонить сервер, и сервер не анон, получается, а как-бы персонализированная поебень какая-то, которой аноны, как-бы доверяют. А если можно задеанонить, то значить, можно и железо отжать, или перехвать контроль над ним и спиздить привкей, зная где именно он лежит, у какого задеанонненного "юзера" (одмина сервера, например).
Ну ты понел.
С другой стороны, я уже писал ранее своё понимание "полу-анонимной" схемы.
Это когда клиент шлёт свой пабкей открытым текстом, и митмщик нихуя не может сделать с шифром от сервера,
(разве что мусор зашифровать какой-то, известным пабкеем клиента, и загнать ему прямо на порты, через замитмченое соеднение, бггг...).
Ну дык вот, сервер с шифром нихуя не может сделать, а с пабкеем может.
Он может пробить соединения, и зная куда они физически ведут, устроить облаву на сервер,
извлечь привкей (соответствующий известному пабкею),
или обнаружить на железе пабкей (который у митмщика уже есть), и таким образом, по ЗАДЕАНОНИТЬ КЛИЕНТА.
Но так как ключ актуален лишь в течении сессии обмена данными, то эта схема - полуанонимна, как-бы,
и пока клиент на связи, он как-бы деанонимизирован,
а как только переподключится - он будет уже другим деанонимизированным клиентом, и вцелом - анонимным.
Ну ты понел.
>>714749
>>714808
>>749593
>>768658
>>839162
Я вам тут, короче, покушать принёс, RSABigInteger, https://github.com/username1565/BigInteger.js/commit/2b2057db04a32996247f2d1182511b6f2fe82395
client-side и на JavaScript, и прямо в браузере, без слива ключей админу говносайта, на сервер.
Сначала копируете, покане удалили,
затем инклюдите BigInteger.js в html-страничку, открываете её, например здесь (уже подключён): https://username1565.github.io/BigInteger.js/cube_root.html
И пишите в консоли RSABigInteger.TEST(); ну а дальше - смотрите код этой функции:
https://github.com/username1565/BigInteger.js/blob/master/BigInteger.js#L3930
и дальше там, по ветвям кода.
Если на C или C# это впилить, можно сделать клиент-серверную поебень с реализацией этой вот схемы: >>839162
А дальше уже - гонять посты наноборды, в виде зашифрованного JSON'а, в локалке,
как между серверами, так и при загрузке на клиент,
в обход слежки через снифферы, и через прочую хуетень, вроде пеленгаторов.
>>839782
Частая перегенерация ключей.
>шифрование с открытым ключом (RSA)
>>714808
>RSA
>>749593
>там можно и подписывать и шифровать с помощью RSA-ключей
>>768658
>Вот, например, атаки на RSA: http://algolist.ru/defence/attack/rsa.php
>>839162
>ПОПРОБУЙТЕ ЗА-MITM-АТЬ ЭТУ ПОЕБНЮ:
>RSA
>RSA
>RSA
Я вам тут, короче, покушать принёс, RSABigInteger, https://github.com/username1565/BigInteger.js/commit/2b2057db04a32996247f2d1182511b6f2fe82395
client-side и на JavaScript, и прямо в браузере, без слива ключей админу говносайта, на сервер.
Сначала копируете, покане удалили,
затем инклюдите BigInteger.js в html-страничку, открываете её, например здесь (уже подключён): https://username1565.github.io/BigInteger.js/cube_root.html
И пишите в консоли RSABigInteger.TEST(); ну а дальше - смотрите код этой функции:
https://github.com/username1565/BigInteger.js/blob/master/BigInteger.js#L3930
и дальше там, по ветвям кода.
Если на C или C# это впилить, можно сделать клиент-серверную поебень с реализацией этой вот схемы: >>839162
А дальше уже - гонять посты наноборды, в виде зашифрованного JSON'а, в локалке,
как между серверами, так и при загрузке на клиент,
в обход слежки через снифферы, и через прочую хуетень, вроде пеленгаторов.
>>839782
>Что, например, мешает правительству заиметь квантовый компьютер,
>о котором никому не говорить, и расшифровывать через него RSA?
Частая перегенерация ключей.
>>714749
>>714808
>>749593
>>768658
>>839162
Я вам тут, короче, покушать принёс, RSABigInteger, https://github.com/username1565/BigInteger.js/commit/2b2057db04a32996247f2d1182511b6f2fe82395
client-side и на JavaScript, и прямо в браузере, без слива ключей админу говносайта, на сервер.
Сначала копируете, покане удалили,
затем инклюдите BigInteger.js в html-страничку, открываете её, например здесь (уже подключён): https://username1565.github.io/BigInteger.js/cube_root.html
И пишите в консоли RSABigInteger.TEST(); ну а дальше - смотрите код этой функции:
https://github.com/username1565/BigInteger.js/blob/master/BigInteger.js#L3930
и дальше там, по ветвям кода.
Если на C или C# это впилить, можно сделать клиент-серверную поебень с реализацией этой вот схемы: >>839162
А дальше уже - гонять посты наноборды, в виде зашифрованного JSON'а, в локалке,
как между серверами, так и при загрузке на клиент,
в обход слежки через снифферы, и через прочую хуетень, вроде пеленгаторов.
>>839782
Частая перегенерация ключей.
>шифрование с открытым ключом (RSA)
>>714808
>RSA
>>749593
>там можно и подписывать и шифровать с помощью RSA-ключей
>>768658
>Вот, например, атаки на RSA: http://algolist.ru/defence/attack/rsa.php
>>839162
>ПОПРОБУЙТЕ ЗА-MITM-АТЬ ЭТУ ПОЕБНЮ:
>RSA
>RSA
>RSA
Я вам тут, короче, покушать принёс, RSABigInteger, https://github.com/username1565/BigInteger.js/commit/2b2057db04a32996247f2d1182511b6f2fe82395
client-side и на JavaScript, и прямо в браузере, без слива ключей админу говносайта, на сервер.
Сначала копируете, покане удалили,
затем инклюдите BigInteger.js в html-страничку, открываете её, например здесь (уже подключён): https://username1565.github.io/BigInteger.js/cube_root.html
И пишите в консоли RSABigInteger.TEST(); ну а дальше - смотрите код этой функции:
https://github.com/username1565/BigInteger.js/blob/master/BigInteger.js#L3930
и дальше там, по ветвям кода.
Если на C или C# это впилить, можно сделать клиент-серверную поебень с реализацией этой вот схемы: >>839162
А дальше уже - гонять посты наноборды, в виде зашифрованного JSON'а, в локалке,
как между серверами, так и при загрузке на клиент,
в обход слежки через снифферы, и через прочую хуетень, вроде пеленгаторов.
>>839782
>Что, например, мешает правительству заиметь квантовый компьютер,
>о котором никому не говорить, и расшифровывать через него RSA?
Частая перегенерация ключей.
Двач.hk не отвечает.
Вы видите копию треда, сохраненную 22 апреля 2021 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Вы видите копию треда, сохраненную 22 апреля 2021 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.