Pull to refresh

Comments 51

Мило, но бесполезно.

Вконтакт может передавать сообщения на сервер до того как сообщение будет зашифровано, и приватность идет лесом.
да, но:
  • Если мой аккаунт угонит некий Вася Пупкин, прочесть личные сообщения он не сможет.
  • У меня теперь есть кнопка «Удалить сообщения», которая сотрет ключи у меня и у собеседника (например девушки). А значит, среднестатистическая мадам гарантированно удалит личные сообщения, если мне будет нужно (на самом деле, это наверное самая важная функция, т.к. вконтакт удаляет сообщение только у одного из собеседников).


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

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

> всегда можно вывести человека в лес

Я говорю о чисто технических слабостях алгоритма и протоколов.

Прочитав исходный код, я понял, что у автора нет понимания свойств RSA.
А что если собеседник будет использовать модифицированную версию плагина, которая не слушает команды и не удалаяет ключи? Что если собеседник записывает ключи из плагина?

Значит это не среднестатистическая девушка / пользователь. И, возможно, не стоит вообще писать ему лишнее.
Прочитав исходный код, я понял, что у автора нет понимания свойств RSA.

Можно более подробнее? RSA я не писал, а использовал чужую библиотеку. Если она плоха, можно ее заменить.
Например, что RSA не используется как блочный алгоритм.
Поэтому в библиотеке не встроено разбиение сообщения на блоки.

        /*
         * Ебанная хуня, пишу костыли, т.к. разрабы либы ПИД*РАСЫ
         * Либа должна сама текст на куски разбивать, а она нах*й посылает и пишет Лимит для RSA превышен.
         */
        _getSmallBlock: function (message, limit, callback) {
            var length = message.length,
                count = Math.ceil(length / limit),
                textBlock = "";

            for (var i = 0; i < count; i++) {
                var from = i * limit,
                    to = from + limit,
                    part = message.substring(from, to);

                textBlock += callback(part) || "";
            }

            return textBlock;
        },
Но тут не про блоки. Тут длинный текст, который нужно зашифровать открытым ключом. Мне кажется логично, что библиотека должна получить текст и вернуть шифровку, и довольно странно, что она не хочет этого делать.

При том другая библиотека шифровала текст любой длины, но имела недостатки в других методах.
> Но тут не про блоки. Тут длинный текст, который нужно зашифровать открытым ключом.

Но то что здесь изобретается и есть *блочное шифрование*. :)
Unpadded RSA? Похоже, вы опасно некомпетенты в криптографии.

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

У меня в либе все это реализовано, и работает довольно шустро.

Если есть вопросы, пишите в личку — проконсультирую.
Вроде там PCKS1.5 используется. Он конечно тоже взломан, но не так печально как совсем без паддинга. Ну а автор действительно некомпетентен, раз не понимает даже при чем тут блоки. Видимо поэтому большая часть статьи — картинки не по теме.

PS: я больше угорел по тексту на http://bakhirev.biz/demo/crypto/#!view=how_works:
Примерно так работает алгоритм шифрования RSA. Ключ, конечно, можно подобрать или расшифровать. Но на этой уйдет 2^32 попыток. Это очень много, и для этого нужно очень много мощных компьютеров, которые будут работать несколько дней. Т.к. ключи могут меняться в ходе переписки, то задача становится еще более трудоемкой.


И вроде бы не 1е апреля…
не в курсе о возможности разработки для Вконтакт, но разве там нельзя внедрить свой Javascript, в котором проводить кодирование до того, как будет отправка данных на сервер и декодирование после чтения с сервера?

PS: тоже не совсем давно занимался подобным вопросом. Правда задача немного стояла другая: шифрация/дешифрация сообщений. Например информацию для соединения с каким-либо сервером, хранящихся статически в почтовом ящике, которая требуется раз в пару месяцев, но не хотелось бы ее потерять. Или в гуглевских таблицах и документах.Кодирование и декодирование производится в браузере клиента, без отправки по сети. Если кому интересно, то тут: https://svddevelop.com/crypt/
Конечно можно. Но только до первого обновления скрипта, связанного с отправкой сообщений. Это далеко не первый скрипт/плагин, позволяющий шифровать сообщения ВКонтакте. Но ввиду того, что подобные разработки врезаются в код чужого сервиса, то через некоторое время они обрастают костыли, а в какой то момент вообще перестают обновляться, из-за того, что автору надоело, а сервис продолжает изменяться.
Фейсбук, единственные, кто поленились писать крутое поле ввода. Только у них стоит обычная textarea, в которой все смайлы отображаются кодировкой, а не картинкой.
Всегда считал это достоинством ФБ, что они забили на смайлы и прочую разметку, только plain text.
Это лучшее объяснение RSA с иллюстрациями, которое я видел
Во первых иллюстрировано не шифрование с помощью RSA, а обмен ключами. Во вторых, либо я неправильно понял аналогию, либо тут ошибка: если чемодан — публичный ключ, а «ключ» — приватный — то Саша не должен посылать обратно свой ключ, только чемодан.

