kliss Oct 22 2011 at 10:58

Про догмы в криптографии

7 min

8.8K

Information Security*

Translation

+150

Comments 99

mark_ablov Oct 22 2011 at 11:12

> 12 символов будут сопротивляться в течение полутора лет (опять же, в среднем), это определенно мало для большинства приложений.

Мало? :)

kliss Oct 22 2011 at 11:13

Ну, как часто ты пароль от, например, почты меняешь? Я вот почти не меняю. Поставил и забыл. А на сторонних сайтах так и вообще никогда не меняю.

Harkonnen Oct 22 2011 at 18:05

Аналогично. Автор, кстати, не углядел более глобальную догму в криптографии — что пароли вообще нет смысла шифровать в БД. Если злоумышленник добрался до ДБ с паролями, до сами пароли ему уже нафиг не сдались. Всё равно что хранить ключ от кабинета в сейфе того же самого кабинета.

lorc Oct 22 2011 at 18:18

Ну как бы, получить доступ к табличке с логинами/паролями — это далеко не всегда то же самое, что получись доступ ко всей базе. Плюс, в больших системах база с паролями может быть физически отделена от БД с чем-то более критичным.
Например список хешей можно получить из бекапа AD, но это же не зачит, что мы получили доступ к самой AD, правда?

Harkonnen Oct 22 2011 at 21:17

С ситуацией бэкапа согласен

Harkonnen Oct 23 2011 at 10:56

Хотя… там же может оказаться и бэкап CD (content dababase), и опять всё по-новой :) Вы скажете, то бэкап CD должен быть зашифрован, но это можно сказать и про бэкап AD.

barmaley_exe Oct 22 2011 at 18:24

Ключ, потенциально подходящий к другим кабинетам.

Nashev Jul 15 2022 at 17:26

Некрокомент, но этой мысли в даном контексте явно не хватает:

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

grigoryvp Oct 22 2011 at 11:23

Полтора года = день для ботнета в 5к компьютеров. Ботнеты, увы, не только для DDOS используют :(. Так что дамп базы с чего-нибудь слабосекьюрного -> расшифровка пароля -> велика вероятность что этот же пароль используется для более важных ресурсов. Крайне мало людей у которых к каждому сервису свой криптостойкий пароль :(.

kliss Oct 22 2011 at 11:24

Я использую lastpass для этого. Он мне пароли символов по 20 генерит :-)

UFO just landed and posted this here

kliss Oct 22 2011 at 14:01

Ну, его то можно запомнить и нигде больше не использовать :-)

UFO just landed and posted this here

merqlove Oct 23 2011 at 01:43

Если он кому-то нужен, то охотится будут за ним лично. А здесь речь о сервисе. ))

UFO just landed and posted this here

merqlove Oct 23 2011 at 01:54

Ну только если так смотреть.
А что если человек пользует что-то вроде 1Password?

UFO just landed and posted this here

merqlove Oct 23 2011 at 03:18

Ага. +1

-2

merqlove Oct 23 2011 at 17:33

Если доступ не давать посторонним, то взлом тяжкая штука. Отследить, найти дырки, проникнуть. А если трояна не подкинуть? И вообще не винда у человека и человек не нуб)
Тут без доступа к компу в реале не обойтись. А если так, то не важно, как хранить пароли.

bazzilic Oct 23 2011 at 20:00

Еще забываете про терморектальный криптоанализ.

merqlove Oct 23 2011 at 21:44

Очень смешно.

max_mara Oct 22 2011 at 18:39

На самом деле, вместо того что-бы добавлять соль в конец пароля, ее можно просто размазать по самому паролю.

