[PHP] Mcrypt ciphers; Welke?

[frickY]

Voor het opslaan van klantgegevens heb ik mijn hosting de mcrypt-module laten installeren om deze te kunnen coderen met een goede codering.
Nu is er echter een nogal lange lijst met alle ciphers die ik nu tot mijn beschikking heb, waaruit kiezen lastig is.

Supported ciphers:
cast-128, gost, rijndael-128, twofish, arcfour, cast-256, loki97, rijndael-192, saferplus, wake, blowfish-compat, des, rijndael-256, serpent, xtea, blowfish, enigma, rc2, tripledes
Supported modes:
cbc, cfb, ctr, ecb, ncfb, nofb, ofb, stream

Ik heb wat rondgezocht met Google en een aantal forums bezocht, en het schijnt dat Rijndael-256 momenteel onkraakbaar is (het zou je ongeveer 22duizend keer de leeftijd van het helal kosten om te kraken, volgens beweringen).
Nu wil ik dat best geloven, maar waarom zijn er dan nog zoveel andere ciphers?

Wie kan mij een aantal voor- en nadelen noemen van 1 of meer van bovenstaande ciphers, of heeft andere adviezen?

Het liefst zou ik gebruik maken van een public-key systeem, zodat de sleutel nergens in de source komt te staan. Maar de enige manier die ik heb gevonden om dat te doen (PGP) is te lastig om te implementeren.

[Soultaker]

De mate van veiligheid van geen van deze ciphers is bewezen; er is uitsluitend de afwezigheid van substantieel bewijs dat ze onveilig zouden zijn, waardoor men vermoedt dat ze veilig genoeg zijn om te gebruiken.

Rijndael is door het Amerikaanse instituut voor technologiestandaarden (NIST) gekozen tot advanced encryption standard (AES) en is daardoor een redelijk "veilige" keuze.

Behalve de beveiliging hebben de algoritmen ook een heleboel andere eigenschappen waar je je keuze op zou kunnen baseren, zowel met betrekking tot de algoritmen als de implementatie. Je kunt daarbij denken aan zaken als parallellisme, processorgebruik, geheugengebruik en allerlei eigenschappen met betrekking tot de grote van de invoer (initialisatiekosten, etcetera). Ik heb daar zelf verder geen gedetailleerde gegevens over, maar Google kan je daar vast wel het een en ander over vertellen.

Het verschil in eigenschappen van de implementaties zijn dan ook precies de reden dat er verschillende ciphers beschikbaar zijn: in verschillende situaties spelen er verschillende belangen. In het ene geval zal je vooral een snel algoritme willen hebben, ongeacht de opstarttijd of het geheugengebruik; in een ander geval wil je een algoritme dat vlot kleine stukjes gegevens kan coderen, zonder dat je lang hoeft te initialiseren of grote hoeveelheden geheugen moet vrijmaken.

Mijn advies heb ik al gegeven: gebruik gewoon Rijndael als je twijfelt. Dat is waarschijnlijk goed genoeg. Een andere bekende goede cipher is Blowfish; die zou wat sneller zijn dan Rijndael, maar gebruikt een kleinere key (dacht ik). PGP biedt je geen extra mogelijkheden, aangezien je dan (neem ik aan) je private key in de broncode moet zetten; dat is net zo vervelend als je globale key van een symmetrisch encryptiealgoritme.

[ Voor 9% gewijzigd door Soultaker op 20-08-2003 18:08 ]

[frickY]

In ieder geval bedankt voor je informatie.

Bij PGP zou ik mijn public key in de source meoten zetten, hiermee worden de gegevens gecodeerd wanneer ze worden opgeslagen.
Mijn privatekey zou het wachtwoord zijn waarmee ik in de verwerkingspagina's inlog. Deze staat dus nergens opgeslagen, maar voer ik telkens opnieuw in.

De eisen waaraan het cipher moet voldoen dat ik zoek is vooral betrouwbaarheid.
De strings die gecodeerd moeten worden bestaan uit hoogstens 20 karakters, en dit gebeurt alleen bij een transactie (hou het op 30 per dag). De server waar het geheel op draait is een dedicated FreeBSD bak met een Celeron en 128MB. Dit lijkt mij voldoende om een fatsoenlijke cipher te kunnen gebruiken voor zulke kleine codeer-klusjes.

Ik heb al eens mijn eigen codering geschreven, welke vooral was gebaseerd op een logical XOR op de plaintext en de key, en wat character shifting ed. Was leuk om te doen, maar niet geschikt voor dit doel.

