Crypt и DES са стари шифри и не трябва да се използват
Обикновен стар DES е остарял алгоритъм. Не можете наистина полезно да го сравните с AES128; все едно да се оплакваш, че хешът на SHA256 е по-голям от хеш на MD5 - да, така е, но само един от тях може да забави нападателя за известно време. DES беше широко смятан за слаб дори през 1999 г. и никога не трябва да се използва в нови приложения. Не го използвайте.
Не мисля, че е добра идея да се търси метод за криптиране, който "осигурява възможно най-малкия размер на данните" - защото всъщност е загуба на време да се криптират данни с помощта на DES. Защо не използвате ROT13 (caesar cypher)? „Шифрованият“ резултат е със същия размер като входа, за съжаление криптирането може да бъде разбито от 3-годишно дете.
крипта е от подобна реколта. Старият алгоритъм за криптиране на UNIX е ... възрастен ... и напълно неподходящ за ново приложение. Наистина хешовете трябва да са поне SHA256.
Crypt е еднопосочен хеш
Що се отнася до невъзможността да разберете как да дешифрирате криптирани данни:crypt не е алгоритъм за криптиране, а криптографска хеш функция или "еднопосочен хеш". Еднопосочните хешове са подходящи за проверка, че данните са немодифицирани, в сравнение със съхранен солен хеш за удостоверяване на парола, за използване при удостоверяване при предизвикателство-отговор , и т.н. Не можете да дешифрирате криптирани данни.
Справете се с размера
Използвайте прилична криптографска функция и живейте с увеличаването на размера. bf или aes128 са най-слабите, които разумно можете да използвате.
Лично аз предпочитам да правя криптирането/декриптирането си в приложението, а не в DB. Ако е направено в DB, ключовете могат да бъдат разкрити от pg_stat_statements , в регистрационните файлове от log_statement или грешки и т.н. По-добре ключът никога да не е на същото място като съхранените данни.
Повечето езици за програмиране имат добри криптографски процедури, които можете да използвате.
Трудно е да се даде повече съвет, тъй като не сте обяснили наистина какво шифровате, защо, какви са вашите изисквания, какви са заплахите и т.н.
Пароли?
Ако съхранявате пароли, вероятно го правите погрешно.
-
Ако е възможно, оставете някой друг да извърши удостоверяването:
-
OAuth или OpenID за интернет
-
SSPI, Kerberos/GSSAPI, Active Directory, LDAP свързване, SASL, HTTP DIGEST и т.н. за интранет
-
-
Ако наистина трябва да извършите удостоверяването сами, добавете сол към паролите и хеширайте резултата. Съхранявайте хашиша и солта. Когато трябва да сравните пароли, солете новия обикновен текст от потребителя със същата сол, която сте използвали за съхранения хеш, хеширайте новата парола+сол и вижте дали хешът е същият като това, което сте съхранили. Ако е, те са дали правилната парола.
-
Почти сигурно не е необходимо да възстановявате пароли с чист текст. Вместо това приложете сигурно повторно задаване на парола. Ако наистина, наистина трябва, използвайте прилично защитен алгоритъм като aes, за да ги шифровате и помислете внимателно за съхранението и управлението на ключовете. Вижте други публикации в SO за съхранение/управление на ключове с pgcrypto.
Вижте също:
