21 ноября, среда 06:41
Bankir.Ru

Объявление

Свернуть
Пока нет объявлений.

iBank - хендшекинг в криптопротоколе

Свернуть
X
  • Фильтр
  • Время
  • Показать
Очистить всё
новые сообщения

  • iBank - хендшекинг в криптопротоколе

    Дабы не засорять топик "Сравнение систем Интернетбанкинга", я открыл отдельную тему, посвящению обсуждению хендшекинга в криптопротоколе iBank'а.

    Далее идет ответ Волчкову
    Как тошно объяснять неспециалисту, что он не специалист.
    Это точно - совершенно невозможно дискутировать с оппонетом, считающим себя высококлассным специалистом, но не могущем ответить ни за написанные им же слова!, ни на элементарные прямые вопросы :

    "Какой транспьютерный модуль на каких транспьютерах и с какими FPGA Xilinx использовались (или предлагается к использованию) для подбора секретного ключа ЭЦП в экспериментах по вскрытию iBank'а за 5 минут?".

    Как всегда любые попытки конструктивного диалога с Волчковым Алексеем, онный по-пиаровски преобразует в высокомерные, но совершенно пустые обвинения.

    1. Для обеспечения стойкости равной стойкости 1024 битного RSA достаточно ичпользовать 512 битный DH на арифметике больших чисел или 256 битный DH на эллиптических кривых, далее все + RSA можно заменить на -
    Алексей, мы не ставили задачу сравнения криптостойкости 1024-битного RSA и 512-ти битного DH.

    Я предлагал тебе, Алексей, самую что ни на есть конкретную и простую задачу - дать краткое описание предлагаемого тобой хендшекинга на основе DH. У тебя была ТАКАЯ возможность проявить весь твой профессионализм!!!

    Тебе следовало "развернуть боевые знамена волчковского пиара", дать полное описание твоего варианта хендшекинга (а лучше протокола), с конкретными цифрами показать на порядки более высокую стойкость, с конкретными цифрами показать на порядки более низкие издержки процессорных ресурсов на математических операциях для клиента и сервера, с конкретными цифрами показать в десять раз более компактный трафик с полным отсутствием избыточности. Короче - за пояс заткнуть БИФИТ и показать сколько денег банки и их клиенты потеряли на издержках связи, избыточности оборудования и потери времени из-за использования в iBank'е RSA вместо DH

    2. Если Вы не знаете как делается аутентификация на DH....
    Я совершенно в курсе КАК делается аутентификация на DH, и, если серьезно, именно поэтому я предлагал тебе, Алексей, построить автомат, описывающий хендшекинг, дабы ты не занимался очередными теоретическими изысканиями, а сам лично на практике посмотрел на количество требуемых сложных математических операций с большими числами на клиенте и на сервере (а сей ресур чрезмерно дорогой, и требует минимум процессорных затрат на одну транзакцию).

    Дабы ты сам лично посмотрел на количество передаваемых байт в каждую сторону, на количество TCP и IP пакетиков, вносящих свою избыточность в трафик и свои задержки во взаимодействии.

    Но ты всё остаешься "теоретиком"

    P.P.S. В корректном переводе с английского "примитив под модулю n" звучит так - элемент максимального периода поля Fn, или примитивный элемент поля Fn.
    Алексей, спасибо за "ликбез" ! Я очень рад, что ты так просто и быстро понял о чем идет речь, смог осилить интерпретацию столь "некорректного термина", и наконец-то воспользовался возможностью проявить весь твой профессионализм теоретика. Молодец Бурные аплодисменты

    С уважением, Репан Димитрий
    Компания "БИФИТ" - www.bifit.com
    С уважением, Репан Димитрий
    Компания "БИФИТ" - www.bifit.com

  • #2
    Димитрий
    Алексей, мы не ставили задачу сравнения криптостойкости 1024-битного RSA и 512-ти битного DH. Правильно не ставили, потому что если бы поставили, поняли бы,ч то DH лучше.
    Я совершенно в курсе КАК делается аутентификация на DH, и, если серьезно, именно поэтому я предлагал тебе, Алексей, построить автомат, описывающий хендшекинг, дабы ты не занимался очередными теоретическими изысканиями, а сам лично на практике посмотрел на количество требуемых сложных математических операций с большими числами на клиенте и на сервере (а сей ресур чрезмерно дорогой, и требует минимум процессорных затрат на одну транзакцию).
    Вот здесь у Вас ошибочка. Если сравнить схемы хендшекинга в продукте Jet "Тропа" и в продукте Инфотекс "VIP Net", чем я в свое время занимался, есть отчет, который принадлежит не мне, то молжно увидеть, что при том же уровне стойкости схема DH, увеличивает трафик на 20-25% по сравнению с незащищенным, а схема RSA на 110-115%.
    По поводу сложности вычислени спорить уже надоело, но Вы должны знать, что в DH, при длине ключа 512 бит используются 160 битные показатели,а сокращение длины размера модуля по сравнению с RSA в двое дает выигрыш по скорости в 8 раз.

    Я предлагал тебе, Алексей, самую что ни на есть конкретную и простую задачу - дать краткое описание предлагаемого тобой хендшекинга на основе DH. У тебя была ТАКАЯ возможность проявить весь твой профессионализм!!!

    После того, как лично Вы Димитрий продемонстрировали "свое порядочное отношение к экспертам" и "готовность к сотрудничеству" в августе 2000. Разговор о конкретных разработках для Вас может идти только на основе 100% предоплаты, а может быть и вообще не может идти, это как коллеги решат.
    Поэтому Ваши призывы прислать Вам описание чего либо "на халяву" пропадают в туне.


    Алексей.

    Комментарий


    • #3
      отправил Волчков Алексейх
      при том же уровне стойкости схема DH, увеличивает трафик на 20-25% по сравнению с незащищенным, а схема RSA на 110-115%
      Алексей, сеи цифры, IMHO, некорректны

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

      В транзакции в качестве данных может быть передано и 8 байт, и 8 Кбайт - это уже дело прикладного уровня. Поэтому говорить об избыточности в отношении RSA и DH следует в абсолютных числах - столько то байт идет на хендшекинг при использовании RSA, столько то байт идет на хендшекинг при использовании DH.

      По поводу сложности вычислени спорить уже надоело, но Вы должны знать, что в DH, при длине ключа 512 бит используются 160 битные показатели,а сокращение длины размера модуля по сравнению с RSA в двое дает выигрыш по скорости в 8 раз.
      Алексей, ты и здесь лукавишь

      В 8 раз, Алексей, получается, если считать 1024-битную экспоненту в лоб.

      Если же знать множители N = P*Q, а в случае RSA на стороне сервера мы их как раз и знаем, сложность вычислений такой 1024-битной экспоненты сводится практически к вычислению двух модульных экспонент с модулем 512 бит. Соответственно сложность вычисления RSA-1024 со знанием P и Q всего лишь в 2 раза, а не в 8 раз, выше сложности вычисления DH с модулем 512 бит. Ну если быть максимально точным, с учетом трех обычных модулей, двух умножений, одного вычитания и максимум двух сложений, больше в 2,1 раза

      С уважением, Репан Димитрий
      Компания "БИФИТ" - www.bifit.com
      С уважением, Репан Димитрий
      Компания "БИФИТ" - www.bifit.com

      Комментарий


      • #4
        Алексей, сеи цифры, IMHO, некорректны

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

        В транзакции в качестве данных может быть передано и 8 байт, и 8 Кбайт - это уже дело прикладного уровня. Поэтому говорить об избыточности в отношении RSA и DH следует в абсолютных числах - столько то байт идет на хендшекинг при использовании RSA, столько то байт идет на хендшекинг при использовании DH.

        Я действительно здесь наверное не свосем корректен, поскольку должен был показать при каких условиях тестировались продукты.
        И откуда взялась разница в 5%. Тестирование проводилось на основе генерации пакетов, соответствующих типовому трафику различных сетей, напримир один из вариантов - оценка увеличения трафика при установлении соединения клиент (броузер) и WEB сервер, заполнение форм, и т.д.. Второй варинат - для FTP протоколоа, третий для микшированного трафика VoIP, Video, Data и т.д.
        Приведенные оценки средневзвешенные, в Вашем случае (закачка апплетов, прикладные транзакции до 8 килобайт) это соотношение будет примерно 25% 95% в пользу DH.

        Оценим теперь скорость возведения.

        На стороне сервера мы имеем возведение 512 битных чисел в 512 битные причем два таких возведеня, или отбрысывая константы 512*512*512.
        Или 134*(10**6). Для DH на 512 бит имеем 512*512*80 = 20*(10**6) или в 7 раз быстрее.

        При схземе DH, при переходе к эллиптическим кривым, которые Вам судя по всему понадобяться для ГОСТ, ситуация будет еще очевиднее в сторону DH.

        Алексей.

        Комментарий


        • #5
          отправил Волчков Алексей
          Приведенные оценки средневзвешенные, в Вашем случае (закачка апплетов, прикладные транзакции до 8 килобайт) это соотношение будет примерно 25% 95% в пользу DH.
          Откуда такие цифры - ума не приложу. Алексей, может что-то с прямым углом путаешь?!

          Для случае iBank'а с хендшекингом на основе RSA, онный добавляет к трафику:
          - 136 байт от клиента серверу (8 байт + 128 байт)
          - 37 байт от сервера клиенту (32 байта + 5 байт)

          При схземе DH, при переходе к эллиптическим кривым, которые Вам судя по всему понадобяться для ГОСТ, ситуация будет еще очевиднее в сторону DH.
          Об использовании в хендшекинге DH c элипптическими кривыми - не спорю, надо все аккуратно посмотреть и посчитать.

          С уважением, Репан Димитрий
          Компания "БИФИТ" - www.bifit.com
          С уважением, Репан Димитрий
          Компания "БИФИТ" - www.bifit.com

          Комментарий


          • #6
            Димитрий
            Откуда такие цифры - ума не приложу. Алексей, может что-то с прямым углом путаешь?!
            Я уже упоминал, что сравнивались эквивалентные по стойкости схемы, т.е. при той же стойкости длина чисел для DH может быть меньше, а следовательно протокол компактнее. У Вас числа по 1024 бита, т.е. по 128 байт, а в DH - по 64 быйта, кроме того подпись в DH, с использованием алгоритма ШНОРРА сокращается до 27 байт. Отсюда и выигрыши.


            Алексей.

            Комментарий

            Пользователи, просматривающие эту тему

            Свернуть

            Присутствует 1. Участников: 0, гостей: 1.

            Обработка...
            X