Stocker des fichiers cryptés dans une base de données

J'utilise PyCrypto pour stocker certains fichiers dans une base de données SQLITE.Stocker des fichiers cryptés dans une base de données

J'utilise 4 champs:
le nom du fichier,
la longueur du fichier (en octets)
le hachage SHA512 du fichier
le fichier crypté (avec AES puis base64 à ASCII).

J'ai besoin de tous les champs pour montrer quelques informations sur le fichier sans le décrypter.

La question est: est-il sécuritaire de stocker les données comme ceci?
Par exemple, les premiers caractères d'un fichier ZIP, ou d'un fichier exécutable sont toujours les mêmes, et si vous connaissez déjà le hachage et la longueur du fichier ... est-il possible de décrypter le fichier, peut-être partiellement?

Si ce n'est pas sécurisé, comment puis-je stocker des informations sur le fichier pour indexer les fichiers sans les décrypter? (Informations comme la longueur, hachage, nom, étiquettes, etc.)

(j'utilise python, mais vous pouvez donner des exemples dans toutes les langues)

Source

2011-05-07 Cristi Constantin

note pour économiser de l'espace et éviter le surcoût de base64 (augmentation de 33% environ), vous devez utiliser des blobs pour stocker des données binaires dans une base de données sqlite. –

Pour éviter tout problème concernant les premiers octets étant les mêmes, vous devez utiliser AES en mode Bloc Cipher avec un IV aléatoire. Cela garantit que même si le premier bloc (la longueur dépend de la taille de la clé) de deux fichiers cryptés est exactement le même, le texte chiffré sera différent.

Si vous faites cela, je ne vois aucun problème avec votre approche.

Source

2011-05-07 09:58:50 Demento

Merci. Ma question est résolue. :) –

données cryptées avec AES a la même longueur que les données brutes (donner ou prendre un certain rembourrage de bloc), de sorte que donner la longueur d'origine ne nuise pas à la sécurité. SHA512 est un hachage cryptographique fort conçu pour fournir des informations minimales sur le contenu original, donc je ne vois pas de problème ici non plus.

Par conséquent, je pense que votre système est assez sûr. Toute information "exposée" par elle est négligeable. La gestion des clés sera probablement une préoccupation beaucoup plus importante de toute façon.

Source

2011-05-07 08:10:08

Vous réservoir beaucoup! –

Vous ne pouvez pas simplement dire "oah son AES-256 bien sûr sa sécurité." Juste par votre poste, je peux voir que vos attaques confuses contre les chiffrements de flux et les chiffrements de bloc, donc vous devriez probablement mettre en œuvre ceci jusqu'à ce que vous fassiez des recherches sur ce sujet.

Cela étant dit, vous devez lire environ block cipher modes of operation. Toute la famille CWE-310. Ça ne ferait pas de mal de prendre une copie de la cryptographie piratée. Après tout cela, il y a encore beaucoup de place pour que vous puissiez tout gâcher.

Solution réelle: UTILISEZ QUELQU'UN D'AUTRE MISE EN ŒUVRE.

Source

2011-05-07 19:56:13 rook

Merci, je vais chercher ce livre. Comme vous l'avez deviné, je suis un débutant en cryptographie, j'utilise les outils d'autres personnes. Je veux juste garder mes données privées aussi privées que possible. Je salage la clé et stocke le sel et la clé SHA512 dans la base de données, avec le fichier crypté et les balises. Ça doit être sûr. L'utilisation de quelqu'un d'autre n'est pas une solution, sauf si vous connaissez un logiciel qui crée des "conteneurs indexés compressés chiffrés portables" pour les fichiers. C'est ce que j'essaie de faire. –

@Cristi Constantin Je ne pense pas que c'est une façon valide de stocker une clé. sha512 est un moyen, vous ne pouvez pas obtenir le texte brut, si vous le frappez à nouveau avec sha512 alors l'attaquant peut le faire. Qui a besoin d'accéder aux données? Qui essayez-vous d'empêcher d'accéder aux données? – rook

@Rook: J'ai lu votre profil, donc je ne suis pas en désaccord avec tout ce que vous dites :). Quoi qu'il en soit, SHA512 est une fonction à sens unique? Donc, si je salais le mot de passe (8 caractères de sel) et hachage le résultat, il ne devrait pas être possible d'utiliser l'attaque des tables arc-en-ciel. La personne qui a stocké les fichiers dans la base de données devrait être la seule à avoir accès aux fichiers. Personne d'autre. –

Vous devez vraiment penser aux attaques contre lesquelles vous voulez vous protéger et aux ressources des éventuels attaquants.

En général, le stockage de certaines données chiffrées n'est utile que s'il répond exactement à vos besoins. En particulier, s'il existe un moyen pour un attaquant de compromettre la clé en même temps que les données, alors le chiffrement est effectivement inutile.

Source

2011-05-09 06:31:15 MarkR

Eh bien, je veux juste que mes données privées soient ... aussi privées que possible. Peut-être que je devrais utiliser PGP au lieu de AES. De toute façon, j'ai eu la réponse que je voulais. Merci pour le tuyau! –

@Cristi: vous devez tenir compte de la gestion des clés dans votre application; C'est le principal problème avec l'utilisation du cryptage. – MarkR

Stocker des fichiers cryptés dans une base de données

Répondre

Questions connexes