SQLite database wordt ineens groter

[Verwijderd]

LS,

Ik wil alle strings in mijn SQLite database encrypten. Daarvoor doe ik;

SELECT _id,name FROM MyTable

Daarna loop ik door het resultaat, en vervang de string met de versleutelde versie;

UPDATE MyTable SET name=' + encryptedname + ' WHERE _id=' & id

Zoals gebruikelijk bij het klussen moet je hierna schoonmaken, dus doe ik op het einde een;

VACUUM

Tot mijn stomme verbazing is de database geen 1300kb meer, maar ineens 1600kb. En ik snap niet hoe dat kan!, de versluetelde strings zijn precies even lang als de originele. Ik snap ook heel goed dat compressie altijd moet doen voordat je data versleuteld, maar dat is hier niet aan de orde, het word ongecomprimeerd opgeslagen. Als ik het SQLite bestand open met een HEX editor, kan ik gewoon de text lezen.

Mijn vragen;
-Moet ik naast VACUUM nog een iets doen om de boel op te schonen?
-Waar komt die extra 300kb vandaan?

[voodooless]

Als er gebruikt wordt gemaakt van indexen kan het zijn dat de nieuwe indexen groter zijn dat de oude. Volgens de FAQ zou een vacuum de database van scratch opnieuw moeten opbouwen, en het resultaat zou dus de meest optimale situatie moeten zijn.

[NMe]

Als je encrypted namen niet in één byte passen (lees: UTF-8 nodig hebben) dan hebben sommige tekens ineens 2 of zelfs 3 bytes nodig. Dat is het enige dat ik me zo kan bedenken zonder SQLite-kennis.

[Verwijderd]

NMe schreef op donderdag 06 oktober 2011 @ 16:26:
Als je encrypted namen niet in één byte passen (lees: UTF-8 nodig hebben) dan hebben sommige tekens ineens 2 of zelfs 3 bytes nodig. Dat is het enige dat ik me zo kan bedenken zonder SQLite-kennis.

Plausibel!, maar als ik met een editor in de database kijk, is de string weer precies even veel characters. Wil idd nog niet zeggen of ze ook zo worden opgeslagen!

Thnx voor het mee denken!

[NMe]

Het aantal karakters zegt niets over het aantal bytes. Spul dat in de ASCII-tabel staat is te representeren met één byte, maar bijvoorbeeld een Japans karakter zal er al snel 3 innemen.

[DexterDee]

Als je 'name' veld nu een TEXT veld is en je encryptie maakt er binaire data van (bytes van 0-255) dan moet dat veld een BLOB worden. Anders gaat sqlite onbedoeld de binaire data als text zien. Als je toch het TEXT veld wilt behouden, dan is het aan te raden om een BASE64 over de encrypted string te gooien.

Er bestaat ook zoiets als transparante encryptie over de gehele sqlite database, door middel van een extensie. Dan is je hele database beveiligd en hoef je zelf niet meer zorg te dragen voor encryption. En omdat het transparant is, hoef je je queries niet aan te passen.

[ Voor 33% gewijzigd door DexterDee op 06-10-2011 17:14 . Reden: link naar sqlcipher ]

[Voutloos]

NMe schreef op donderdag 06 oktober 2011 @ 16:26:
Als je encrypted namen niet in één byte passen (lees: UTF-8 nodig hebben) dan hebben sommige tekens ineens 2 of zelfs 3 bytes nodig. Dat is het enige dat ik me zo kan bedenken zonder SQLite-kennis.

Ik weet niet met wat voor encryptiefuncties jij werkt, maar uit de normale functies komt gewoon binair spul waar je verder vooral niet met char encoding moet doen. Just a bunch of bytes -> blob datatype (of hoe het ook @ je dbms heet) en klaar.

[Gomez12]

Zijn het niet gewoon simpelweg de genoemde indexen?

Dat het in text-vorm relatief gelijk is en encrypted het "random" wordt waardoor de indexen meer ruimte innemen?

[NMe]

Voutloos schreef op donderdag 06 oktober 2011 @ 18:41:
[...]
Ik weet niet met wat voor encryptiefuncties jij werkt, maar uit de normale functies komt gewoon binair spul waar je verder vooral niet met char encoding moet doen. Just a bunch of bytes -> blob datatype (of hoe het ook @ je dbms heet) en klaar.

Hij heeft het over strings, dus ga ik uit van varchar.

[Soultaker]

Het gaat over SQLite; die doet sowieso niet aan varchar.

Waarschijnlijk gebeurt er inderdaad wat NMe voorspelde omdat de name-kolom text affinity heeft, en moet je de boel als BLOB opslaan (het is ook niet alsof je zinnig kunt sorteren op gecodeerde data). Ik vraag me sowieso af wat SQLite precies doet als je binary (non-UTF8) data probeert op te slaan alsof het UTF8 tekst is.

[Verwijderd]

De details over de encryptie kan ik natuurlijk niet prijs geven , ik heb het zelf gemaakt, en het gebeurt op een manier dat het weer binnen een string past. De versleutelde gegevens vallen ook gewoon binnen de ASCI tabel.

Ik weet dat je ook de hele SQLite database kan encrypten, maar dat ondersteunt android niet helaas

Even simpel gezegd, als de input string 'Nederland' is, zou de 'versleutelde' versie 'danlredeN' kunnen zijn. Niks binair oid, past gewoon weer binnen een string, en het is even lang. En ik hou zelfs rekening met de 'verboden' characters zoals de '.

Ook al zou het index gerelateerd zijn, dan snap ik nog steeds de toename van bijna 25 procent niet. Ik voeg niks toe, ik vervang alleen maar.

Moet ik het misschien met een REPLACE doen?

IGG bedankt voor het mee denken allemaal!

[Voutloos]

Verwijderd schreef op vrijdag 07 oktober 2011 @ 09:39:
De details over de encryptie kan ik natuurlijk niet prijs geven , ik heb het zelf gemaakt, en het gebeurt op een manier dat het weer binnen een string past.

Leesvoer: Security through obscurity, Kerckhoffs's Principle. Je zal, tenzij je zelf minstens RSA uitgevonden hebt een slecht algoritme hebben bedacht. Zonde van je tijd en gegarandeerd onveilig, want je kan de veiligheid niet bewijzen. Pak dan een bestaande proven security algo, en gooi er desnoods base64 overheen als je geen gekke bytes wilt (en neem de extra omvang voor lief).

[joppybt]

Als je het echt wilt weten kun je een reductie-strategie toepassen.

Maak van de database voor en na de encryptie een kopietje en ga daarin strippen.

Drop bijvoorbeeld in beide databases de indexen op die tabel en doe een vacuum. Als het grootte verschil gelijk is gebleven ligt het niet aan de indexen, anders wel.

Ik neem aan dat je ook je encryptie kunt omkeren. Als je dat toepast op de encrypted database, is dan na afloop de grootte weer gelijk aan het origineel?

Tenslotte: Gebruik sqlite3_analyzer.exe van http://www.sqlite.org/download.html eens, dat moet toch uitsluitsel geven waar het probleem zit.

[ Voor 13% gewijzigd door joppybt op 07-10-2011 19:01 ]

[Gunirus]

Toevallig eergisteren ook zoiets tegengekomen, een kleinere page_size geset voor het runnen van de VACUUM het de database was terug lekker klein