[C++]Cryptoapi, partial encryption mogelijk?

[sh4d0wman]

Ik heb een probleempje met de Microsoft CryptoApi en hoop dat jullie mij verder kunnen helpen.

Voor een project moet ik binnen Windows bestanden versleutelen. Dit lukt met behulp van de Cryptoapi en als test met 3Des. Echter bij grote bestanden duurt het erg lang, wat begrijpelijk is. Men wil nu graag bestanden deels encrypten (partial encryption) echter weet ik niet hoe ik dit op de juiste wijze implementeer.

Mijn probleem is: ik lees x bytes vanaf het begin van een bestand, versleutel dit en schrijf het terug. Echter als ik als test 16 bytes inlees dan komt er een padding overheen en overschrijf ik dus valide bytes in mijn testbestand.

Nu kwam ik voor AES een CTS en OFB modus tegen waarbij de plaintext en ciphertext exact even lang zijn bij encryptie. Echter de cryptoapi geeft geen ondersteuning voor OFB en bij CTS krijg ik een error GetLastError geeft -2146893819.

code:

DWORD dwMode = CRYPT_MODE_CTS;
if(!CryptSetKeyParam(hKey, KP_MODE, (PBYTE)&dwMode, 0))
{
    printf("Error %x during CryptSetKeyParam!\n", GetLastError());
    goto Cleanup;
}

Iemand die mij de juiste richting op kan sturen zodat ik partial encryption werkend kan krijgen?

[xos]

Mijn eerste tip zou zijn probeer de performance eens uit met AES ipv 3DES. AES is over het algemeen een heel stuk rapper dan 3DES. Misschien dat de performance dan al acceptabel is. CryptoAPI ken ik niet maar openssl komt met een utility waarmee je eenvoudig kan testen hoe lang het duurt om een bestand te versleutelen met een cipher.

3DES en AES zijn blockchipers, dat kan je zien als een lookup tabel waarin een block plaintext wordt gemapped naar een block chipertext. Voor 3DES is de blocksize 64 en voor AES 128 bits. Het mag duidelijk zijn dat het niet gaat om een echte lookup tabel aangezien zo'n tabel een beetje groot is . Omdat ciphertext meestal niet precies een veelvoud is van de blocksize moet padding toegevoegd worden. Dus padding voegt maximaal blocksize -1 bits toe. Als het gaat om grote bestanden dan lijken mij deze paar bits niet een groot probleem? Of wil je een deel van het originele bestand in place vervangen door de ciphertext?

Naast de keuze voor een snelle blockcipher kan je ook kiezen voor een streamcipher of een "mode of operandi" die een blockcipher omzet in een streamciphers. De door jouw genoemde OFB is een voorbeeld van de 2e variant. Kies dan CTR over OFB aangezien die geen last heeft van het "short cycle probleem". Je kunt dan het lezen van het bestand, toepassen van de XOR en het wegschrijven in 1 thread doen en de cipher operaties in een 2e thread. Een streamciphers heeft ook geen padding nodig.

Maar wat bedoel je precies met partial encryption? Als je daarmee bedoelt dat je alleen een deel van een bestand wilt versleutelen dan kan je alleen de eerste n * blocksize bits pakken zodat er geen padding nodig is.

[Fiander]

Dus jou probleem is eigenlijk dat terwijl je aan het encrypten bent, je met je nieuwe data, data overschrijft die je nog moet inlezen om te encrypten?

Als je je geencrypte stream nou eens als een nieuwe stream wegschrijft? zodat je tijdens encrypten twee streams hebt? Dit zou als nieuw bestand kunnen, maar misschien dat je de ADS functionaliteit kunt gebruiken van ntfs?

[sh4d0wman]

xos schreef op zondag 25 maart 2012 @ 08:38:
Of wil je een deel van het originele bestand in place vervangen door de ciphertext?

Maar wat bedoel je precies met partial encryption? Als je daarmee bedoelt dat je alleen een deel van een bestand wilt versleutelen dan kan je alleen de eerste n * blocksize bits pakken zodat er geen padding nodig is.

Ik wil inderdaad een deel van een bestand encrypten. Dus als volgt:
- Open sourcefile
- Lees x bytes
- Versleutel
- Schrijf terug in sourcefile

Ik heb inderdaad ook gelezen dat als je n * blocksize bits versleuteld er geen padding nodig zou zijn. Echter als test heb ik van mijn sourfile 16 bytes gelezen en na encryptie is deze 16 bytes langer (de AES default blocksize, correct?). De CTS modus krijg ik niet werkend en zie hetzelfde met google terug, de andere modus die je noemde staat als not support op MSDN.

Ik zit er nu over te denken om wellicht vanaf het einde van het bestand te werken. Lees de laatste x bytes in en encrypt. Als er dan een extra block volgt is het geen probleem. Eigenlijk ben ik benieuwd hoe men deze vorm van encryptie op de juiste manier implementeerd. Ik ben er met een zoektocht in ieder geval patenten van tegengekomen.

[xos]

sh4d0wman schreef op zondag 25 maart 2012 @ 10:50:
Ik heb inderdaad ook gelezen dat als je n * blocksize bits versleuteld er geen padding nodig zou zijn. Echter als test heb ik van mijn sourfile 16 bytes gelezen en na encryptie is deze 16 bytes langer (de AES default blocksize, correct?). De CTS modus krijg ik niet werkend en zie hetzelfde met google terug, de andere modus die je noemde staat als not support op MSDN.

