Ад — это чересчур уверенные в себе разработчики, пишущие собственную криптографию

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

Конечно, код пишут люди. Но это специальные люди, у которых есть справка от врача.

Любая мысль сведенная к короткому заголовку, лозунгу или правилу - искажается.
Я как раз хотел возразить - "пишите свою криптографию! пишите свою аутентификацию!" - потому что именно это - единственный способ набить все шишки и научиться. Но надо понимать, что шишки - будут.

Безопасность и особенно криптография - особые области. Во всех остальных, если ты плохо сделал - ты это видишь сам, или быстро найдется пользователь, у которого не работает. Студент просто не сделает сложную задачу в сложной области - все это увидят. А в безопасности - все всегда работает. (Чем больше механизмов безопасности ты отключишь или не включишь - тем даже лучше будет работать!). Давно известные правила из жизни теряют смысл, как только доходит до безопасности, вплоть до того что PRNG инициализировать из таймера нельзя. То, чему мы научились в 14 лет и всю жизнь делали, оказывается, нельзя делать!

Потому что суббота -- это шаббат.

Ой-вэй во имя Тора, песня-то не о библиотеках которые используют пациенты.

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

Всё это можно было-бы изложить коротко и понятно, не создавая иллюзии посягательства на священное право людей всяко по вертеть данными перед шифрованием, тут вестимо, на богов надейся, а сам не лошай.

есть интересное чтиво от одного из авторов своей криптобиблиотеки https://loup-vaillant.fr/articles/rolling-your-own-crypto https://loup-vaillant.fr/articles/implemented-my-own-crypto
спойлер - хотя он разбирается в математике и был уверен что багов нет т.к. реализация занимает меньше тысячи строк, вдумчивые исследователи несколько уязвимостей таки отыскали. Зато теперь она выглядит уж точно понадежнее OpenSSL.

Так в статье и говорится, что практиковаться и изучать криптографию можно и нужно, не стоит только свои изобретения пускать в продакшен

Если бы все сами работали с криптографией, то все имели бы представление о том, как верифицировать собственный протокол или какие типичные ошибки существуют.

К сожалению нет. Есть фундаментальное различие между ошибками функциональности и ошибками безопасности: первые могут быть обнаружены при обычном использовании, и обычно достаточно легко предъявить тест который демонстрирует проблему вне разумных сомнений. Вторые никак не сказываются на нормальной работе ПО (за совсем клиническими исключениями), и даже демонстрирующий уязвимость proof-of-concept вполне можно не понять или убедить себя что проблема несущественна.

Более педантичное правило звучало бы так: реализуйте безопасность всерьёз и с серьёзными затратами или не реализуйте её вовсе, потому что полумеры практически дают результат хуже чем если бы не реализовывали ничего - оно так же небезопасно, но теперь у вас есть ложные иллюзии.

а можно только обратиться к магу-криптографу.

Настораживает то, сколько софта завязано на алгоритмы Daniel J. Bernstein...

Да ладно? Нет вреднее предрассудка? А скажем "при любой простуде обязательно принимайте антибиотики" не страшнее будет?)

Криптография в среднем на порядок сложнее, чем работа с файловой системой или сетевой библиотекой. Ради интереса, попробуйте указать, не подглядывая в интернете решение, в чём заключается уязвимость в этой программе:

from Crypto.Cipher import AES
from Crypto.Util.Padding import pad,unpad
import os

def encrypt(key, plaintext):
    cipher = AES.new(key, AES.MODE_CTR, nonce=IV)
    return cipher.encrypt(pad(plaintext, 16))

def decrypt(key, ciphertext):
    cipher = AES.new(key, AES.MODE_CTR, nonce=IV)
    return unpad(cipher.decrypt(ciphertext), 16)

def menu():
    print("1. Encrypt Message")
    print("2. Get Flag")
    print("3. Exit")
    choice = int(input(">> "))
    return choice

key = os.urandom(16)
IV = os.urandom(8)

while True:
    choice = menu()
    if choice == 1:
        plaintext = input("Message: ")
        print("Encrypted Message (hex):", encrypt(key, plaintext.encode()).hex())
    elif choice == 2:
        print("Encrypted Message (hex):", encrypt(key, b"COMPFEST16{RETACDED}").hex())
     
    elif choice == 3:
        break

Если бы все сами работали с криптографией, то все имели бы представление о том, как верифицировать собственный протокол или какие типичные ошибки существуют.

Ага. А если бы все сами работали с выделением/освобождением памяти , то все имели бы представление, о том, как верифицировать свой код и избегать NPE, Use-after-Free и тому подобных проблем