Например если в качестве уникализатора (?) для соли у нас выступает имя пользователя (username), а пароль (password) и есть соль (!@#$%^&*).

То размазываем сначала соль по username, например простым чередованием символов

username + salt = u!s@e#r$n%a^m&e*

А потом размазываем данное значение по паролю таким-же способом
pua!sss@w#eorr$dn%a^m&e*

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

А если еще пару раз взять md5(sha1(pua!sss@w#eorr$dn%a^m&e*) + md5(username) + sha(password) + username + !@#$%^&*).
Таким вот примерно способом можно решить проблему коротких паролей ровно до тех пор, пока атакующий не знает алгоритма обработки пароля с солью.

+ можно использовать еще медленные алгоритмы преобразования.

lomalkin Oct 23 2011 at 02:05

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

stas_agarkov Oct 23 2011 at 00:38

Зачем нужны пароли, если уже есть дамп базы со всей инфой?

lomalkin Oct 23 2011 at 02:07

Они могут подойти к почте или другим ресурсам — актуально для пользователей, использующих «универсальные пароли».
P.S. Пишу потому, что этот вопрос задается достаточно часто (и здесь тоже), а основная статья тоже описывает азы.

barmaley_exe Oct 22 2011 at 11:41

К слову, на хабре был топик, посвящённый криптостойкости 1000-кратного хеширования.

+22

ni4 Oct 22 2011 at 12:22

Почему бы просто не использовать SHA2? А PBKDF расчитан на извлечение ключа из пароля, не очень логично его использовать для хранения информации о пароле.
И насчет подбора пароля — соль нужна для предотвращения атаки по Rainbow Tables, которая намного быстрее тупого перебора, и требует не так много места.

kliss Oct 22 2011 at 12:23

По моему, Сальваторе говорит как раз про rainbow tables. Посмотри, сколько терабайт там занимает она. Или я что-то путаю? :-)

Vanav Oct 22 2011 at 16:34

И как поможет SHA2?

ni4 Oct 22 2011 at 18:04

Тем что он гораздо более стойкий, чем SHA1.

-3

hellman Oct 22 2011 at 18:38

При чём здесь стойкость самого хэша то ёмое, если в статье брутфорс/таблицы рассматривается?

Rusted Oct 24 2011 at 17:31

Ответ в старой статье на хабре про многократное хеширование, ссылка была указана выше, если вкратце — для SHA2 повышается верхний предел разрешенного количества итераций, ну и само-собой больший запас разрядности хэша при снижения стойкости.

maximw Oct 22 2011 at 12:22

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

kliss Oct 22 2011 at 12:25

Не понимаю. Действительно ли ты утверждаешь, что таблица рассчитанная для sha1(pwd) поможет взломать sha1(sha1(pwd))?

maximw Oct 22 2011 at 12:28

Да. Потому как результат работы одной хеш-функции — есть исходные данные для другой. «Радужные таблицы» позволяют «размотать» вложенность. На 1 уровень вложенности один дополнительный поиск в таблице.

kliss Oct 22 2011 at 12:31

Неправильно. В приведенном примере мы рассчитываем таблицу для пароля из 12 символов. А sha1 дает на выходе строку в 40 символов. Ты до второго пришествия такую таблицу не просчитаешь.

+15

kliss Oct 22 2011 at 12:49

Вот, я тут посчитал :-)

Sergios-MacBook-Pro:projects sergio$ irb
ruby-1.9.2-p290 :001 > combinations = 16**40
 => 1461501637330902918203684832716283019655932542976 
ruby-1.9.2-p290 :002 > size_on_disk = combinations * 40 # two hashes of 20 bytes (binary compact form)
 => 58460065493236116728147393308651320786237301719040 
ruby-1.9.2-p290 :003 > size_in_terabytes = size_on_disk / 1000 / 1000 / 1000 / 1000
 => 58460065493236116728147393308651320786

kliss Oct 22 2011 at 13:28

Что, разве неправильно посчитал? :-)

lorc Oct 22 2011 at 13:35

Неправильно :) В радужных таблицах для каждой «строки» храниться только первая редукция и последний хеш. Бегом на википедию, читать что такое радужные таблицы :)

kliss Oct 22 2011 at 13:36

Будь другом, посчитай правильно :-)

lorc Oct 22 2011 at 13:52

Лень :) Вот тебе выписка из википедии:

К примеру для паролей длиной не более 8 символов, состоящих из букв, цифр и специальных символов !@#$%^&*()-_+= захешированных алгоритмом MD5 могут быть сгенерированы таблицы со следующими параметрами:
длина цепочки 1400
количество цепочек 50 000 000
количество таблиц 800
При этом вероятность нахождения пароля с помощью данных таблиц составит 0.7542 (75.42 %), сами таблицы займут 596 Гб, генерация их на компьютере уровня Пентиум-3 1ГГц займёт 3 года а поиск 1 пароля по готовым таблицам не более 22 минут.

Да, пераметры другие. Но на порядок результата они не повлияют.
Например, если пароль будет всё же 12, а не 8 символов. То таблицы вырастут всего до 596*12/8 = 894 Гб (как я говорил, таблицы хранят только концы цепочек). Правда при этом упадет вероятность нахождения пароля. Но допустим, удвоив количество таблиц мы вернем её обратно. Тогда таблицы будут занимать аж целых полтора терабайта. Но никак не столько, сколько насчитал ты.

kliss Oct 22 2011 at 14:03

А зато у меня поиск мгновенный и стопроцентный. Для пароли из 40 символов :)

-2

TheShock Oct 22 2011 at 14:54