Dan vermoed ik dat er fout in je code zit. Roep je nog een final achtige methode aan? Vaak is er een update methode op de chiper structuur om een volgend block data aan te bieden en een final methode om de chiper structuur het restant aan te bieden en te informeren dat het datablok met padding aangevuld moet worden. Als je zelf in de gaten houdt dat je precies n * blocksize hebt aangeboden dan hoef je deze final methode niet aan te roepen. Ik ben ook benieuwd wat voor data er tevoorschijn komt na decryptie?

Afhankelijk van de gekozen mode heb je ook nog een IV of een nonce nodig. Dus je hebt überhaupt extra informatie nodig. En ja, AES heeft een blocksize van 128 bits.

sh4d0wman schreef op zondag 25 maart 2012 @ 10:50:
Ik zit er nu over te denken om wellicht vanaf het einde van het bestand te werken. Lees de laatste x bytes in en encrypt. Als er dan een extra block volgt is het geen probleem. Eigenlijk ben ik benieuwd hoe men deze vorm van encryptie op de juiste manier implementeerd. Ik ben er met een zoektocht in ieder geval patenten van tegengekomen.

Kan je de user case eens toelichten? Want een bestand deels versleutelen is al opvallend, en zomaar besluiten dat het een ander deel van het bestand moet worden klinkt nog vreemder?

[Soultaker]

Wikipedia zegt over de encryptie-snelheid van AES: "On a Pentium M 1.7 GHz throughput is about 60 MiB/s." Het lijkt me dan sterk dat op een beetje moderne processor de encryptie daadwerkelijk de bottleneck is, aangezien weinig schijven meer dan 60 MiB/s (sustained) kunnen schrijven, en de meeste processoren een stuk sneller zijn dan die Pentium M.

Kortom: als je AES gebruikt zou de CPU de bottleneck niet mogen zijn.

---

Nu even over de gebruikte block cipher mode. Als je in deze tijd nog voor ECB-mode kiest (waarbij ieder blok los gecodeerd wordt) ben je een idioot en hoor je je niet met encryptie bezig te houden. Beter is block chaining (CBC) of counter mode (CTR). Het voordeel van CTR ten op zichte van de CBC voor het encrypten van bestanden is dat je op een willekeurige plek in het bestand kunt lezen/schreven (op block boundaries, tenminste) in plaats van dat je het hele bestand vanaf het begin moet coderen/decoderen.

Maar voor zowel CBC als CTR mode gebruiken typisch een random initialization vector. Dat zijn waarschijnlijk de extra 16 bytes die weggeschreven worden. (Ik ken de CryptoApi niet, maar ik vermoed dat de ontwerpers slimmer waren dan jij en dus standaard een IV genereren.) Je kunt die weglaten maar zie dan mijn eerdere opmerking t.b.v. idioten die geen encryptie-code mogen schrijven.

Als je delen van een bestand wil coderen dan zul je waarschijnlijk ergens meta-data op moeten slaan over de gebruikte initialization vector én welke delen van het bestand wel/niet gecodeerd zijn. Onder Windows kun je die wellicht in een alternate data stream kwijt. Daarin kun je ook mooi het gebruikte algoritme en andere parameters opslaan.

[sh4d0wman]

Ik denk dat je wel eens juist zou kunnen zitten met de final methode. Ik zal morgen eens testen wat er gebeurd als ik dit skip, ben benieuwd of de data dan goed encrypt en ook gedecrypt kan worden.

De usercase is als volgt: mediabestanden worden digitaal verkocht, encryptie moet deze bestanden tegen piracy beschermen. Volledige encryptie neemt veel resources in beslag op embedded systemen (end points) dus men wil liever partial encryption. Hiermee win je tijd en zijn de bestanden geencrypt nog steeds zo goed als waardeloos. Het liefst encrypt ik dus een x aantal blocks in 1 file (hierdoor kan ik voor een test zowel aan het begin of eind van een file beginnen), echter liep ik al vast op 1 block

@soultaker, ik draai al in CBC mode en heb een 16 byte IV (dmv GenRandByte). de CTR modus krijg ik alleen niet aan de praat zoals eerder gemeld.

[ Voor 9% gewijzigd door sh4d0wman op 25-03-2012 17:17 ]

[Soultaker]

Maar die IV was toch juist het probleem? Of begrijp ik je nu verkeerd?

Als je toch het bestand maar ten dele codeert kun je die hele IV wel achterwege laten want mensen die de plaintext kennen kunnen dan toch eenvoudig het hele bestand afleiden.

[MSalters]

Sowieso, 16 bytes encrypten? Wat is de winst daarvan? Het lijkt me niet verstandig om minder dan 4kB (typische blokgrootte van NTFS, en page size van x86) te encrypten. Dan heb je ook geen last van de blokgrootte van typische ciphers.

En wat betreft encryption op embedded systemen: Geen probleem, zelfs als je 4GB+ encrypted data en een ARM9 processortje hebt, laat staan als je Windows gebruikt.

[sh4d0wman]

Allemaal bedankt voor de vele reacties, ik ga er nog eens even op studeren. In place encryptie lijkt niet (makkelijk) mogelijk en daarom zal ik nu eerst de routine om files volledig te encrypten afmaken. (alle voorbeelden op internet maken ook gebruik van een source/destination file constructie)