Если вам хочется пример некриптографических граблей, то "никогда не обрабатывайте сами юникод". Желающие опробовать прочность лба могут написать что-нибудь простенькое, типа самостоятельного подсчёта количества символов в UTF-8 строке.

Самописную реализацию хакнуть проще: если это опенсорс, если это легко дизассемблировать (скорее да чем нет), если автор этого доступен для терморектального криптоанализа. Лушче всё же взять широко известную библиотеку

Зависит от сложности (качества) самодельного решения. Самодельный S-box с уникальными случайными перестановками (A->B, B->G, C->Z, ...) может казаться разработчику охренеть каким простым, эффективным и надежным. Но его взлом - уровень лабораторной работы.
Другие, более сложные методы - тоже имеют причины (методы атаки), по которым от них отказались.
Беда самописной криптографии не в уполовиненном Дохуа, а в том, что разработчик сам не компетентен и не может квалифицированно оценить его "криптостойкость". Ему-то кажется что Дохуа или даже тройной Дохуа (но как пессимист и скептик, он допускает, что всего лишь 1% от Дохуа). А по факту это - 20 минут на взлом.

Или (но тут я повторю мысль из статьи) - алгоритм не так уж и плох, но разраб ошибся в какой-то неожиданной мелочи (например, инициализировал свой PRNG из time() как в школе учили). И вот пароль юзера Wesha из 27 символов в котором есть цифры-буквы-эмодзи-иероглифы и даже соло на саксофоне - он имеет не хреналлион комбинаций и даже не пол хреналлиона, а всего лишь 86400, потому что все знают, что он с нами с 18 сентября 2015.

Если в вашем гипотетическом случае предполагается, что неизвестностью самописной реализации улучшается ее защищенность, то это нарушает принцип Керкгоффса.

Не факт что ломать будет агентство из трех букв. Хакер-самоучка наоборот не осилит сломать общеизвестную библиотеку, а вот самописный код - заинтересуется и расколет.

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

«От меня не требуется создавать принципиально невзламываемую систему. Мне достаточно создать систему, которую не сможет взломать тот, кого назначат расследовать моё дело.»

(Джим Санборн смотрит на этих ваших профессионалов, ехидно посмеиваясь.)

Справедливости ради, необходимость и обязательность использования государственных стандартов регулиируется законодательством о стандартизации. В России, например, за некоторыми исключениями использовать ГОСТы не обязательно. Например, ядерный реактор надо обязательно строить по профильным ГОСТам, а вот писать пояснительную записку к вузовской выпускной квалификационной работе, в принципе, по ГОСТу не обязательно, и вузу никто не запретит утвердить какие-то другие требования к её оформлению.

Применение гостов дело добровольное. Ну вот если у вас есть госзаказчик который требует делать по ГОСТу, то делайте. Обязательными для всех являются технические регламенты, их дума принимает, это законы. Регламента на шифрование нет.

Хотя погодите, регламенты кажется распространяются только на продукцию обращаюся на территории ЕАЭС. Для себя или забесплатно можно что угодно.

Проблема не в том, что разработчик не знает какому ключу можно доверять, а какому нет. Проблема в том, что разработчик не задумался над вопросом: "Откуда я знаю, что ключу можно доверять?" И не записал ответ в документацию. Потому что 100%-ой гарантии не бывает, а ограничения системы должны быть задокументированы

обычно, никто нахрен не полезет ломать вашу криптосистему

если она никому не нужна

В далёких 2000-х кейгены были к каждой более-менее полезной программе. (по факту, это реверс -инжиниринг самодельных криптосистем)

никто нахрен не полезет ломать вашу криптосистему, ибо видно что там заморочено, и мало ли как оно там...время ток терять.....

Security through obscurity не работает. Если ваша кустарная "криптосистема" для кого-то представляет интерес и имеет уязвимости, её сломают, может быть не быстрее чем вы моргнёте глазом, но весьма быстро.

автор коряво сформулировал мысли, но тут есть еще и другой лес:

1) если вы делаете МВП или демку, или петпроект, у которого будет 10 пользователей и недорогие данные внутри - то используйте любую криптографию. Можно даже попробовать свою.

Потому что вы - "неуловимый джо".

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

Потому что вас начнут пытаться взломатью Просто потому что скучно, а у вас АПИ лежит в открытом доступе с "админ/админ" или назначает айдишки по порядку.

3) если у вас больше 100к пользователей (или данные 100к+ денег) - то у вас должен быть отдел безопасников и "правильная криптография".

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

---

и если использовать софт из п1 в ситуации п3 ("о чём мечтают стартаперы") - это немного опрометчиво :)