А вот это предложение вообще ерунда какая-то:
Теперь Тимуру больше не нужен свой чемодан и свой ключ. Он может пользоваться теми, что ему передал Саша.


Шифрование бы выглядело так:
1. Тимур даёт Саше чемодан (публичный ключ)
2. Саша кладет туда сообщение и захлопывает, отдаёт обратно.
3. Тимур открывает ключом чемодан и читает сообщение.
Ощущение что пытались объяснить DH, но суть не передали.
p.s. ник у вас тематический )
Мне кажется, нужно код браузерного плагина выложить на гит, например. Полезная штука же, подтолкнет развитие.
На сколько я понял, вы создаете один приватный ключ на все диалоги пользователя.
Предположим, вы общались зашифрованными сообщениями с Васей и Петей, и Петя внезапно оказался сотрудником ФСБ.
И вот Петя появляется у вас на пороге с группой поддержки. а так как он не лыком шит, он заранее выписал приватный ключ на листик.
И даже если вам удастся каким-то чудом добежать до своего компьютера и удалить свой приватный ключ у себя и у Васи, и даже у Пети, это всё равно не помешает Пете расшифровать всю вашу переписку.
Если я не прав, поправьте.
Ваш приватный (для дешифровки) ключ только у вас. У Пети ваш публичный ключ, им можно только шифровать. Так работает ассиметричная криптография.
вы создаете один приватный ключ на все диалоги пользователя.

Нет, на каждый диалог — свой приватный ключ
если Петя внезапно оказался сотрудником ФСБ.

Если он сотрудник ФСБ, то знать ключи ему не обязательно. Переписку взломают с помощью терморектального криптоанализатора
Переписку взломают с помощью терморектального криптоанализатора
К насильственным методам не будут прибегать без особой необходимости.
> История о любви

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

> История ревнивом муже

Я не на стороне Юли с Сережей))
У меня такой проблемы нет.

> История об алиби

Толику надо научиться чтить закон.
У меня такой проблемы нет.

> История о массовых беспорядках

У Лёши не будет проблем, если организованные им гуляния не нарушают с законы.
У меня такой проблемы нет.

> История об истеричке

Подальше от таких дур держаться надо, если на ровном месте скандал.
У меня такой проблемы нет.

В очередной раз убедился, что шифрование нужно только в промышленных нуждах и преступникам.
Лихо вы всех в преступники записали
Зря минусы.
> История о любви
1. блокируйте комп, так как данная переписка может оказаться мелочью по сравнению с тем, что могло быть унесено. Например дамп готового проекта, который через 1-2 недели должен пойти в релиз.
2. Коллеги, читающие переписку одного из своих, уже не являются коллегами. Этот пример покажет, что в организации нет команды.
> История об истеричке
тут правильнее сказать, что нужно держаться подальше от таких, кто лезет в твой телефон без твоего разрешения.

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

Кстати, объясните пожалуйста, как это шифрование поможет в первом случае, если Миша ушел домой, оставив включенным комп, где на экране уже отображается расшифрованный текст?
Однажды инженер Чжа Вынь обратился к Учителю:
– Один достойный уважения человек сказал мне, что шифровать электронную почту неправильно. Поскольку честному человеку нечего скрывать, шифрованная переписка неизбежно привлечёт внимание Охранительного ведомства. Учитель, что вы об этом думаете?
Инь Фу Во ответил:
– Благородный муж имеет чувство стыдливости. Он закрывает одеждой свою наготу. Вовсе не потому, что лицезрение другими принесёт ему ущерб. Но такова воля Неба, и таков ритуал. Честному человеку есть, что скрывать.
UFO just landed and posted this here
Иллюстрации шикарные, но во всех пяти историях персонажам нужна стеганография, а не наивное шифрование: факт получения сообщения и имя отправителя видны, а невозможность прочитать текст никак не спасет от истерики, ББПЕ или судебного ордера на применение терморектального криптоанализа.
Тут не требуется стеганографии, достаточно шифрования заголовков (того же имени отправителя). Разумеется, в рамках плагина к соцсетям это невозможно, и придется посылать котиков.
т.к. я
… опасно некомпетенты в криптографии.