Een nadeel van rijndeal vond ik de IV. Deze moest, bij voorkeur, random zijn, maar moest ik ook hebben om de ciphertext te decoderen. En om die IV nou met de ciphertext op te slaan klinkt mij weer niet slim in de oren. Dat heb ik toen opgelost door gewoon een vaste IV te nemen, maar dat resulteerde weer dat op elkaar lijkende plaintext ook in cipher op elkaar leek. Heeft elke cipher een IV nodig? OF heeft iemand tips om deze IV ook op te slaan. Zat al te denken om de PK uit de database te gebruiken waaronder de waarde wordt opgeslagen, maar misschien zijn er betere oplossingen.

[Soultaker]

frickY schreef op 20 August 2003 @ 19:10:
Bij PGP zou ik mijn public key in de source meoten zetten, hiermee worden de gegevens gecodeerd wanneer ze worden opgeslagen. Mijn privatekey zou het wachtwoord zijn waarmee ik in de verwerkingspagina's inlog. Deze staat dus nergens opgeslagen, maar voer ik telkens opnieuw in.

Je wil niet een hele private key in moeten typen; je zult die dus toch echt ergens op moeten slaan. Uiteraard hoeft dat niet in je broncode te zijn, of kan je er een keyphrase aan verbinden, maar dan is de situatie volgens weer bijna hetzelfde als wanneer je direct die keyphrase in een symmetrisch algoritme zou gebruiken. Als je met je keyphrase niet je PGP private key ophaalt, maar een sterke key voor je symmetrische algoritme, dan heb je exact dezelfde situatie. Ik zie dus nog steeds het voordeel niet echt; assymetrische encryptie is vooral van belang als je geen controle hebt over het communicatiemedium, maar op een lokale PC heb je dat gewoon wel.

De eisen waaraan het cipher moet voldoen dat ik zoek is vooral betrouwbaarheid. De strings die gecodeerd moeten worden bestaan uit hoogstens 20 karakters, en dit gebeurt alleen bij een transactie (hou het op 30 per dag). De server waar het geheel op draait is een dedicated FreeBSD bak met een Celeron en 128MB. Dit lijkt mij voldoende om een fatsoenlijke cipher te kunnen gebruiken voor zulke kleine codeer-klusjes.

Lijkt mij ook, maar dat kun je natuurlijk uitstekend benchmarken. Maak een simpele PHP pagina die een transactie simuleert en doe een benchmark (bijvoorbeeld met ab, als je Apache hebt geinstalleerd); waarschijnlijk ben je binnen een paar seconde klaar en dan is 't goed.

Een nadeel van rijndeal vond ik de IV. Deze moest, bij voorkeur, random zijn, maar moest ik ook hebben om de ciphertext te decoderen. En om die IV nou met de ciphertext op te slaan klinkt mij weer niet slim in de oren. Dat heb ik toen opgelost door gewoon een vaste IV te nemen, maar dat resulteerde weer dat op elkaar lijkende plaintext ook in cipher op elkaar leek. Heeft elke cipher een IV nodig? OF heeft iemand tips om deze IV ook op te slaan. Zat al te denken om de PK uit de database te gebruiken waaronder de waarde wordt opgeslagen, maar misschien zijn er betere oplossingen.

De PHP manual is daar vrij duidelijk over:

The IV is only meant to give an alternative seed to the encryption routines. This IV does not need to be secret at all, though it can be desirable. You even can send it along with your ciphertext without loosing security.

Je kunt dus prima een fixed value gebruiken, of inderdaad iets systeemspecifieks als een database id (maar die moet dan wel voor altijd fixed zijn; ook als je je database dumpt en restored!). Zelf zou ik gewoon een constante waarde gebruiken, eigenlijk. Ik zie geen reden om het veiliger dan "gewoon veilig" te maken.

[frickY]

Ik gebruikte dus een constante IV; het reultaat van log(375) (of iets in die richting). Das een heel mooi lang decimaal getal en zeer geschikt als IV.
Als ik echter een de strings "AB12-01329" en "AB12097123" codeer, zijn de eerste paar karakters in de ciphertext vaak ook hetzelfde.
Nu is dit een onlogische text. Maar als je weet wat voor soort strings er worden opgeslagen, wat niet ondenkbaar is, kan je dit soort ciphertexten dan niet kraken met een karakter-analyse (of hoe zoiets ook mag heten) ?

Ik heb gemerkt dat wanneer je een random IV gebruikt, de ciphertexten wel absoluut verschillend zijn.

[frickY]

/me doet ff klein schopje
Is er hier dan niemand die hier verstand van heeft?

Dan hou ik het maar gewoon bij Rijndeal-256. OF misschien trek ik die ciphertext ook nog even door Blowfish...