Chiffrement d'accès aléatoire avec AES En mode compteur utilisant Fortuna PRNG:

Question

Je construis un chiffrement de fichier basé sur AES qui doit pouvoir fonctionner en mode accès aléatoire (accès à n'importe quelle partie du fichier). AES in Counter par exemple peut être utilisé, mais il est bien connu que nous avons besoin d'une séquence unique jamais utilisée deux fois. Est-il correct d'utiliser un PRNG Fortuna simplifié dans ce cas (cryptage d'un compteur avec une clé unique choisie au hasard et spécifique au fichier en question)? Y a-t-il des points faibles dans cette approche?

Donc, le cryptage/décryptage peut ressembler à ceci

Le chiffrement d'un bloc à décalage:

rndsubseq = AESEnc(Offset, FileUniqueKey) 
xoredplaintext = plaintext xor rndsubseq 
ciphertext = AESEnc(xoredplaintext, PasswordBasedKey) 

Décryptage d'un bloc à décalage:

rndsubseq = AESEnc(Offset, FileUniqueKey) 
xoredplaintext = AESDec(ciphertext, PasswordBasedKey) 
plaintext = xoredplaintext xor rndsubseq 

Une observation. Je suis venu à l'idée utilisée dans Fortuna par moi-même et sûrement découvert plus tard qu'il est déjà inventé. Mais comme je l'ai lu partout le point clé à ce sujet est la sécurité, mais il y a un autre bon point: c'est un grand générateur de nombres pseudo-aléatoires à accès aléatoire pour ainsi dire (sous forme simplifiée). Donc le PRNG qui produit non seulement une très bonne séquence (je l'ai testé avec Ent et Die Hard) mais permet aussi d'accéder à n'importe quelle sous-séquence si vous connaissez le numéro d'étape. Donc est-il généralement acceptable d'utiliser Fortuna en tant que PRNG "à accès aléatoire" dans les applications de sécurité?

EDIT:

En d'autres termes, ce que je suggère est d'utiliser Fortuna PRNG comme tweak pour former un tweakable AES Cipher avec la capacité d'accès aléatoire. J'ai lu le travail de Liskov, Rivest et Wagner, mais je ne pouvais pas comprendre quelle était la principale différence entre un chiffre dans un mode de fonctionnement et un chiffre modifiable. Ils ont dit qu'ils ont suggéré d'amener cette approche de haut niveau à l'intérieur du chiffre lui-même, mais par exemple dans mon cas en xoring le texte brut avec le tweak, est-ce un tweak ou pas?

Answer 1

Je pense que vous voudrez peut-être chercher comment "tweakable block ciphers" fonctionne et voir comment le problème du cryptage de disque est résolu: Disk encryption theory. Le cryptage du disque entier est similaire à votre problème: le cryptage de chaque secteur doit être fait indépendamment (vous voulez un cryptage indépendant des données à différents décalages) et pourtant tout doit être sécurisé. Il y a beaucoup de travail à faire là-dessus. Wikipedia semble donner un bon aperçu.

EDITED pour ajouter: Re votre édition: Oui, vous essayez de faire un chiffrement de bloc modifiable à partir de AES en XORING le tweak avec le texte en clair. Plus concrètement, vous avez Enc (T, K, M) = AES (K, f (T) x ou M) où AES (K, ...) signifie chiffrement AES avec la clé K et f (T) est une fonction de le tweak (dans ton cas je suppose que c'est Fortuna). J'ai regardé brièvement le papier que vous avez mentionné et pour autant que je puisse voir, il est possible de montrer que cette méthode ne produit pas un chiffrement de bloc modifiable et sécurisé. L'idée (basée sur les définitions de la section 2 de l'article de Liskov, Rivest, Wagner) est la suivante. Nous avons accès à l'oracle de cryptage ou à une permutation aléatoire et nous voulons dire avec lequel nous interagissons. Nous pouvons définir le tweak T et le texte en clair M et nous récupérons le texte chiffré correspondant mais nous ne connaissons pas la clé qui est utilisée. Voici comment savoir si on utilise la construction AES (K, f (T) x ou M). Choisissez deux valeurs différentes T, T ', calculez f (T), f (T'). Choisissez n'importe quel message M puis calculez le deuxième message en tant que M '= M x ou f (T) x ou f (T'). Demandez maintenant à l'oracle de cryptage de crypter M en utilisant tweak T et M 'en utilisant tweak T'. Si nous traitons de la construction considérée, les sorties seront identiques. Si nous traitons des permutations aléatoires, les sorties seront presque certainement (avec probabilité 1-2^-128) différentes. C'est parce que les deux entrées aux cryptage AES seront les mêmes, ainsi les textes chiffrés seront également identiques. Ce ne serait pas le cas lorsqu'on utilise des permutations aléatoires, car la probabilité que les deux sorties soient identiques est de 2^-128. L'essentiel est que tweak xoring à l'entrée n'est probablement pas une méthode sécurisée.

Le document donne quelques exemples de ce qu'ils peuvent s'avérer être une construction sécurisée. Le plus simple semble être Enc (T, K, M) = AES (K, T x ou AES (K, M)). Vous avez besoin de deux chiffrements par bloc, mais ils prouvent la sécurité de cette construction. Ils mentionnent également des variantes plus rapides, mais elles nécessitent des familles de fonctions primitives supplémentaires (presque-xor-universal).

Answer 2

Même si je pense que votre approche est suffisamment sécurisée, je ne vois aucun avantage par rapport au CTR. Vous avez exactement le même problème, c'est-à-dire que vous n'injectez pas le vrai caractère aléatoire dans le texte chiffré. Le décalage est une entrée systématique connue. Même si c'est chiffré avec une clé, ce n'est toujours pas aléatoire.

Un autre problème est de savoir comment garder la FileUniqueKey sécurisée? Chiffré avec mot de passe? Un tas de problèmes sont présentés lorsque vous utilisez plusieurs clés.

Le mode compteur est une pratique courante pour crypter les fichiers à accès aléatoire. Même s'il comporte toutes sortes de vulnérabilités, tout est bien étudié, de sorte que le risque est mesurable.