Думаю через некоторое время заменю алгоритм шифрования на тот, который предложат комментаторы в ходе обсуждения.
UFO just landed and posted this here
Автор, а вы как-то решаете проблему Man-in-the-middle Attack?

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

Если шифровка RSA представлена как C = M^e (mod n),
где C — шифротекст, M — открытый текст, e, n — публичный ключ, то:

Если вычислить C' = C*(M1)^e (mod n)
где M1 — желаемая модификация открытого текста, C' — модифицированный шифротекст, при этом C,e,n известны злоумышленнику — то при расшифровке шифротекста C' легитимным пользователем получим результат:
M + M1
иными словами, злоумышленник может модифицировать сообщение так, что при расшифровке к открытому тексту (который был неизвестен злоумышленнику) будет прибавлено произвольное, заданное злоумышленником, число.
Никак. Эта атака нецелесообразна для сайтов соц. сетей. Проще достать с localStorage ключики, или угнать уже расшифрованный текст с интерфейса.

При любой атака и защите от неё нужно прежде всего рассматривать рентабельность. Маловероятно, что кто-то будет сильно замарачиватся с расширением, у которого 3.5 пользователя.
Эта атака нецелесообразна для сайтов соц. сетей

Кто вам такое сказал? Атака (Man in the middle) очень легка в реализации, когда общение и обмен ключами проходят через сервер, подконтрольный атакующему.
Маловероятно, что кто-то будет сильно замарачиватся с расширением, у которого 3.5 пользователя.

Это неправильный подход при разработке криптографических решений. Фактически вы полагаетесь на принцип «неуловимого Джо». В чем тогда смысл применения сильных шифров, вроде RSA? С тем же успехом вы могли зашифровать сообщения чем-нибудь попроще, простой ксоркой с фиксированным ключом. До тех пор, пока атакующий не прореверсит ваш плагин, и такой шифр, скорее всего, не будет взломан.
Сервер соцсети — слишком большой узел, чтобы быть подконтрольным коллегам Миши, ревнивому Кириллу — или истеричке Лиде.

Опасаться такой атаки надо Толику и Леше — но на первого не смогут провести MitM-атаку еще до того, как он похвастался — а значит, дела не будет — а нет дела, нет и ордера на атаку.

Лешу же вычислят в любом случае, независимо от алгоритмов шифрования.
Только M * M1 а не M + M1. Ну и библиотека, которую использует автор, использует PKCS1.5 паддинг так что эта модификация идёт лесом (но на PKCS1.5 есть куча других атак, нужно использовать OAEP).
Да, вы правы, M*M1. Перепутал школьную формулу умножения степеней, позор на мою седую голову.
Спасибо за труд. Статья была бы более полноценной без примеров в начале, но с большим упором на техническую часть. Большинство людей на ресурсе прекрасно представляют, зачем может понадобиться шифрование :)

Два вопроса:
1. Где почитать исходники?
2. Почему не использовали готовую для таких случаев реализацию: OTR (все, что вам пришлось бы сделать — реализовать внедрение)? Если знакомы с ней, чем не понравилась?
1. Исходники можно почитать, если установить плагин и открыть панель разработчика (F12) или посмотреть папку хрома, в которую он установится. Выкладывать на github смысла не вижу.
2. Про OTR не знал.
В качестве библиотеки для шифрования использую у себя cryptojs. Лучше неё не встречал.

Ну и ещё вопрос, а как прочитать сообщение, которое мне когда-то прислали и которое было зашифровано?
Если ключи остались в localStorage — оно дешифруется. Если ключи были удаленны по какой-то причине, то уже никак. В этом и фишка. Есть возможность более менее гарантированно уничтожить написанное в соц. сети.
Т.к. взял первое, что под руку попалось. Если количество установок увеличится — буду менять алгоритм.

зы: таки да :3
Сорри, но когда Кирилл увидит, что Юля переписывается с Сережей да еще и шифрует это. ББПЕ не избежать).
Идея и статья классные.
Sign up to leave a comment.

Articles

Change theme settings