Неправильно. В приведенном примере мы рассчитываем таблицу для пароля из 12 символов. А sha1 дает на выходе строку в 40 символов. Ты до второго пришествия такую таблицу не просчитаешь.

Автор, видимо, имеет ввиду, что при полном переборе мы можем использовать rainbowTables, как-то так:

variantsGenerator = new VariantsGenerator;

while (variant = variantsGenerator.next()) {
   // result = sha1(sha1( variant ));
   result = sha1(getHashFromRainbowTable( variant ));
}

как-то так.

-1

lorc Oct 22 2011 at 13:30

Не так. В радужных таблицах после операции хеширования идет операция редукции — превращение хеша в новый «пароль», который уже пойдет на вход следующей итерации.
Потому что нет удобного способа использовать строку из 320 бит в качестве пароля напрямую.

lorc Oct 22 2011 at 13:33

Упс, не 320, а 160 бит. Попутал малость.

hellohaos Oct 22 2011 at 12:35

SHA2?

-3

kliss Oct 22 2011 at 12:39

А если нету его для нашей системы. А sha1 есть даже не пылесосах. И секьюрность не меньше, если с умом подойти :-)

lomalkin Oct 23 2011 at 02:12

~~Блин, SHA4! Суть то не в этом!~~ Извините.

philpirj Oct 22 2011 at 13:21

Вы случайно не следили за соревнованием на право называться SHA-3? Очень там были забавные мотивации на отсеивание кандидатов. Так что «криптограф-любитель» вряд ли сможет сделать что-либо хорошее.
Ко всему прочему, в статье, приведённой несколькими комментариями выше, автор топика соглашается в спорности повышения криптостойкости при применении этого подхода.
BCrypt, к слову, использует несколько итераций, что и даёт стойкость, и что снижает скорость (в том числе составления таблиц). Не вижу причин не использовать его, если отбросить нежелание добавлять новые зависимости.

kliss Oct 22 2011 at 13:25

Сальваторе предлагает много раз прогонять sha1 не для повышения криптостойкости. А для увеличения стоимости генерации хэша. Ну и заодно для защиты от таблиц. :-)

bcrypt — хороший алгоритм. Но можно же и без него обойтись. К слову, redis компиляется вообще без зависимостей. Маленький компактный самодостаточный код. Так что мужик знает о чем говорит :-)

mas Oct 22 2011 at 13:37

Всё хорошо, это эта фраза просто убила: «Заметим, что в английском языке не так уж и много слов, поэтому эта атака может быть проведена очень легко и быстро.» И это про язык, в котором больше всего слов!

kliss Oct 22 2011 at 13:38

Да брось, откуда данные то? :-)

kliss Oct 22 2011 at 13:39

В любом языке слов ничтожное количество, по сравнению с количеством комбинаций для пароля из хотя бы 8 символов :-)

Oblitus Oct 22 2011 at 13:45

Слова в английском образуются склейкой нескольких других слов. Количество уникальных корней не так уж велико. Если мы возьмем слово airplane, то это будет 2 словарных слова air и plane, то есть по стойкости это пароль из 2 знаков.

vaniaPooh Oct 22 2011 at 16:21

Китайский — вот жесть! 50 тыс. иероглифов.

kliss Oct 23 2011 at 09:34

При этом они читаются все одинаково :-))

История про десять каменных львов

Исполняемая живым настоящим китайцем

jcmvbkbc Oct 23 2011 at 14:35

В словаре Ожегова (русский язык) 57000 слов.

plishas2 Nov 12 2011 at 02:29

словарный запас обычного человека ограничен

Greendq Oct 22 2011 at 13:42

А какой-такой GPU может генерить МИЛЛИАРД хешей в секунду??? По-моему, слишком большое преувеличение.

kliss Oct 22 2011 at 13:44

На что только современные видеокарты не способны. Говорят, они даже деньги добывают :-))

Greendq Oct 22 2011 at 14:03

Про майнинг знаю, но мне что-то слабо верится, что можно именно сгенерить и проверить миллиард хешей в секунду. Хотя, на частоте 1 Ггц 300 процессоров может и могут сгенерить миллиард хешей. Вот только где они его держать будут? :)

-1

aleks_raiden Oct 22 2011 at 16:16

специализированные криптопроцессоры, стоящие копейки, вполне могут, при этом создать их при современных средствах програмирования ПЛИС, может любой, прослушавший курс микроелектроники — infobez.com/article.asp?ob_no=1203 (пусть старая но интересная статья)

Sardar Oct 22 2011 at 14:03

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

А вот BCrypt с солью это пока сильно, т.к. BCrypt ограничивает скорость перебора (медленный по дизайну), а случайная соль борется со слабыми паролями.

Кстати, любые правила на пароль, к примеру «минимум одна цифра, буквы в разных регистрах и обязательная пунктуация» делают перебор проще, т.к. я могу отсеять пароли не подходящие под условие. Это реальный пример, когда любитель пытается просто логикой «повысить безопасность» вверенного в его руки объекта. К сожалению такие правила на пароль встречаются повсеместно, что конечно печально.

Не в тему, но все же: пароли зло. Тут ранее пробегала статья про фразы в 4 и более слов. Фразу гораздо сложней подобрать (при этом весь перебор по словарю ;)), за разъяснениями (энтропия) туда. Это пример, когда не любитель правильно подходит к анализу проблемы.

kliss Oct 22 2011 at 14:06

да-да, и комикс на XKCD тоже пробегал где-то тут :-)

bolk Oct 22 2011 at 18:24

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

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

Мне только кажется, что сделать надо sha1(sha1(sha1(sha1…)))+salt), например.

frol Oct 22 2011 at 21:15

sha1(sha1(sha1(sha1…)))+salt)

Тогда достаточно сгенерировать таблицу со значениями sha1(sha1(sha1…))) и дальше решать начальную задачу sha(pwd+salt), где pwd — sha1(sha1(sha1…)))
Возможно тогда делать sha1(sha1(sha1(sha1…sha1(pwd+salt))))+salt), но мне не нравится идея изобреения велосипеда без оценки его эффективности.

bolk Oct 22 2011 at 22:14

Для этого надо получить доступ к коду и знать на каком шаге добавляется соль.

deniszh Oct 23 2011 at 00:40

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

philpirj Oct 24 2011 at 03:21

Узнать алгоритм очень просто — атакующему достаточно знать всего один пароль в системе, для этого обычно достаточно зарегистрироваться либо подобрать всего один пароль брутфорсом.

kliss Oct 24 2011 at 13:08

Сомнительное утверждение.

Вот подобрал ты пароль брутфорсом. Какие выводы ты можешь сделать об алгоритме?

philpirj Oct 27 2011 at 23:13

Алгоритм — чёрный ящик, но я знаю всё, что у него на входе и на выходе (есть пароль и есть дамп базы), и обладаю достаточным количеством ресурсов, чтобы воссоздать сходный ящик.
Во-первых, пробегусь по этому топику, и посмотрю все варианты, с количеством итераций хеширования, алгоритмами хэширования, с добавлениями солей туда и сюда, перемешиваниями солей, перестановкой символов, xor и прочего. Вариантов сравнимо с тем, что пришлось подбирать брутфорсом.

Syra Oct 22 2011 at 18:31

Коллизии? Ой ли? И сколько же надо записей хранить, что бы покрыть все 160 бит SHA-1? Может таки не зря придумали словари и прочее?

lomalkin Oct 23 2011 at 02:22

> У атакующего нет цели найти исходный пароль, ему нужно найти строку, которая даст такой же хеш.

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

tzlom Oct 22 2011 at 16:38

Я использую sha1(salt+sha1(password)), причём в соль пихаю и непечатные символы, чтобы растянуть диапазон значений

gnomeby Oct 22 2011 at 17:40

Ответ не верный. Дело в том, что мне достаточно взять вычисленные хеши популярных паролей (а это sha1(password)) и довести их до нужного состояния зная вашу хеш функцию.

Тогда как для sha1(salt+password) у меня нет готовой таблицы. Ну и конечно соль должна быть индивидуальной, иначе толку никакого.

tzlom Oct 22 2011 at 17:42

Хм, а и в правду, спасибо

hellman Oct 22 2011 at 18:47

А какая разница, в обоих случаях надо сделать 1 sha1 по всей таблице

gnomeby Oct 22 2011 at 18:55

Да, вы правы. Таблица с вычисленными хешами хранит и исходный пароль. В общем нужна индивидуальная соль. Ну и конечно sha1(password) в исходной формуле вообще никак не добавляет криптостойкости.

max7 Oct 22 2011 at 16:47

HMAC

lorc Oct 22 2011 at 17:38

Эм? При чем тут алгоритм подписи?

vibornoff Oct 22 2011 at 19:10

Ну, как-бы это один из возможных вариантов соления сообщения ключом: HMAC(m,k) = H( k | H( k | m ))

vibornoff Oct 22 2011 at 21:33

Только сообщением m здесь будет соль, а ключом k — пароль, ибо H( k | m ) можно частичным применением хеш-функции превратить в Hk( m )

gnomeby Oct 22 2011 at 17:36

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

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

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

kliss Oct 23 2011 at 04:49

> вас можно задосить на форме проверки пароля

Ну скажем, он не 1ккк хэшей в секунду будет просчитывать, а «всего лишь» 100к. Фиг ты заддосишь :-)

Ибо в любой момент в кластер аутентификации можно машин добавить.

alxrt Oct 23 2011 at 14:28

>>Как только вы начинаете использовать медленную хеш-функцию у вас также начинаются проблемы, так как вас можно задосить на форме проверки пароля.
Защитить форму логина капчей и — вуаля.

>>Зачем мне сидеть вычислять ваши хеши, когда проще натравить ботнет на форму ввода пароля и подобрать пароль к нескольким юзерам.
А ботнет обладает средствами OCR и может дать нормальную скорость перебора паролей?
Кроме того, обычно базы хэшей утягивают, для дальнейшей продажи. Если нет целенаправленной атаки на конкретный ресурс/человека, то ваши несколько подобранных логинов/паролей никому нужны не будут.

-1

Sap_ru Oct 22 2011 at 18:02

Из всего прочитанного уяснил, что оптимальным будет SHA1(global_salt+SHA1(user_salt+pwd)), который для пущей надёжности можно ещё несколько раз SHA1 сделать.

gnomeby Oct 22 2011 at 18:20

Наверное только в том случае, если для злоумышленника добыть одновременно дамп, алгоритм и глобальную соль — не простая задача.

И сразу возникает вопрос, где хранить глобальную соль, если не в коде и не в базе?

lomalkin Oct 23 2011 at 02:35

Если случай не параноидальный — то хоть в конфиге, лучше в отдельном и неприметном (его могут забыть слить, если даже будут брать код). В других случаях можно вынести всю криптологику в другое место (например другой физический сервер с только локальным входом и закрытыми лишними портами/отключенными лишними службами), сделав некое подобие внутреннего (т.е. не доступного извне) крипто-API, обслуживающего запросы основной системы, и там же хранить свою соль. В любом случае зависит от задачи.
Для большинства систем подойдет формула из этого комментария.

Sap_ru Oct 24 2011 at 16:30

Нет, это для того, чтобы радужные таблицы никакого рода нельзя было использовать (ни готовые, ни с вои посчитать) — только полный прямой перебор. Сейчас действительно часто встречаются описания взломов по таблицам. А в этой статье всё весьма доходчиво систематизировано.

lightman Oct 22 2011 at 18:04

Чтобы не хранить пароли в БД в открытом виде, обычно их хэшируют.

Если бы… Если говорить о сайтах, то добрая их треть имеет ограничения 8-12-20-30 символов на пароль. Что говорит либо о дурости разработчиков, сующих бездумные ограничения где ни попадя, либо тоже о дурости, но заключающейся в хранении паролей в открытом виде в БД.

foff4ik Oct 22 2011 at 18:18

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

alpha6 Oct 22 2011 at 18:51

Это из серии организуй DDOS на свой сервер сам?
Это не говоря уже о том, что авторизация пользователя начнет занимать достаточно существенное время при n даже не доходящих до 10

roman_pro Oct 22 2011 at 20:06

Существует схема, которая не боится кражи базы паролей с сервера — Lamport hash chain. Другой вопрос, что мне неизвестны реальные продукты, в которых бы она применялась. Возможно, отпугивает необходимость вычислений на клиентской стороне. Или солёные хэши + многократное хэширование просто привычнее и проще для понимания.

david_mz Oct 23 2011 at 00:37

Вот ещё интересная схема habrahabr.ru/blogs/web_security/121021/, хотя считать гораздо больше. Лэмпорт привлекает своей крайней простотой, хотя от MiM и от подбора не защищает.

Vanav Oct 22 2011 at 21:04

Не нужно изобретать собственные алгоритмы, нет, правда.

Используйте:

— bcrypt,
— PBKDF2 с HMAC-SHA256 (рекомендовано NIST в Special Publication SP 800-132),
— scrypt.

Рекомендованная длина хеша.

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

Rigidus Oct 24 2011 at 00:36

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

Vanav Oct 24 2011 at 00:53

За аргументами ходить далеко не надо. Очень часто, когда программист говорит, что он лучше знает, и реализовывает криптографию самостоятельно, находятся ошибки. Даже у экспертов.

Например, автор scrypt недавно ошибся в реализации AES-CTR и поставил под серьёзную угрозу безопасность чужих данных.

Andorfin Oct 22 2011 at 23:53

Благодарю за познавательный материал!

kliss Oct 23 2011 at 05:47

Мы старались :-)

Show the best of all time