Асиметрично удостоверено криптиране

Знам, че мога да правя автентифицирано шифроване ... използвайки ... CCM, GCM или EAX. Но забелязах, че използват един и същ ключ за криптиране и декриптиране на данни. Не искам това, предпочитам да използвам асиметрични ключове за криптиране и декриптиране на данните си.

Всички схеми, за които съм запознат, ще използват симетричен шифър за масово криптиране на данни. Симетричният шифър може да бъде блоков шифър или поточен шифър.

Виждал съм и няколко неправилни приложения на RSA, където RSA работи в режим ECB. Това означава, че данните се "разделят" или "блокират", след което RSA се прилага към всеки блок. Наръчник за приложна криптография изрично предупреждава срещу това.

Най-доброто, което вероятно ще направите, е Eliptic Curve Integrated Encryption Scheme (ECIES) или Интегрирана система за шифроване на дискретни регистрационни файлове (DLIES). И двете са налични в Crypto++. И двете използват криптография с публичен ключ (асиметрична).

ECIES и DLIES съчетават механизъм за капсулиране на ключове (KEM) с механизъм за капсулиране на данни (DEM). Системата независимо извлича ключ за симетричен шифър и MAC ключ от общ секрет. Данните първо се криптират със симетричен шифър и след това шифрованият текст се MAC'd под схема за удостоверяване. И накрая, общата тайна е криптирана под публичната част на двойка публичен/личен ключ. Резултатът от функцията за криптиране е кортежът {K,C,T}, където K е шифрованата обща тайна, C е шифрованият текст, а T е етикетът за удостоверяване.

Има известно размахване на ръката около „общата тайна“, тъй като тя всъщност е резултат от прилагане на функция за ключово споразумение и по-късно усвоена с KDF. Той използва статичен публичен ключ и двойка ефимерни ключове. Лицето, извършващо дешифрирането, използва публичния си ключ, за да извърши другата половина от обмена на ключове, за да стигне до „общата тайна“.

KEM и DEM избягват подплънките, така че подпълващите оракули не са проблем. Ето защо KDF се използва за усвояване на голямата „обща тайна“ под KEM. Пропускането на подложките значително опростява доказателствата за сигурност на системата. Поради доказателствата за сигурност ECIES и DLIES са IND-CCA2, което е едно от най-силното, което можете да постигнете.

Ако подпиша данни с помощта на асиметричен алгоритъм и след това ги криптирам с помощта на симетричен алгоритъм...

Ето малко свързано четиво... Първо е Редът за криптиране и удостоверяване за защита на комуникациите на Hugo Krawczyk /a>. Второто е Дефектно подписване и шифроване на Дон Дейвис в S/MIME, PKCS#7, MOSS, PEM, PGP и XML.

Уместността тук е: документът на Krawczyk се занимава с криптография със симетричен ключ и стила Encrypt-then-Authenticate на удостоверено криптиране (и как да се извърши удостоверено криптиране). Докладът на Дейвис се занимава с асиметрична криптография и липсата на връзка между подписване и криптиране (и как да го поправите).

Но преди да направя това, има ли крипто библиотеки, които вече правят това, което искам?

Да (но зависи какво искате да правите). Crypto++ е единственият, за който знам, че предоставя ECIES, DLIES и колекция от PSSR.

Bouncy Castle е на второ място, защото осигурява ECIES, но не и DLIES. Не съм сигурен колко PSSR предоставя.

Crypto++, Bouncy Castle, OpenSSL (и други) предоставят PSSR. Не би трябвало да имате проблеми с намирането на lib с PSSR.

Евентуално бихте могли да обмислите решение, базирано на OpenPGP. Това ще ви осигури функционалността, която желаете, и ще се мащабира, за да поддържа произволни размери на данни, за разлика от решение, базирано само на асиметрично криптиране (без транспортен ключ).

Има няколко реализации с отворен код. BouncyCastle предлагат такъв, но не съм сигурен, че имат реализация на C++.

GPGME (GnuPG стана лесно). Това е библиотека за криптиране на високо ниво в C и е лицензирана за LGPL.