Fichier SQLite contenant des caractères indésirables

Question

Je suis actuellement en train d'utiliser MonoTouch et SQLite afin de déterminer s'il est préférable d'utiliser une base de données avec chiffrement plutôt qu'un simple fichier .txt avec chiffrement.

J'essaie d'utiliser RijndaelManaged et d'autres méthodes de System.Security.Cryptography pour chiffrer ma base de données SQLite, mais la base de données devient corrompue.

J'ai trouvé le problème, mais je ne sais pas pourquoi cela se produit ni comment le corriger. Il s'agit d'un fichier SQLite de base avec une seule table :

SQLite format 3@ -‚

øø?gtablenewnewCREATE TABLE new (id int(5), name vchar(255))

Après avoir utilisé un exemple en ligne, et chiffré cette base de données, j'obtiens ceci :

SQLite format 3@ -

?gtablenewnewCREATE TABLE new (id int(5), name vchar(255))

Cela laisse la base de données corrompue et inutilisable. Est-ce que quelqu'un a une idée de pourquoi cela se produit ? Est-ce que quelqu'un peut m'aider à chiffrer cette base de données SANS utiliser SQLCipher ?

EDIT : J'ai essayé de lire la base de données brute en tant qu'octets, et j'ai essayé de convertir les octets en chaîne, mais quelle que soit l'encodage que j'utilise, j'obtiens \0 après la première ligne.

Answer 1

Sans voir vos routines de chiffrement/déchiffrement, je ne peux que deviner. Comme vous utilisez Rijndael, vous devez vous assurer que vous définissez le même Rembourrage sur la classe pour chiffrer et déchiffrer. De plus, assurez-vous d'appeler FlushFinalBlock lors du chiffrement des données. Cet appel n'est pas répertorié dans l'exemple (même s'ils appellent Close qui devrait appeler FlushFinalBlock, donc si vous appelez Close sur le CryptoStream, vous devriez être ok).

Éditer
J'y ai réfléchi un peu plus. Je pense que cela peut être lié au rembourrage (encore une fois, sans voir votre code, il est difficile de dire). Selon le mode de rembourrage que vous choisissez, vous devrez supprimer les octets rembourrés du texte en clair après le déchiffrement.

Answer 2

Les endroits les plus probables où votre problème pourrait résider sont lorsque vous lisez dans la base de données non chiffrée avant le cryptage, ou lorsque vous ouvrez un nouveau fichier pour écrire la base de données fraîchement déchiffrée.

Comme étapes de dépannage, vous pourriez envisager de lire le fichier de base de données brut en tant qu'octets, puis de l'écrire, sans aucun cryptage/décryptage intermédiaire. Si le fichier se corrompt toujours, la première chose que je vérifierais est l'encodage avec lequel vous ouvrez votre fichier de sortie.