SavePearlHarbor

Още едно копие на хабора

Главно меню

След навигация

Здравей Хабра! Темата за криптиране на лична кореспонденция е обсъждана многократно. Но всъщност не открих нищо повече или по-малко здравомислещо, отколкото бих могъл да използвам без хемороиди. Затова написах разширението си за социално. мрежи с покер и куртизанки. Тъй като днес е петък, първата половина на публикацията се състои от весели картинни истории. Във втората част - няколко проблема и начини за тяхното решаване.

Защо се нуждаете от криптиране

Любовна история

Миша обича да си кореспондира с Катя на работа. Често си пишат различни неприлични неща. Веднъж Миша се прибрал и забравил да изключи компютъра си. На този ден колегите му научиха много за личния живот на Миша. Но за всичко Миша и Катя трябваше да използват криптиране.

Историята на ревнив съпруг

Серьожа пише поезия за любовта на Юлия. Джулия отвръща. Кирил е тъжен. Той е съпруг на Джулия и подозира нещо. Скоро той ще прочете кореспонденцията между Серьожа и Юлия и ще уреди BBPE за жена си. Джулия можеше да се отклони от темата и да избегне BBPE, ако знаеше повече за криптирането.

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

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

История за бунтове

Леша има активна гражданска позиция. Леша обича да събира приятели и да организира шумни срещи на градския площад. Леша кани гости на тези срещи чрез Интернет. Програмистът Артьом прегледа цялата лична кореспонденция и бързо разбра кой е организаторът на масовите тържества. Сега Леша има проблеми. Можеше да ги избегне, като шифрова съобщенията си.

Истерична история

Света изпрати съобщение до Глеб. Но Глеб се среща с Лида. Глеб отиде до тоалетната и забрави мобилния си телефон. Лида прочете съобщението на Света. След около минута Лида ще вдигне скандал.

Как работи криптирането

Тимур има куфар и ключ. Предава празен куфар на приятеля си Саша.

Саша също има свой куфар и ключ. Той прави копие от тях и го крие в куфара на Тимур.

Защото куфарът се връща затворен, само Тимур може да го отвори. Единствено Тимур има ключа от куфара си.

Тимур отваря куфара си и вади копие от куфара и ключа на Саша.

Сега Тимур вече не се нуждае от куфара и ключа си. Той може да използва тези, които Саша му е дал.

Ето как работи RSA алгоритъмът за криптиране. И ето как изглежда бързото дешифриране на криптографски алгоритъм с помощта на терморектален криптоанализатор.

Техническата страна на въпроса.

Избрах RSA като алгоритъм за криптиране. Въпреки факта, че алгоритъмът е на около 30 години, първите JS библиотеки, които попаднаха, бяха с изключително лошо качество. Изглежда, че те са написани изключително за един проект. С мъка и болка успях да ги адаптирам към нуждите на моя проект, въпреки че задачите бяха типични:

Генериране на ключове
Шифроване на текст с публичен ключ
Дешифриране на текст с частен ключ

Също така бях изненадан, че при половината подобни разширения трябва да измислите някои фрази, да ги прехвърлите по някакъв начин и т.н. Въпреки че изглежда, че хората отдавна предават криптиране по отворени канали и процесът се поддава на автоматизация.

Проблеми със социалния разбор мрежи.

Започнах с ВКонтакте. Първата трудност е, че всеки диалогов прозорец създава свое поле за въвеждане и поле за показване на съобщения. Проблемът беше решен чрез получаване на идентификатора на събеседника.

След това беше необходимо да се прихване натискането на бутона "Изпращане" и бутона Enter. Проблемът е, че първият затваря събития в контакт и едва след това приставката се инициализира. За да поправя ситуацията, добавих свои собствени манипулатори към document.body и след това филтрирах всички прихванати събития. Трябваше първо да ги получим, за да имаме време да заменим оригиналното съобщение с криптирано.

Съучениците на сайта показаха, че това не е достатъчно. Максималната им дължина на съобщението е 3000 знака, а шифрованата двойка ключове има дължина 3800. В допълнение, обикновените съобщения също стават по-дълги поради преобразуване в base64. Трябваше да напиша механизъм, който да раздели съобщенията на части, да ги подпише (идентификатор, текущ индекс, общ брой части) и след това да ги събере отново. Оказа се нещо като пакети в TCP/IP.

Тогава трябваше да се науча как да генерирам събитието "Изпращане на съобщение", защото скриптът, необходим за изпращане на пакети от само себе си. Във ВКонтакте проблемът беше решен много просто чрез извикване на глобалния метод IM.send (). За да стигна до обхвата на сайта от обхвата на разширението, трябваше да добавя SCRIPT тага и да напиша извикване на метод там като линия. Пример:

Тук трябва да се изясни, че DOM за сайта и разширението са еднакви, но глобалният обхват е различен. Не можах да намеря подобен метод в съучениците си. Момчетата минимизират кода и не използват глобали. Трябваше да емулирам събитието на бутона „Изпрати“:

Когато текстът беше шифрован, разделен на части, изпратен и сглобен, беше необходимо да се прави разлика между нови и стари съобщения, които се показват на сайта. Както VKontakte, така и в съученици се подписват с дата или уникален идентификатор ... Мислех си ... Никога не съм грешал толкова. След това се появи „плаващ“ бъг. Оказа се, че всички тези етикети могат, по един или друг начин, да съвпадат за две различни съобщения. Затова започнах да присвоявам атрибута си на всички DOM възли, за да разбера кой вече е обработен и кой не.

Но чудесата не свършиха дотук. Съучениците публикуваха съобщение, след което го замених с дешифрирано, след това се случи някаква магия и след няколко милисекунди съучениците отново написаха оригиналния текст, същия HTML елемент. Трябваше да направя клонинг на възела за съобщения, да напиша там стенограма и да скрия оригиналния елемент. Оригиналният възел е скрит (дисплей: няма), но не е изтрит. Не знаех как и защо се пренаписва. Имаше опасност от счупване на скрипта на съученици, ако HTML елементът бъде премахнат.

Последната мистерия на социалния разбор мрежи беше, че ако няколко души са влезли от един компютър, тогава техните двойки ключове за диалогови прозорци трябва да бъдат запазени на различни места. Проблемът беше решен чрез извличане на текущия потребителски идентификатор. Познаването на потребителския идентификатор направи възможно създаването на лични записи в localStorage: