Комментарии 20
Беда…
Первое, чему учат любые учебники по криптографии и информационной безопасности, и первое же, что говорят на любых курсах — Не используйте не проверенных временем и не перепроверенных сотню раз алгоритмов. Второе — не пытайтесь самостоятельно реализовать даже существующие алгоритмы, даже если вам кажется, что вы прекрасно их понимаете. Никакой самодеятельности, просто следуйте стандартам.
Но в качестве зарядки для мозгов статья хорошая. Главное, что заголовок выбран правильно!
Но в качестве зарядки для мозгов статья хорошая. Главное, что заголовок выбран правильно!
На ноль делить нельзя, да.
Есть 2 причины для этого совета: 1) человек, плохо разбирающийся в криптографии, накосячит очень сильно. 2) нестандартный алгоритм будет сложно вскрыть «кому надо».
Есть 2 причины для этого совета: 1) человек, плохо разбирающийся в криптографии, накосячит очень сильно. 2) нестандартный алгоритм будет сложно вскрыть «кому надо».
Смутно представляю себе, как «кому надо» будет вскрывать AES. Так что дело именно в первой причине.
Качественная реализация криптографических алгоритмов, это не только программная реализация самого алгоритма, но и принципы работы с памятью, с ключами, с открытым и зашифрованным текстом, с генерацией случайных чисел. И в этих частях накосячить даже проще, чем в самом алгоритме.
А вот для защиты от «кого надо» лучше использовать открытые библиотеки реализующие стандартные алгоритмы. Там можно самому убедиться в том, что нет «пасхальных яиц». Но, опять же, где гарантия, что opensource разработчик не коммитнул в последнюю версию используемого вами компонента какую-нибудь бяку?
Качественная реализация криптографических алгоритмов, это не только программная реализация самого алгоритма, но и принципы работы с памятью, с ключами, с открытым и зашифрованным текстом, с генерацией случайных чисел. И в этих частях накосячить даже проще, чем в самом алгоритме.
А вот для защиты от «кого надо» лучше использовать открытые библиотеки реализующие стандартные алгоритмы. Там можно самому убедиться в том, что нет «пасхальных яиц». Но, опять же, где гарантия, что opensource разработчик не коммитнул в последнюю версию используемого вами компонента какую-нибудь бяку?
Вот именно, тем более чтобы хотя бы понять как работает некий код и всё ли он делает правильно, надо хорошо понимать в криптографии. У меня уже давно сложилось ощущение, что Open Source показал, насколько мы близки к сингулярности в отдельно взятой области знания.
Вы путаете программные закладки в библиотеке и математические закладки в алгоритме. Скажем, разработало АНБ некий нестойкий шифр с глубоко запрятанной уязвимостью. Такое вы не в жизнь не найдете (если, конечно, вы программист, а не криптоаналитик).
Вы предполагаете, что реально разработать новый математический алгоритм, доказать его эффективность, повсеместно внедрить и при это еще и оставить для себя «заднюю дверь»? Имхо, это уже что-то из области теории заговора, причем граничащего с паранойей.
Я имел в виду именно программные закладки. Например, могут генерироваться не 128-ми битные ключи, а более короткие, а по ним уже вычисляться ключи для AES. В этом случае для атаки «в лоб» зная алгоритм генерации первичных коротких ключей не придется перебирать все варианты.
Но это все в порядке бреда, т.к. алгоритм шифрования — это одно, а генерация ключей — другое. Сделать «программную закладку» в реализацию самого алгоритма шифрования невозможно — сообщения просто не будут корректно расшифровываться. Т.е. фактически это уже будет другой алгоритм.
Я имел в виду именно программные закладки. Например, могут генерироваться не 128-ми битные ключи, а более короткие, а по ним уже вычисляться ключи для AES. В этом случае для атаки «в лоб» зная алгоритм генерации первичных коротких ключей не придется перебирать все варианты.
Но это все в порядке бреда, т.к. алгоритм шифрования — это одно, а генерация ключей — другое. Сделать «программную закладку» в реализацию самого алгоритма шифрования невозможно — сообщения просто не будут корректно расшифровываться. Т.е. фактически это уже будет другой алгоритм.
Интересно, кто учебники по криптографии писал? NSA? что-бы не выдумывали ничего нового, а то не поломать?
Шучу конечно, но кошки скебут на душе.
Шучу конечно, но кошки скебут на душе.
Не знаю как на счет NSA, но точно знаю про одну страну в Средней Азии, где все банки, госслужбы и финансовые организации должны пользоваться одним определенным криптопровайдером, который разработан одной не слишком большой местной компанией.
Т.е. стандартный криптопровайдер, входящий в состав Windows и разработанный спецами Microsoft (или под их контролем) — это не безопасно. Стандартные провайдеры *nix систем — тоже. А вот что-то, написанное хрен пойми кем, под чутким контролем местного аналога ФСБ — это самое оно.
Наводит на размышления. Хотя, возможно, это просто схема откатов и распилов.
Т.е. стандартный криптопровайдер, входящий в состав Windows и разработанный спецами Microsoft (или под их контролем) — это не безопасно. Стандартные провайдеры *nix систем — тоже. А вот что-то, написанное хрен пойми кем, под чутким контролем местного аналога ФСБ — это самое оно.
Наводит на размышления. Хотя, возможно, это просто схема откатов и распилов.
Если у вас пакетный режим, можно же сделать сервис который будет отвечать за передачу, висеть 24x7, и не будет выгружать проинициализированное состояние для шифрования.
Звучит всё разумно. Выложите исходный код где-нибудь на гитхабе с названием HC-128-Scratch, сделайте описание на английском и люди потянутся, мне кажется.
Довольно часто использовал модифицированные векторы инициализации в MD5 без последствий для софта, зато с последствиями для тех, кто долго не мог понять почему у них MD5 не совпадает с моим %)
Спасибо за статью.
Спасибо за статью.
Тег «не повторяйте это дома» -> «не делайте это в продакшене».
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Никогда не повторяйте этого дома: модификация алгоритма шифрования HC-128