Комментарии 44
Если оба собеседника имеют серые IP (т.е. находятся за NAT и не имеют возможности соединения напрямую), то как ваш скрипт автоматизирует процесс обмена ключами?
0
1. Вы передаете публичные ключи открытым текстом? То есть теоретически кто-то может реализовать классическую MITM?
2. Насколько я помню RSA не очень хорошо работает на тексте. Ему лучше передавать случайный набор байт (в общем случае хеш). То есть опять же теоретически ваша реализация шифрования RSA не такая уж криптостойкая.
2. Насколько я помню RSA не очень хорошо работает на тексте. Ему лучше передавать случайный набор байт (в общем случае хеш). То есть опять же теоретически ваша реализация шифрования RSA не такая уж криптостойкая.
+6
RSA не рекомендуется использовать для шифрования сообщений, для этого есть много причин. Одного того, что это детерменированный алгоримтм (одинаковый текст всегда дает одинаковый шифр) хватает. А вообще http://en.wikipedia.org/wiki/RSA_(algorithm)#Attacks_against_plain_RSA
Рекомендованный способ — сгенерить ключ K, зашифровать его открытым ключом PK (RSA), параллельно посчитать его (K, не PK) хэш H(K) (SHA-256), полученный H(K) использовать как ключ для симметричного шифрования (AES) сообщения. Передать результат работы RSA и AES одним сообщением. Получатель расшифровывает своим закрытым ключом SK первую часть, получает ключ K, считает его хэш H(K) и расшифровывает им сообщение.
Рекомендованный способ — сгенерить ключ K, зашифровать его открытым ключом PK (RSA), параллельно посчитать его (K, не PK) хэш H(K) (SHA-256), полученный H(K) использовать как ключ для симметричного шифрования (AES) сообщения. Передать результат работы RSA и AES одним сообщением. Получатель расшифровывает своим закрытым ключом SK первую часть, получает ключ K, считает его хэш H(K) и расшифровывает им сообщение.
+17
еще вариант — перед шифрованием добивать блок рандомными данными фиксированной длины и потом отрезать их с другой стороны. таким образом даже одинаковые сообщения будут отличаться
0
Строго говоря, за абзацем, на который вы ссылаетесь, есть абзац про «Padding schemes», который как раз призван бороться с детерминистичностью результата. Я не призываю никого использовать RSA в чистом виде, и я полностью согласен с концепцией генерации сеансовых ключей под защитой RSA, это просто ремарка
0
Ну и конечно же, банальный ajax не вернёт расшифрованный текст обратно на сервер…
+4
Интересная идея, но есть и побочный эффект: Нет гарантий, что ваш скрипт сам не отсылает личные сообщения на ваш сервер.
У меня, например, тоже стоит самописный плагин к вконтакте, но он работает как кейлогер и угоняет переписку всех, кто логинится с моего ноутбука. Опять же — маловероятно что кто-либо из моих знакомых будет ставить подобные плагины, т.к. они будут опасаться, что переписку угонит сам плагин.
У меня, например, тоже стоит самописный плагин к вконтакте, но он работает как кейлогер и угоняет переписку всех, кто логинится с моего ноутбука. Опять же — маловероятно что кто-либо из моих знакомых будет ставить подобные плагины, т.к. они будут опасаться, что переписку угонит сам плагин.
+2
Согласен, хотя скрипт довольно простой и с открытым кодом, такая потенциальная опасность есть.
0
Несмотря на то, что скрипт простой, читать и анализировать его код обычные пользователи не будут. Никто не помешает под видом «супер-секретного-чата-дуров-не узнает» распространять скрипт (не ваш), сливающий все ключи тем же спецслужбам.
0
> У меня, например, тоже стоит самописный плагин к вконтакте, но он работает как кейлогер и угоняет переписку всех, кто логинится с моего ноутбука
Даете друзья попользоваться, или это на злоумышленников нацелено?
Даете друзья попользоваться, или это на злоумышленников нацелено?
+1
Спасибо :)
Все программисты — немного параноики :)
Все программисты — немного параноики :)
0
НЛО прилетело и опубликовало эту надпись здесь
Лучше сгенерировать ключ и выдать пользователю через prompt, сообщив, что ключ нужно передать собеседнику по другому каналу.
Саму возможность отправить ключ через чат ВК отключить, выдав предупреждение об опасности mitm при попытке вставить ключ в чат.
Саму возможность отправить ключ через чат ВК отключить, выдав предупреждение об опасности mitm при попытке вставить ключ в чат.
0
Саму возможность отправить ключ через чат отключить
— Месье знает как это сделать?
— Месье знает как это сделать?
0
жаваскриптом при вставке в форму ключа удалять содержимое и сообщать о необходимости отправить данные другим каналом.
0
Как вы определите, что строка «41325три13245-213ололо5» — это ключ?
0
Как бы ключ генерируется жаваскриптом, подцепленным greasemonkey, на домен vk.com и им же можно проверить отправку строки 41325три13245-213ололо5 в окно чата, на клиенте.
0
Нет, сразу видно, что вы никогда не сталкивались со страшным зверем пользователем.
Ключ: 413253132452135.
Пользователь забивает: 41325три13245-213ололо5.
Как вы определите, что пользователь забил ключ?
Я к чему это говорю — любая криптографическая система устойчивее ROT13 если и только если ее пользователь имеет элементарные знания о безопасности и желание этими знаниями пользоваться.
Ключ: 413253132452135.
Пользователь забивает: 41325три13245-213ололо5.
Как вы определите, что пользователь забил ключ?
Я к чему это говорю — любая криптографическая система устойчивее ROT13 если и только если ее пользователь имеет элементарные знания о безопасности и желание этими знаниями пользоваться.
0
2048-битный ключ — это такой огромный blob, который передать по другому (например, телефону) каналу весьма проблематично. Ключи допустимо передавать и через чат, но выводя отпечатки ключей на обоих сторонах. Тогда можно будет позвонить по тому же телефону и довольно быстро сверить эти отпечатки. Другой вопрос — если ключ используется в течении долгого времени, то где его хранить? cookies, localstorage — оба хранилища легко читаются контактовскими скриптами, а первое, кроме того, еще и на сервер VK посылается. Возможное решение — хранение шифрованного ключа в LocalStorage и запрос через функцию prompt() пароля. Но, я уверен, тут найдется еще куча приемов типа замены функций, благо JS позволяет.
Кроме того, можно использовать долговременные ключи только для аутентификации, а сам ключ шифрования получать посредством DH/ECDH, как это делает OTR. Это немного снизит опасность похищения ключей, т.к. предыдущую переписку расшифровать все равно не получится (Perfect forward secrecy).
Кроме того, можно использовать долговременные ключи только для аутентификации, а сам ключ шифрования получать посредством DH/ECDH, как это делает OTR. Это немного снизит опасность похищения ключей, т.к. предыдущую переписку расшифровать все равно не получится (Perfect forward secrecy).
+1
На хроме не работает, а переходить на мозиллу только ради шифрочата — не хочется :(
0
Автор, будьте так любезны:
s/ключём/ключом/g
+1
А почему сообщение шифруется только пабликом собеседника? Логично было бы шифровать и своим приватом тоже. Этим можно и MITM усложнить.
0
Тогда надо иметь возможность передать ключик для расшифровки.
0
Шифрование своим приватным ключем называется «цифровая подпись». Но толку все равно никакого, если атакующий может подменять открытые ключи при обмене.
0
«Цифровая подпись» — это не шифрование.
«Цифровая (электронная) подпись» — это добавленный к открытому сообщению его зашифрованный хеш (если совсем уж «на пальцах» объяснять).
«Цифровая (электронная) подпись» — это добавленный к открытому сообщению его зашифрованный хеш (если совсем уж «на пальцах» объяснять).
0
И чем тогда по-вашему шифруется хэш? Открытым ключем получателя? Тогда что мешает злоумышленнику взять тот же открытый ключ, подделать сообщение и переподписать его?
Разумеется на практике закрытым ключем «шифруется» хэш, но это делается только для того, чтобы размер подпись был небольшим и не зависел от размера подписываемого сообщения. Суть самой цифровой подписи все равно остается в «подписали, зашифровав закрытым ключем отправителя, проверили, расшифровав открытым ключем отправителя».
Разумеется на практике закрытым ключем «шифруется» хэш, но это делается только для того, чтобы размер подпись был небольшим и не зависел от размера подписываемого сообщения. Суть самой цифровой подписи все равно остается в «подписали, зашифровав закрытым ключем отправителя, проверили, расшифровав открытым ключем отправителя».
0
Можно кстати использовать Interlock_protocol
0
Основная идея такого чатика это обскьюрити. Потому что если подобный способ наберет популярность. MITM встроить в сервер будет не так дорого организовать. Сам н времени назад сделал на питоне похожу хрень для xmpp. Оно хорошо, если им пользуется 2 колеки и всем на вас пофиг.
0
Факт самого общения собеседников — никак шифрованием не скрывается.
По периодичности, продолжительность и изменению интенсивности общения можно сделать различные далеко идущие выводы.
Как, например, сделал Facebook.
По периодичности, продолжительность и изменению интенсивности общения можно сделать различные далеко идущие выводы.
Как, например, сделал Facebook.
0
+2
Ах да, вместо ctrl shift V в правом нижнем углу кнопка Patch
+1
А как его установить в хроме?
0
>Факт самого общения собеседников — никак шифрованием не скрывается.
для этого имеется другой механизм: СТЕГАНОЛОГИЯ=СТЕГАНОГРАФИЯ + СТЕГАЕОАНАЛИЗ
для этого имеется другой механизм: СТЕГАНОЛОГИЯ=СТЕГАНОГРАФИЯ + СТЕГАЕОАНАЛИЗ
0
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Шифрованный тоннель для общения через VK (RSA + GreaseMonkey)