Клиент наскоро ми изпрати спецификация за крипто, която включва известно, как да кажа, неоптимално използване на крипто примитиви. Те са потребители на .Net, така че реших да потърся хубава справка за крипто msdn, за да ги оправя. Вместо това намерих вероятния виновник зад тяхното объркване.

Въпросната статия е следната: Как да криптирате и декриптирате файл с помощта на Visual C# (оттогава е свалена, победа!). Ако сте в настроение за малко удар по челото, препоръчвам да го прочетете. Ето някои от смешните-ако-не-бяха-тъжни съвети, които намерих:

Използване на DES за криптиране

И не, нямам предвид 3DES, просто обикновен DES. Този, който може да бъде грубо форсиран за едноцифрен брой дни от модерен компютър. Имайте предвид, че предназначената аудитория за тази статия не са криптографи, които знаят по-добре, а програмисти, които търсят урок. Добре е, че смяната на Цезар не е налична в библиотеката им или вероятно щеше да попадне в този урок.

Предложение за използване на ключа за криптиране като IV

Това беше първата от поредица данни, които предполагат, че авторът няма представа какво е IV или как трябва да се използва. Това предложение всъщност се появява повече от веднъж в статията, ето обидните пасажи:

Можете да поискате от потребителя парола. След това използвайте паролата като ключ и IV.

Обърнете внимание, че не се споменава използването на функция за извличане на ключ, а само предложение за директно използване на паролата.

DES.Key = ASCIIEncoding.ASCII.GetBytes(sKey);
DES.IV = ASCIIEncoding.ASCII.GetBytes(sKey);

Този пасаж вероятно е още по-лош, тъй като това е действителен код, който нищо неподозиращите читатели биха могли потенциално да копират и поставят.

Съвет срещу използването на ключа на библиотеката и функционалността за IV поколение

Използването на една парола като ключ и IV е доста ужасно предложение, но за щастие библиотеката има метод за генериране на ключ и IV за вас, така че да не го объркате. За съжаление авторът изрично съветва да не го правите поради безсмислена причина.

Ако не предоставите ключ, доставчикът произволно генерира такъв. Това успешно шифрова файла, но няма начин да го дешифрирате. Обърнете внимание, че трябва да предоставите и инициализиращия вектор (IV). Тази стойност се използва като част от криптирането. Подобно на ключа, IV се генерира на случаен принцип, ако не предоставите стойността. Тъй като стойностите трябва да са еднакви за криптиране и декриптиране, не трябва да разрешавате произволно генериране на тези стойности.

Акцентът е мой. Така че очевидно, ако използвате функцията за ключа и IV поколение на библиотеката, няма начин да извършите дешифриране. Трябва да се чудя защо авторът смята, че авторите на библиотеката са избрали да включат тази необратима функционалност за унищожаване на данни. Авторът дори прави крачка напред и прави общото изявление, че ключовете и IV изобщо не трябва да се генерират на случаен принцип.

IV не е включен в шифрования текст

Този е тънък, защото трябва или наистина да следвате логиката, или да опитате да изпълните кода сами. Това вероятно обяснява защо авторът третира IV като друг таен ключ.

Препратките също грешат IV

Може да изглежда, че наистина разтърсвам този човек за неразбирането му какво е IV или как се използва; в края на краищата това не е статия за режими на блоково шифиране или криптографски ключове и дори препраща към „препратка специално за криптографски ключове“. Това със сигурност изяснява всичко, нали? нали?? Това е буквално второто изречение в тази статия:

Симетричните алгоритми изискват създаването на ключ и вектор за инициализация (IV), които трябва да се пазят в тайна от всеки, който не трябва да дешифрира вашите данни

Но поне тази статия използва троен DES в техния пример.

Продължение: „Скъпи Microsoft, така шифровате файл“