Crypt och DES är gamla cypher och bör inte användas
Vanlig gammal DES är en föråldrad algoritm. Du kan inte riktigt jämföra det med AES128; det är som att klaga på att en SHA256-hash är större än en MD5-hash - japp, det är det, men bara en av dem kan sakta ner angriparen ett tag. DES ansågs allt vara svag även 1999 och bör aldrig användas i nya applikationer. Använd den inte.
Jag tror inte att det är en bra idé att söka efter en krypteringsmetod som "ger minsta möjliga datastorlek" - eftersom det i grunden är ett slöseri med tid att kryptera data med DES. Varför inte använda ROT13 (caesar cypher)? Det "krypterade" resultatet har samma storlek som inmatningen, synd att krypteringen kan brytas av en 3-åring.
krypt är av liknande årgång. Den gamla UNIX-krypthashingalgoritmen är ... äldre ... och totalt olämplig för någon ny applikation. Hashes bör vara minst SHA256, verkligen.
Crypt är en enkelriktad hash
När det gäller att inte kunna ta reda på hur man dekrypterar krypterad data:kryptera är inte en krypteringsalgoritm, det är en kryptografisk hashfunktion eller "one way hash". Ett sätts hash är lämpligt för att verifiera att data är oförändrad, jämfört med en lagrad saltad hash för lösenordsautentisering, för användning i utmaningssvarsautentisering , etc. Du kan inte dekryptera krypterad data.
Hör med storleken
Använd en anständig kryptografisk funktion och lev med storleksökningen. bf eller aes128 är ungefär de svagaste du rimligen kan använda.
Personligen föredrar jag att göra min kryptering/dekryptering i appen, inte i DB. Om det görs i DB kan nycklarna avslöjas av pg_stat_statements , i loggarna med log_statement eller fel, etc. Bättre att nyckeln aldrig är på samma plats som den lagrade data alls.
De flesta programmeringsspråk har bra kryptografiska rutiner som du kan använda.
Det är svårt att ge några fler råd eftersom du inte riktigt har förklarat vad du krypterar, varför, vilka krav du har, vad hoten är osv.
Lösenord?
Om du lagrar lösenord gör du förmodligen fel.
-
Om möjligt, låt någon annan göra autentiseringen:
-
OAuth eller OpenID för Internet
-
SSPI, Kerberos/GSSAPI, Active Directory, LDAP bind, SASL, HTTP DIGEST, etc för intranät
-
-
Om du verkligen måste göra autentiseringen själv, lägg till ett salt i lösenorden och hasha resultatet. Förvara hashen och saltet. När du måste jämföra lösenord, salta den nya klartexten från användaren med samma salt som du använde för den lagrade hashen, hasha det nya lösenordet+salt och se om hashen är samma som det du lagrade. Om det är det, gav de rätt lösenord.
-
Du behöver nästan säkert inte återställa klartextlösenord. Implementera en säker lösenordsåterställning istället. Om du verkligen, verkligen måste, använd en hyggligt säker algoritm som aes för att kryptera dem och tänk noga på nyckellagring och hantering. Se andra inlägg på SO om nyckellagring/hantering med pgcrypto.
Se även: