1. C++ / Говнокод #11528

    +12

    1. 01
    2. 02
    3. 03
    4. 04
    5. 05
    6. 06
    7. 07
    8. 08
    9. 09
    10. 10
    11. 11
    12. 12
    13. 13
    14. 14
    15. 15
    16. 16
    17. 17
    18. 18
    19. 19
    20. 20
    21. 21
    22. 22
    23. 23
    void EllipticPoint::Add(const EllipticPoint &b, const EllipticCoord &a, const EllipticCoord &p, EllipticPoint &res) {
        if (!x.IsNotZero() && !y.IsNotZero()) {
            res = b;
        } else if (!b.x.IsNotZero() && !b.y.IsNotZero()) {
            res = *this;
        } else if (x.Compare(b.x)!=0) {
            EllipticCoord tmp1, tmp2, lambda;
            b.x.Sub(x,p,tmp1); tmp1.Invert(p,tmp2);
            b.y.Sub(y,p,tmp1); tmp1.Mul(tmp2,p,lambda);
            lambda.Mul(lambda,p,tmp1);
            tmp1.Sub(x,p,tmp2); tmp2.Sub(b.x,p,res.x);
            x.Sub(res.x,p,tmp1); lambda.Mul(tmp1,p,tmp2); tmp2.Sub(y,p,res.y);
        } else if (y.Compare(b.y)==0) {
            EllipticCoord tmp1, tmp2, tmp3, lambda;
            x.Mul(x,p,tmp1); tmp1.Add(tmp1,p,tmp3); tmp1.Add(tmp3,p,tmp2); tmp2.Add(a,p,tmp1);
            y.Add(y,p,tmp2); tmp2.Invert(p,tmp3); tmp1.Mul(tmp3,p,lambda);
            lambda.Mul(lambda,p,tmp1); tmp1.Sub(x,p,tmp2); tmp2.Sub(x,p,res.x);
            x.Sub(res.x,p,tmp1); lambda.Mul(tmp1,p,tmp3); tmp3.Sub(y,p,res.y);
        } else {
            res.x.SetZero();
            res.y.SetZero();
        }
    }

    Из моего велосипеда четырехлетней давности.
    Кусочек реализации ГОСТ Р 34.10-2001.

    Запостил: bormand, 03 Августа 2012

    Комментарии (24) RSS

    • Ну это вообще Java.
      Ответить
      • > Ну это вообще Java.
        Ага. Решение не самое удачное было.

        Стоило, наверное, всякие p и a вынести в отдельный класс EllipticField, и добавить всем точкам и координатам ссылочку на поле, в котором они находятся. Тогда можно было бы и обыкновенные операторы запилить...
        Ответить
    • Ну и как велосипед? Катаетесь?
      Ответить
    • Курсовая - Шифрование Гост Р 34.10-2001 (C++ Builder)
      Программа шифорвания по Госту Р 34.10-2001. Написана на C++ Builder
      Купить работу за ~80руб. или 3$
      Ответить
      • "3$"
        Пендосы ставят доллар во главу.
        Ответить
      • Да нет, не курсовик. Просто разбирался с отечественной криптографией.
        Там еще был хэш по госту 34.11 и симметричное шифрование по госту 28147-89.

        P.S. Классы были названы в стиле Кэпа - Gost28147, Gost3411, Gost3410 ;)
        Ответить
    • Хабр: «ГОСТ 34-й серии для сисадминов, начинающих фрилансеров и всех заинтересованных (часть 2)»
      Дата: 3 августа 2012 в 17:12

      Прочитали и вспомнили своё?
      Ответить
    • Мне всегда было любопытно. Насколько высока вероятность лопухнуться и при самостоятельной реализации годного криптоалгоритма сделать уязвимый вариант?
      Ответить
      • 1/2
        Ответить
      • http://ithappens.ru/story/5349
        Ответить
        • Весьма достоверный источник.
          Ответить
        • Звучит как-то надуманно. Нет, не буду спорить, украденный хэш они могли восстановить, но весь вопрос в том, а были ли пароли у пользователей эдак килобайт длиной и состояли из разных случайных символов.
          Ответить
        • то есть, если я правильно понял, в базе хранились хэши, сгенерированные неправильным алгоритмом? Тогда вроде как маловероятно, что этим хэшам соответствуют какие-то словарные пароли.
          Ответить
          • Плюсую. Если это был невесть какой хеш, то "реальный", подбрученый кулхацкером пароль с огромной вероятностью не был чем-то вменяемым. Мог даже содержать символы вне "слышимого диапозона", не вводимые с клавиатуры. А это значит, что нужны невесть какие вычислительные мощности, что бы перебирать все подряд символы.
            Ответить
        • Истории с ithappens правдивы точно так же, как истории рыбаков или охотников ;)
          Ответить
      • В симметричных шифрах и хешах любая ошибка в коде вылезет на первом же шифровании/хешировании. Разве что при наборе s-box'а можно в паре цифр накосячить... Поэтому тут ошибки очень маловероятны.

        А вот в ассимметрике - вполне можно лопухнуться, особенно если реализовывать операции над большими числами самостоятельно (как я и делал), и пропустить какой-нибудь крайний случай, который выпадает раз в 100 лет...
        Ответить
        • > вылезет на первом же
          Это если верифицировать заранее известным источником с теми же парами <ключ, плейнтекст>. Если же по принципу "сам зашифровал, сам расшифровал" - тут уже нужно детально исследовать реализацию.

          > вполне можно лопухнуться
          Вполне. Даже без длинной арифметики. Где-то выбрал "слабое" число, где-то простые числа не такие и всё.
          Ответить
          • > где-то простые числа не такие
            А где-то простые числа не простые ;) Если тест на простоту криво реализован... А они длинные и хрен проверишь...

            И, на самом деле, даже правильная реализация может пострадать от хренового ГПСЧ, типа rand(), который выдает жалкие 4 миллиарда вариантов...

            P.S. Я согласен, что не нужно изобретать велосипеды для продакшена. Но для души то можно? ;)
            Ответить
            • Можно-можно. Весь вопрос в целесообразности. Одна из главных целеобразующих возможностей - разобраться и понять, как же оно работает. Я так в своё время пошагово разобрал MD5 (но уже всё забыл подчистую).
              Последнее, что я делал с криптографией - пытался заюзать в софтине Windows CryptoAPI. Собрал все-все-все возможные грабли из всех возможных и немного ещё.
              Ответить

    Добавить комментарий