Изпечатай

[victim70]

Някой да има примерни C++ кодове, или линк към такива, за криптиране/декриптиране с библиотеката crypto++. Налага ми се да я ползвам точно нея и не съм сигурен, че това дето го правя е правилно. Документацията и е отвратителна.

[gat3way]

Нещата са общи навсякъде. Не съм ползвал crypto++, предимно openssl и botan, също така що се отнася до DES - сам съм си реализирал алгоритъма, включително в bitslice вид.

В общи линии има няколко неща, които могат да се осерат. Първото и най-важното е режима на криптиране - CBC, ECB, XTR и т.н. Това е най-важното нещо, не знам как се прави там, но предполагам имаш някакви тестови вектори, които трябва да сравняваш и не ти излизат.

Почти всички режими на опериране на блоковите шифри изискват начален вектор (IV), единствено ECB режима не го изисква,щото всеки блок е сам за себе си. Внимавай какъв ти е IV-а, иначе може и да не си нагодиш test vector-a.

Другото е padding-a, има няколко варианта, но най-често се ползва PKCS5. При него като не достигаш нещо кратно на block size-a, падваш съобщението с колкото трябва байтове равни на разликата между големината на съобщението и големината на съобщението ти до следващия блок. примерно съобщението ти е AAA а блока ти е 32 бита, паднатото съобщение е AAA\01. Обаче някои малоумни библиотеки pad-ват с нулеви байтове примерно и това чупи последния блок ако не е кратен на block size-a.

Всичко останало е стандартно и се ползваат стандартни примитиви, които дават очаквани резултати. Та в крайна сметка важните неща са да даваш правилния IV, правилния режим на работа ако има избор - правилния padding mode. Друго трудно може да се осере.

A, при 3DES може би още едно нещо може да се осере, има няколко варианта там, но май си имаше стандарт. Имаше някакви дивотии дали да се ползват 3 различни ключа или 2 различни ключа и криптиране-декриптиране-криптиране, като meet in the middle атаките свеждат сложността на двете до една и съща стойност. Има си стандарт за това, ма не ги помня тези неща вече.

П.П препоръчвам ти на първо време да си поиграеш с DES в ECB режим, най-лесно ще ти излезнат test vector-ите. Block size-a е най-малък (64 бита) и ключа тоже (64 бита, но всеки 8-ми бит няма значение щото е parity и почти винаги се ignore-ва - openssl примерно въобще не му пука какво има там - така че все едно блока ти е 64 бита, а ключа - 56-битов).

[victim70]

Нещата са общи навсякъде. Не съм ползвал crypto++, предимно openssl и botan, също така що се отнася до DES - сам съм си реализирал алгоритъма, включително в bitslice вид.

......

Братле точно от тебе очаквах отговор, имаш мнооого внушителна работа по криптиранията.
За съжаление имам ограничение (някаква стандартизация) за използването точно на тази библиотека и никоя друга.
За сега и аз като тебе си имам кратки сорсове за отделни алгоритми AES най-често ми се е налагал. Там за бързина част от кода го имам на Асемблер (ползвам го с едночепови Атмеги), разбира се имам и на C ама в момента са се закучили и искат тази тегава библиотека.

А като се повдигна въпроса за реализации на крипто алгоритми имам следният проблем:
Имам блок от данни дълъг 0x4c (по стандарт е между 56 и 128 байта)  прекаран през стандартен алгоритъм за декриптиране изкарва 16 байта. Имам ключ който е 64 или 128 битов. Тоест имам вход, изход, ключ. Въпроса в случая е:
Някакво предположение за алгоритъма на криптиране/декриптиране?

Втори случай:
128 битов ключ, вход криптиран 16 байта, изход декриптиран 16 байта. Въпроса е същият, предположения за алгоритъм  за криптиране/декриптиране?

[gat3way]

Дължината на съобщението няма значение, така или иначе ще се разбива на блокове и при необходимост ще се пад-ва, това става с всеки блоков алгоритъм. Ако е важно да се ползва 128-битов блок, тогава DES отпада, защото работи с 64-битови блокове.

Ако идеята е да се гони сигурност (и изискването за големината на блока е 128 бита), то тогава AES комай е най-добрият вариант. Той работи с 128-битови блокове и е доста сигурен алгоритъм. Дори с 128-битов ключ за момента не е оправдано да се атакува с груба сила алгоритъма (дори от страна на големите агенции там). Но обикновено дявола е в детайлите и всичко може да се осере от наглед дребни неща - примерно ключът ако се генерира по малоумен начин или пък ако ползваш ECB (последното е много лоша идея). DES не е сигурен алгоритъм (макар че за простолюдието като нас все още не е отредено да го чупим с подръчни мат'ряли ), но Triple DES за сметка на това е доста сигурен.

Ако идеята е да се гони производителност....нещата са по-интересни. На x86 архитектура обикновено имаш достатъчно много памет и AES криптирането може да се ускори доста чрез ползване на lookup таблици, вместо правене на бавни сметки. Въпросните таблици не са много големи, обикновено успяват да се съберат в L1 кеша на процесора и заради това, AES е обикновено поне 2 пъти по-бърз от DES на средностатистическата десктоп система. Сега си направих един тест с OpenSSL - AES-128 е почти 3 пъти по-бърз от DES при мен. На архитектури с по-малко памет и липса на процесорни кешове обаче сигурно нещата ще са коренно различни, защото DES по принцип изисква по-малко сметки, а тези фокуси с AES няма как да се реализират.

[kokoex]

И от мен честит празник. Един от най-Българските!