Шифруем сообщения в сети XMPP/Jabber с помощью PGP

    В этой статье я подробно опишу как использовать шифрование при передаче сообщений по сетям на основе XMPP с помощью пакета GnuPG. Показана процедура генерации ключевых пар под Windows, установка ключей в клиент Psi, проверка подписанного присутсвия, передача шифрованного сообщения.

    Мотивация


    Для чего может понадобится шифрование сообщений?
    1. Так как сеть XMPP федеративная и каждый может основать свой узел, то ставится вопрос доверия администратору данного сервера. Сервер могут сломать, сам админ может подбарижить данными и т.д.
    2. XMPP набирает популярность в качестве внутрикорпоративного обмена. Может быть сервер и не имеет выхода в Интернет, но никто не застрахован от приезда Party-van с маски-шоу внутри
    3. Цифровая подпись повышает надёжность идентификации. То есть вы точно знаете что в данный момент за компьютером сидит именно тот человек, который вам дал ключ, а не тот кто ломанул его аккаунт или воспользовался его отсутсвием его за компьютером


    Немного теории



    Сообщения шифруются с помощью криптосистемы с открытым ключом. Если не вдаваться в подробности, суть системы шифрования состоит в том, что существует пара ключей и некая процедура, которая может с помощью одного ключа преобразовать сообщение так, что обратное преобразование можно будет выполнить только с помощью другого ключа. Один из этих ключей называется закрытым и держится в тайне, другой же, напротив, называется открытым, и распространяется свободно. Таким образом, зашифровав сообщение открытым ключом можно быть уверенным, что его прочитает только владелец закрытого ключа, напротив, подписав что-то своим ключом автор даёт уверенность получателю сообщения в своём авторстве.
    Можно объединить эти две процедуры и тогда содержимое будет известно только двум лицам, обладающими соответсвующими ключами. Наглядно это изображено на картинке:


    На данный момент невозможно за обозримое время из открытого ключа восстановить закрытый.

    Инструменты



    В качестве системы шифрования мы будем использовать пакет с открытым кодом GnuPG (эй, не убегайте, это под Windiows тоже есть и очень даже юзерфрендли :)) и клиент Psi. Уверен, что в других клиентах процедура схожая. Я взял реализацию под windows, так как всё-таки её использует большинство пользователей, а юниксоиды, думаю, и сами разбирутся. В *nix в качестве удобного средства управления ключами можно посоветовать kgpg.

    Предполагаю что у вас уже стоит jabber клиент, он настроен и соединение с сетью есть.

    Шаг первый, загрузка ПО и генерация закрытого и открытого ключей


    Для пользователей Windows специально создан пакет программ gpg4win, который существенно облегчает работу с GPG. Скачиваем gpg4win lite с официального сайта, выбираем необходимые компоненты и устанавливаем.


    После установки, запускаем менеджер ключей WinPT. При первом запуске утилита предложит создать ключевую пару. Это очень важный шаг. Ключ это ваш паспорт в сети интернет, проверье внимательно имя и адрес, очень желательно его не терять и не забывать от него пароль. Восстановить закрытый ключ будет уже не возможно, придётся генерить новый. Каждый закрытый ключ шифруется паролем. Это нужно для того что бы даже если кто-то завладеет вашим ключом, злоумышленник не смог бы им воспользоваться, без пароля он бесполезен. Программа предожить забекапить ключ и это правильно.

    Итак, вы сгенерили ключевую пару. Теперь в меню WinPT нужно выбрать Key -> Export… Таким образом вы получите файл *.asc, который будет содержать что-то вроде:
    -----BEGIN PGP PUBLIC KEY BLOCK-----

    Version: GnuPG v1.4.7 (MingW32)

    mQGiBEmINMURBACJDeTglDCoq5HQ4bU6yFzqCTfYbCEjkNlMmvJK+5zesKVJhohK
    LZ6oiCZaGt5B8rfY1qvJvgIQNvWOsp63lviPSTamndlmlDeTOXbqc21iEE6E9mOS
    .....


    Это и есть ваш открытый ключ, его можно разослать друзьям и коллегам, с которыми вы собираетесь обмениваться сообщениеми. Естественно обмениваться ключами желательно через зашифрованный канал или банально переписать на CD-R/флешку. Так же можно разместить свой открытый ключ на своём вебсайте или в профайле хабра. Не буду вдаваться в подробности, но обмен ключами довольно забавная процедура, см. Web Of Trust и Key signing party

    Шаг второй, добавление своего ключа в Psi и импорт открытых ключей контактов


    Итак, теперь надо сказать Psi, что нужно использовать ключ. Запускаем Psi, идём в настройки аккаунта, там во вкладке подробности нажимаем «выбрать openPGP ключ» и указываем наш ключ.


    После выбора ключа и переподключения к сети, Psi затребует пароль от закрытого ключа:



    Теперь вы подключены к сети и ваш статус подписан. То есть те, кто имеют ваш открытый ключ, знают, что за компьютером именно вы.

    Допустим, вы обменялись с кем-то ключами, по есть отдали свой открытый ключ и получили чей-то открытый. Теперь нужно привязать ключ к конкретному аккаунту. Для этого заходим в WinPT, заходим в key->import, далее выбираем файл с ключом нужного человека. Всё, открытый ключ импортирован в систему. Стоит сказать, что Psi считывает состояние ключей только при запуске, так что после того как мы добавили новый ключ надо перезапустить Psi. Кликаем правой кнопкой мыши на нужный контакт и выбираем «Присвоить ключ OpenPGP», присваиваем контакту его ключ. Теперь мы можем проверить электронную подпись нашего контакта:



    Выделенная зелёным строчка означает, что контакт вошёл в сеть с правильным ключом и у вас есть его открытый ключ. Если строчка чёрная это означает, что статус клиента подписан, но у вас нет его ключа или ключ неверен, так что неизвестно кто там за компом.

    Шаг третьий. Обмениваемся шифрованными сообщениями


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



    Последнее сообщение в шифрованном виде выглядит так:
    <message from="ivlis_test@jabber.ru/Psi" type="chat" xml:lang="ru-RU" to="ivan@ivlis.com/WorkF53B8E96" id="aaf8a" >
    <body>[Ошибка: сообщение зашифровано, и невозможно его расшифровать.]</body>
    <active xmlns="http://jabber.org/protocol/chatstates"/>
    <x xmlns="jabber:x:encrypted">
    hQEOA/CjxWiKTl51EAP9HaQ8nzTtjUECqiO+1lcJRciUJrOLkgFr/KTqjvOmEgvx
    rtF4TCCjpBMElbVbjY+yYmV6F8IWMweRlU4olzDFfdbJYO/TGWq+22s3jIvhWI+e
    7bfMn7qVcnDD7GsGxU8norUqjKHQmYvwdAwHBDdbf/AD0qqAvb7jK+1X1NXyeioD
    /3lxyWobgoiCt165OwZu/G2osiDQlMTtzt/W198tzfpKoJURaUNkwhFJeOp3rgr0
    77frKDbIO6IRloyHx1xL3kRZNEBOVJO5AYdflH0Z756wPt+mGpZ29vzbdt40hkwu
    rHjnYEDJhj1oJkoRpesIgiPQxmXpbsRGrAcKQr2f4e3d0lgBCkkivC27qPEM0eFO
    TQnVww+RGczA+VHRbpXCRvLx4fcle9qSEM0xgdkae7IWJXBQRVEootOqdNJz49G8
    FPakyAsBoZ2XvrEqW+r6hXvLYrKGBYO2cI3F
    =ysML</x>
    </message>


    * This source code was highlighted with Source Code Highlighter.


    Можно быть уверенным, что в ближайшие 50 лет никто не сможет это прочитать.

    Заключение



    Итак, как видно, шифровать сообщения на лету очень просто, для конечного юзера не меняется практически ничего, а надёжность системы возрастает. Может быть это и сподвигнет кого-то перейти на xmpp/jabber.

    Но всегда нужно помнить:
    1. Шифрование не отменяет голову. Храните пароль от ключей в секрете, сделите за кейлоггерами, вирусами и прочим.
    2. Это


    Спасибо за внимание, надеюсь было интересно. :)
    Поделиться публикацией

    Комментарии 80

      +3
      Спасибо! :)
        0
        Пользуйтесь!
          0
          Извините, но картинка с процедурой преобразования ключей в «нечто» — не очень подходит.

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

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

              «Криптография с открытым ключом – это асимметричная схема, в которой применяются пары ключей: открытый (public key), который зашифровывает данные, и соответствующий ему закрытый (private key), который их расшифровывает. Вы распространяете свой открытый ключ по всему свету, в то время как закрытый держите в тайне. Любой человек с копией вашего открытого ключа может зашифровать информацию, которую только вы сможете прочитать. Кто угодно. Даже люди, с которыми вы прежде никогда не встречались.»

              Прочитать о криптоалгоритмах и их реализациях можно здесь: www.pgpru.com
                0
                Вы уж тогда до конца дочитайте

                https://www.pgpru.com/biblioteka/osnovy/vvedenievkripto/glava1/cifrovyepodpisi

                А ещё тут прочитайте:

                The most obvious application of a public key encryption system is confidentiality; a message which a sender encrypts using the recipient's public key can be decrypted only by the recipient's paired private key (assuming, of course that no flaw is discovered in the basic algorithm used).

                Another type of applications in public-key cryptography are digital signature schemes. Digital signature schemes can be used for sender authentication and non-repudiation. In such a scheme a user who wants to send a message computes a digital signature of this message and then sends this digital signature together with the message to the intended receiver. Digital signature schemes have the property that signatures can only be computed with the knowledge of a private key. To verify that a message has been signed by a user and has not been modified the receiver only needs to know the corresponding public key.

                To achieve authentication, and confidentiality, the sender could first sign the message using his private key, then encrypt the message and signature using the recipient's public key.

                en.wikipedia.org/wiki/Public-key_cryptography

                Картинку я взял от иллюстрации алгоритма Диффи — Хеллмана, но всё таки надо читать что под картинкой написано, а не только её саму.
                  –1
                  Хорошо, попытаюсь объяснить все еще раз (на пальцах и простыми словами):
                  1. Есть шифрование сообщения.
                  2. Есть аутентификация сообщения.

                  Шифрование сообщения — преобразование его для приватности. При ассиметр. криптовании прочитать его может только владелец секретного ключа.

                  Аутентификация (подпись) сообщения — заключение его в контейнер с целью обезопасить от модификации при передаче.

                  Каждая из вещей выполняет только свою функцию. Аутентификация не шифрует, а шифрование не подписывает.

                  В вашей статье Вы рассказываете о ШИФРОВАНИИ сообщения (т.е. как сделать так, чтобы между 2мя собеседниками состоялся приватный диалог).

                  Как аутентифицировать собеседника в вашей статье нет ни слова, т.к. эта процедура включает в себя совместную с партнером ПРОВЕРКУ ИСТИННОСТИ КЛЮЧА (сходите же по ссылке из вашей статьи: en.wikipedia.org/wiki/Key_signing_party). Обычно валидация происходит посредством продиктовки друг другу хешей ключей по телефону. НО Вы должны удостоверится, что голос принадлежит Вашему другу, либо используется инфраструктура PKI (отдельный разговор).
                  Пример в статье легко подвержен атаке «человек по середине».

                  Надеюсь все описаные мной вещи понятны.

                  Что такое и зачем нужен DH (Diffie-Hellman). Этот алгоритм позволяет создать общий секретный ключ, используя защищенные от модицикации каналы связи (кстати в русской вики этот важнейший момент упущен). т.е. e-mail не пригоден для генерации общего секретного ключа (см. man-in-the-middle).
                  Это дает возможность создать ШИФРОВАННОЕ (но НЕ АУТЕНТИФИЦИРОВАННОЕ) соединение между 2мя узлами.

                  НО в вашем примере DH не испольуется, в силу того, что оба пользователя уже имеют публичные сертификаты друг друга и могут без прегенерации «общего секрета» начать защищенный (но не валидированный) обмен данными.
                    0
                    Естественно обмениваться ключами желательно через зашифрованный канал или банально переписать на CD-R/флешку.


                    Про сверку там всё написано, ниже в комментах тоже. Ещё раз, от DH там одна картинка, которая иллюстрирует что к сообщению применяются два ключа.
                      0
                      Все верно, только ключи применяются совершенно по-другому!
                      Картинка относится ТОЛЬКО к процедуре DH! Никакого shared secret в криптографии с открытым ключем НЕТ! Есть ОТДЕЛЬНО процедура ШИФРОВАНИЯ сообщения к Bob'у его публичным ключем и ПОДПИСЬ этого сообщения ключем Alice.
                      Из статьи в педивикии (en.wikipedia.org/wiki/Public-key_cryptography) Вам нужно было скопировать картинку 2 — для иллюстрации шифрования/дешифрования сообщения И картинку — 3 — для иллюстрации подписи.
                        0
                        как я понял, знания криптографии на сим у топикстартера закончились.
                        Надеюсь мое время на ликбез было потрачено не даром.
        0
        «фередеративная» сеть? :)
          +2
          Ровный почерк всегда не был моим коньком :)
          +1
          Есть одно существенное НО — хистори не шифруется.

          Посему для конфедициальной переписки я бы рекомендовал использовать почту. Большинство почтовых клиентов сохраняет зашифрованную корреспонденцию в зашифрованном виде.
            0
            Хистори надо отключить, да.
              +1
              Вот еще. Надо просто шифровать ее внешними способами :)
            0
            Кстати, в джббере есть ещё E2E шифрование. Не раскажете о нем? (поддерживает по крайней мере Gajim)
              0
              Поставлю Gajim, посмотрю что это за зверь такой.
                0
                Gajim зверь во всех отношениях приятный, но имейте ввиду что многие вкусности, в том числе и gnupg, недоступны в версии для windows
            • НЛО прилетело и опубликовало эту надпись здесь
                0
                Actual actual reality: nobody cares about his secrets.  (Also, I would be hard-pressed to find that wrench for $5.)
                  +1
                  Сразу видно мягкотелую европу, до сурового российского ректального криптоанализа им еще расти и расти :)
                    0
                    Upd: Картинка — реакция на фразу «Можно быть уверенным, что в ближайшие 50 лет никто не сможет это прочитать» ;)
                      +2
                      Посмотрите на предпоследнюю ссылку в посте.
                      +2
                      >загрузка ПО и генерация *закрытого и закрытого* ключа
                        0
                        fixed
                        0
                        А мне интересно, как будут храниться хистори? Если в зашифрованном виде, то как можно их прочитать потом? (если на другом компе захочется прочитать).
                          +2
                          PGP — это все-таки не алгоритм, а криптосистема. И основное ее предназначение как раз то, что вы назвали «весьма забавной процедурой» — управление ключами.
                          А алгоритм там используется RSA, если не комбинация с каким-либо блочным алгоритмом, в которой асимметричное шифрование ипользуется только для передачи сеансового ключа.
                          Поправьте заголовок.

                          «Шаг третьий. Обмениваемся шифрованными сообещниями»
                          очепяточки
                            –1
                            Алгоритм это последовательность действий и условий, а не обязательно программа, а тут в действия входят и обмен ключами.
                              0
                              Я и не говорил о PGP как о программном коплексе. Я говорил о PGP как о инфраструктуре открытых ключей, аналогами которой являются X.509, PKI и SPKI, и которая стандартизирована под именем OpenPGP.

                              В этом смысле PGP предусматривает самостоятельное урпавление ключами: пользователь берет на себя функции CA и подписывает открытые ключи других пользователей. Ключи, которым доверяет отдельный пользователь, объединяются в кольцо ключей, при этом каждый пользователь самостоятельно контролирует это кольцо. Проблема этой схемы — это проблема каскадного обновления колец в случае компроментации одного из ключей.

                              Называть это «алгоритмом» — подменять общепринятые понятия своими. То же самое, кстати, если рассматривать PGP как программный продукт. Так что заголовок все же лучше изменить
                                0
                                Убедили
                              0
                              Согласен, фраза «PGP алгоритм» звучит нелепо.
                              И про алгоритм — в приведенном сообщении используется Эль-Гамаль, а не RSA, плюс еще какой-то симметричный алгоритм.
                              0
                              Поведайте пожалуйста какие еще джаббер клиенты можно подобным образом зашифровать??? а то к qip доверие пропало после известий о том что он пароли у себя на сервере хранит :)
                                0
                                По поводу «пароли у себя на сервере» — предложите сначала безопасную схему аутентификации с использованием пароля без хранения пароля на сервере, а потом уже критикуйте хранение паролей.
                                  0
                                  1) Хранить хеш пароля
                                  2) Аутентификация по ключам, как в openvpn
                                  3) Аутентификация по смарткартам (для криптоманьяков)
                                    0
                                    1) А полностью схему покажите, при которой пароль не передаётся по сети в открытом виде и не хранится на сервере?

                                    2 & 3) Я вопрос задал про парольную аутентификацию. У ключей есть свои плюсы и свои минусы.
                                      0
                                      Передать хеш пароля, не?

                                      У ключей только один недостаток — человеческая лень.
                                        0
                                        Ну если мы просто храним хэш пароля и передаём тот же хэш пароля, то секретным является не сам пароль а хэш пароля, таким образом злоумышленнику не надо знать сам пароль, чтоб представится нами, достаточно знать хэш пароля.

                                        У ключей еще один недостаток — запомнить 256 байт сложно, т.е. пароль вы можете просто ввести на любом компьютере и попасть в жаббераську, а ключ надо обязательно таскать с собой на каком-нибудь носителе.
                                          0
                                          Ну естественно хешировать при передаче не сам пароль, а, например, строку «текущее время+хеш пароля». Ну и мы считаем, что при регистрации пароль не был сворован. От этого спасут только ключи.

                                          Ну и SSL никто не отменял тоже да.

                                            0
                                            Ну а тогда если мы хэшируем не сам пароль, а «время+пароль», как сервер сможет сверить хэш с настоящим, не храня пароль у себя? ;-)

                                            Я даже не спрашиваю про то, как вы собираетесь обеспечить совпадение времени на сервере и клиенте, эта проблема еще худо-бедно решаема.
                                              0
                                              На сервере хранится хеш пароля. Он генерит hash(time+shadow), а на клиенте генерится hash(time+hash(password)). Если строки совпали — всё ok.

                                              Можно не время использовать, а какую-то строку с сервера передавать к клиенту в качестве опорной.
                                                0
                                                Если я правильно понимаю, что shadow == hash(password), то вы просто подменили пароль его хэшем, т.е. злоумышленнику не нужно знать сам пароль, а достаточно знать его хэш для того, чтобы авторизоваться.
                                                А если достаточно знать хэш, а не пароль, то по факту паролем является то, что вы называли «хэш пароля».
                                                  0
                                                  Да, но откуда же он его возьмёт то этот хеш оригинальный?

                                                  Мы считаем что во время регистрации взлома нет.
                                                    0
                                                    Речь как я понимаю была о том, что сервер хранит у себя секрет, зная который, можно представится пользователем, разве не так? Ваша схема этот недостаток также содержит.

                                                    Например, зная соль+хэш из shadow-файла unix-системы представиться пользователем нельзя, т.к. пароль передаётся в открытом виде как во время ввода его с физического терминала, так и во время ssh-соединения. В случае ssh-соединения он передаётся по зашифрованному каналу и подлинность сервера проверяется по known_hosts.
                                                      0
                                                      Идея в том, что один пароль некоторые юзеры используют для нескольких аккаунтов. И если ломанут базу квипа, например, то получат доступ к туевой хуче емайлов бландинок у которых один пароль, только и всего.
                                                        0
                                                        Если два сервиса используют ваш протокол авторизации получается опять таки ерунда, т.к. зная хэш сломавший базу квипа сможет авторизоваться на всех этих сервисах.
                                                        А если ваш протокол может использоваться только на одном сервисе — грош цена этому протоколу.

                                                        На самом деле я не знаю, возможна ли принципиально безопасная аутентификация по паролю как без передачи его в открытом виде и так и без хранения на сервере. Может быть в криптографии это доказывается, но в любом случае я не видал пока протоколов аутентификации по паролю, которые удовлетворяют обоим этим свойствам.
                                                          0
                                                          Ну никто и не говорит что пароль это секьюрно.
                                                            0
                                                            Итого, мы пришли к мнению, что ответом на вопрос
                                                            … предложите сначала безопасную схему аутентификации с использованием пароля без хранения пароля на сервере, а потом уже критикуйте хранение паролей.

                                                            является простое «идеальной схемы с использованием паролей не существует», что я и подразумевал с самого начала.

                                                            :-)
                                                              0
                                                              О, сервер хранит hash(password + servername), тогда эти хеши никак не пригодятся на другом сервере.
                                                                0
                                                                Поздравляю, вы, если не ошибаюсь, изобрели Digest access authentication!

                                                                Там действительно пароль на стороне сервера хранится не обязан, и достаточно хранить HA1 = hash(username + servername + password), таким образом получив базу данных HA1 злоумышленник действительно сможет залогиниться на сервис, но только на него.

                                                                Это решает проблему блондинки с одним паролем на все случаи жизни, но не решает проблему с тем, что утечка базы данных ведет к возможности тривиального входа в систему от имени любого пользователя.
                                                                  0
                                                                  Чувствую себя великим :)

                                                                  Я собственно к этому и клонил. Если базу квипа заломали, то понятно получили уже доступ ко всему квипу.
                                                                    0
                                                                    Не боги RFC пишут :-)

                                                                    Я говорил про идеальный вариант — когда получение хэшей не даёт также и провести аутентификацию. Тот же самый пример в /etc/shadow — что после получения хэша пароль всё равно приходится брутфорсить.
                                                                    Как показывает практика, возможность стянуть базу не равна рутовому доступу к серверу. Типичный пример — забыли обезопасить бэкапы базы.
                                  0
                                  Вроде как под windows из юзабельных только psi.
                                  –2
                                  От себя могу порекомендовать более простые и универсальные решения E2E криптования IM под Windows. Это IMsecure от ZoneAlarm и более распространенный и продвинутый Simp от Secway. Обе бесплатны при использовании с одним аккаунтом, например, с ICQ или Jabber, а Pro версии обеспечат шифрование всех клиентов всех сетей.

                                  Также не стоит забывать плагины IMsecure для миранды и триллиана — они также прозрачно зашифруют сообщения.

                                  И само собой не стоит забывать, что шифраторы должны стоять на обоих «концах», все-таки end-to-end
                                    +3
                                    Что-то я не особо понимаю в чём профит юзать закрытые платные аналоги, если есть открытый, бесплатный и неуступающий по удобству?
                                    0
                                    А нафига зашифрованный канал для передачи открытого ключа? :) В этом вроде и фишка такого шифрования, что можно не парица и передавать открытый ключ куда угодно. А если нужна идентификация от кого пришло — то ЕЦП в помощь :)
                                      0
                                      Нужно обеспечить достоверность открытого ключа, т.е. что он не был подменён при передаче.
                                        0
                                        Естественно, если канал УЖЕ шифрованный — не ясно, что мешает им пользоваться. Ну и ссылка про key signing party в статье есть.
                                        0
                                        Потому что в таком случае система подвержена Man In Middle атаке. Кто-то может перехватить открытый ключ и вместо него выслать подделку, которая соответсвует уже другому закрытому ключу. От этого должны спасть CA, но это уже перебор для личного общения, imho :)
                                        0
                                        Странно, что никто не написал про OTR: www.cypherpunks.ca/otr

                                        Всё же описанный способ очень долог в настройке.
                                          0
                                          Минут 15 не больше.
                                            0
                                            OTR настраивается где-то минуты 2, а то и меньше.
                                              0
                                              И имеет кучу недостатков.
                                                0
                                                А можно подробнее, очень интересно?
                                        0
                                        Така защита ни разу не оптимальна: в каждом сообщении посылается дополнительно 2кб данных (+30% изза Base64 кодирования), плюс шифрование/расшифровка каждого сообщения занимает достаточно времении. Гораздо умнее было бы сделатьодноразовый обмен сессионными симметричными ключами.
                                          0
                                          А кто говорил что система с открытым ключом оптимальна вообще?
                                            0
                                            Вопрос не в системе с открытым ключем, а способе ее использования.
                                              0
                                              В жаббере нет системы сессий, imho.
                                                0
                                                Так зачем сессии? просто один раз обменятся сессионными ключами, а потом уже шифровать сообщения только симметричным алгоритмом.
                                                  0
                                                  Я думаю это очень просто реализовать как расширение жаббера, будет здорово, если кто-то займётся.
                                                    0
                                                    Реализовать несложно, но для большинства применений достаточно TLS/SSL от клиента к серверу, и между серверами.
                                                      0
                                                      ну а кому остальным досататочно pgp и они не парятся на счёт трафика. :)
                                                  • НЛО прилетело и опубликовало эту надпись здесь
                                                      0
                                                      Ну, тут думаю не проблема — установить срок годности ключа в какое-то определенное время (час, два часа, сутки...)
                                            0
                                            Ктонибудь сталкивался с такой проблемой? В миранде использую плагин SecureIM + tabSRMM. Установили соединение с человеком. Ключами обменялись, всё окейно. Всё подтверждено, в этом плане всё ок.

                                            Но сообщения от меня отсылаются крякозябрями (я так понимаю utf8), но почему такое происходит?



                                            И как этого избежать, кто с такой проблемой сталкивался, помогите плз
                                              0
                                              Все ясновидящие в отпуске, хотя бы версии ядра и плагинов написали.
                                              Почти всегде помогает: letmegooglethatforyou.com/?q=SecureIM+unicode
                                                0
                                                извиняюсь, забыл в порыве гнева версдамп скинуть, но, я уже разобрался, оказывается нужно было обновиться, обновления нашел на других сайтах, на addons.miranda-im.org не было(

                                                Было:
                                                ¤ cryptopp.dll v.1.0.2.2 [2008-04-23 08:54:26+0300] — Crypto++
                                                ¤ SecureIM.dll v.1.0.10.9 [2008-04-23 08:51:36+0300] — SecureIM (2in1)

                                                Стало:
                                                ¤ cryptopp.dll v.1.0.3.0 [2008-09-17 15:27:48+0300] — Crypto++
                                                ¤ SecureIM.dll v.1.0.11.0 [2008-09-17 15:27:58+0300] — SecureIM (2in1)

                                            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                            Самое читаемое