• Стоит ли использовать RSA?

    Deerenaros
    @Deerenaros
    Программист, математик, задрот и даже чуть инженер
    И да и нет одновременно.

    (обновлено, ибо внезапно прочитал и половину не понял - видимо писал на "потоке")
    RSA стоит использовать лишь для шифрования других ключей - ключей симметричных алгоритмов шифрования. AES, ГОСТ 28147-89, 3DES и другие. Почему? Во-первых, симметричные алгоритмы более устойчивы к взлому при большом известном закрытом тексте, тогда как ассиметричное шифрование потенциально имеет изъяны. В том смысле, что (почти) любое ассиметричное шифрование использует задачу NP-класса (точнее - NP-полную задачу): факторизация числа (RSA), декодирование полных (общих) линейных кодов (McEliece), вычисление дискретного логарифма на элептической кривой (ГОСТ Р 34.10-2012), или в конечном поле (Elgamal). Другое дело, что любая эта задача потенциально - решаемая. В случае с симметричным шифрованием действительно стоит лишь надеяться на чудо (в ГОСТе разрешено выбирать любые s-блоки, так что криптоаналитику ничего не остаётся, как молиться пролетариату в надежде на терморектальный криптоанализ). В случае же с ассиметричным шифром в дело вступают две вещи - высокая сложность реализации действительно стойкого алгоритма (ассиметричные шифры очень сложны и полны нюансов, не учитывая которые можно запросто порушить систему), низкая скорость работы (в силу того, что приходиться использовать очень абстрактные математические функции, сложно реализуемые аппаратно и таящие в себе множество низкоуровневых операций) при требовании к очень длинным ключам заставляют использовать небольшие ключи для того, чтобы не ждать вечность.

    Однако. Здесь имеется странный парадокс. Если данные очень важные и на их защиту можно убить несколько миллионов енотов, то надо использовать только ассиметричный шифр. Потому что, он потенциально даёт большую стойкость. Парадокс здесь в том, что если классы P и NP неравны, то мы получаем едва ли не идеальную и приемлемую по стоимости защиту, так как есть возможность сложной организационной защиты.
    (здесь было многое отправлено в топку)

    Окай, посмотрим на стандартную схему с Алисой, Бобом и Евой:
    Алиса -> c = E(m, Eb) -> -------- -> D(c, Db) -> Боб (
                                     |
                                     |
                                     v
                         Ева <- c, E, D, d

    здесь m - текст, который надо передать (сообщение)
    c - шифротекст
    E - функция шифрования (получения из сообщения шифротекста)
    D - функция дешифрования, иначе - обратная функция шифрования (получения из шифротекста - сообщения)
    Eb, Db - секретный и открытый ключи Боба (в литературе используется различное обозначение, здесь так)
    Собственно, Ева знает всё о функциях шифрования и дешифрования, имеет доступ к шифротексту и будем считать, что она получает и открытый ключ.

    Теперь, что нам это даёт? А это нам даёт возможность наплодить большое количество ключей и шифровать каждое сообщение отдельным ключём. Потенциально, но если есть $$$, то можно скупить половину серверов страны, если не планеты и радоваться жизни. Хотя ровно так же можно поступить и с симметричным шифрованием, и называется это одноразовым блокнотом, используют и различные режимы шифрования и всё равно выходит профитнее. Где же профит здесь?
    Во-первых, если нужно передавать по каналу, а не хранить, то можно генерировать ключи налету и после расшифровки их уничтожать. По сути, получиться что для того, чтобы получить сообщение длины l бобу потребуется передать и ключей в общей сумме длины l. Много? Да. Профитно? Очень - ибо мы реализуем
    ассиметричный одноразовый блокнот (упс), который, однако, нет никакого смысла использовать нет - слишком дорого. Да и не всегда возможно - порой обратный канал чрезвычайно узкий.
    Во-вторых, есть способ организовать защиту, основанную на иерархии пользователей. То есть майор Алиса написала отчёт, который ей надо отправить подполковнику Бобу. При этом читать этот отчёт должны иметь право все, кто равен или выше подполковника.
    В-третьих, как писалось выше, сложность взлома достаточно велика. И не только потому, что P != NP. Даже P довольно большое получается, поэтому и используют асимметричный шифр для передачи ключей симметричных ключей. Но и взлом получается очень не простым из-за тяжёлых математических абстракций. Обычно. Да, RSA можно "взломать" перебрав все возможные делители, но это долго из-за астрономического размера ключа. А способы обхода или упрощения опираются на такой зубодробительный матан, что попытка как-то это реализовать заставит использовать сами по себе очень тяжёлые операции. Так это при работе с банальными числами (и это показывает, насколько плохо развита теория чисел), а что если уйти на эллиптическую кривую - аналитическая геометрия развита может чуть лучше, но абстракции намного тяжелее для компьютеров. И даже использование графических карт не помогает, ведь есть ещё и макэлис. Я к тому, что O(2^32) для симметричного шифра и O(2^32) для асимметричного шифра не очень таки равны. Так же не равны, как не равны день и месяц.

    Но самое главное. Сегодня всё что угодно можно взломать. А то, что нельзя взломать - бесполезно (ибо либо уничтожено полностью, либо предоставляет такие же непосильные сложности для расшифровки и получателю). Во-первых, атака может быть не на сами шифры, а на организационные методы (которые, можно улучшить применением асимметричного шифра). Во-вторых, некоторые шифры таки имеют изъяны, просто возможно о них знают ограниченный круг лиц; привет масонам. И, наконец, криптоаналитик может быть просто ну очень удачлив.

    Поэтому шифрование надо использовать соразмерно цене риска. Чем выше риск - тем сильнее шифрование, но самое главное - сложнее и дисциплинированнее организационные меры. Согласитесь - бесполезно иметь централизованное хранилище сертификатов с одним сервером в бункере за 200 км под землей и круглосуточной охраной из армии маленькой страны, всего лишь одним портом торчащим во внешний мир с каналом около 200 бит в секунду и постоянным наблюдением за организационными методами (авторизация, доступ и подобной)... Имея пароль на суперюзер - qwerty, и держа на винчестере архив с котиками.
    Ответ написан
    Комментировать
  • Что почитать для прохождения вводного курсa C#?

    @smozhaykin
    Jeffrey Richter - CLR via C#
    Adam Nathan - WPF 4.5 Unleashed
    Ответ написан
    Комментировать
  • Какие есть крипт сервисы?

    EvilsInterrupt
    @EvilsInterrupt
    System programming, Reversing Engineering, C++
    getPolice()->SendMessage("Malware-developer detected");
    Ответ написан
    Комментировать
  • Зачем нужны таблицы подстановок в блочных алгоритмах шифрования?

    qmax
    @qmax
    программер
    В блочных шифрах они нужны для того же что и в подстановочных сетях - для добавления нелинейности.
    en.wikipedia.org/wiki/Confusion_and_diffusion
    Ответ написан
    Комментировать
  • Зачем нужны таблицы подстановок в блочных алгоритмах шифрования?

    Rsa97
    @Rsa97
    Для правильного вопроса надо знать половину ответа
    Это таблицы замен, читайте описание алгоритма.
    Ответ написан
    Комментировать
  • Как реализовать вывод текста в консоли Linux после команды?

    MintTea
    @MintTea
    Самый быстрый:
    alias easteregg="echo Hello world"
    Способ два:
    echo 'alias easteregg="echo Hello world"' >> ~/.bashrc

    Способ три:
    # Либо открываете этот файл в редакторе и пишете на любом известном вам яп
    echo -e '#!/bin/bash \n echo Hello world' > /usr/local/bin/easteregg 
    chmod +x /usr/local/bin/easteregg

    Первый будет работать в рамках сессии шелла, второй станет постоянным, но только для текущего пользователя, третий - будет доступен всем и всегда, но потребует прав рута.
    Пока хватит?:)
    Ответ написан
    Комментировать
  • Где можно посмотреть возможности SQLServer'a 2012?

    Много, максимальный размер базы 524 ПБ.
    msdn.microsoft.com/ru-ru/library/cc645993.aspx
    "сколько строк может быть в таблице, чтобы с ней можно было нормально работать", грубо говоря сколько угодно (пока размер базы позволяет), "нормально работать" зависит только от аппаратного обеспечения, дизайна базы и кода ПО.
    P.S. msdn.microsoft.com/ru-ru/library/ms143432.aspx
    Ответ написан
    Комментировать
  • Проблемы в конвертировании int в string и наоборот.И вызов метода. С#

    Что-то странное вы делаете. Мало того, что пытаетесь обратиться к переменной mark до ее инициализации, так еще и сравниваете строку с числом.
    Вас не смущает, что сообщение "Введена неверная оценка" появляется до ввода самой оценки?
    Ответ написан
    1 комментарий
  • Забытый пароль присылают на почту открытым текстом

    Carcharodon
    @Carcharodon
    люблю криптографию
    Если этот сайт еще и не шифрует трафик между собой и Вами, то я бы держался от таких сайтов подальше. В свете всего вышеописанного, даже если применяется шифрование на сервере базы с паролями, а Вам его шлют в открытом виде, ничто не мешает просто получить Ваш новый пароль по пути к Вам.
    Ответ написан
    Комментировать
  • Забытый пароль присылают на почту открытым текстом

    @Masterme
    А ещё нужно менять пароль после получения на почту. Ну, по-моему, об этом каждый школьник знает.
    Ответ написан
    Комментировать
  • Каково Ваше мнение при выборе ультрабука?

    Очень много что-то нареканий на ультрабуки Asus. Я бы не стал рисковать.
    Сам выбрал около года назад Macbook Air 13". Сейчас если бы встал выбор, то скорее всего снова взял его.
    Убунту 13.04 встает без проблем на него, всё работает и очень шустро, хотя энергосбережение надо донастраивать.
    Разрешение типа FHD на такой маленькой матрице создает лишь оверхед, реальной пользы мало, а под виндой так вообще ад с мелким шрифтом. Так что 1400х900 — вполне оптимальное. Единственный минус у Ээра TN+film, а не IPS. Но тем не менее откалиброванный и вполне сносный.
    Ответ написан
    8 комментариев
  • Оптимальные параметры для pbkdf2

    ntkt
    @ntkt
    Потомственный рыцарь клавиатуры и паяльника
    Оптимальные по какому критерию? :)
    Попробуйте сначала понять, от кого защищаемся и чем готовы пожертвовать.

    Если нужны конкретные рекомендации, то открываем, например, NIST SP800-132 «Recommendation for Password-Based Key Derivation», глава «A2. PBKDF»
    csrc.nist.gov/publications/nistpubs/800-132/nist-sp800-132.pdf
    Или те же самые вещи можно прочитать тут, например: www.ietf.org/rfc/rfc2898.txt

    image

    У Вас 32 байта соль? Тогда все хорошо. От длины соли скорость вычисления внутри системы не сильно зависит, а вот атакующему будет сильно хуже, чем если бы соль была, скажем, 32 бита.

    image

    Смотрим дальше: количество итераций в PBKDF, грубо говоря, линейно увеличивает сложность атаки.
    Поэтому делаем бенчмарк и ставим столько итераций, сколько влезет. 1000 рекомендовалось давно (2000 год), сейчас ставят больше — 10000 и т.д.
    Ответ написан
    2 комментария