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

Question

Je construis fichier de chiffrement basé sur AES qui doivent pouvoir travailler en mode accès aléatoire (accesing une partie du fichier). AES en contre par exemple peut être utilisé, mais il est bien connu que nous avons besoin d'une séquence unique jamais utilisé deux fois. Est-il acceptable d'utiliser une PRNG simplifiée Fortuna dans ce cas (chiffrer un compteur avec une clé spécifique choisie au hasard unique au fichier particulier)? Sont dans cette approche là des points faibles?

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échiffrement 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: il est un grand pseudo générateur de nombres aléatoires accès aléatoire pour ainsi dire (sous forme simplifiée). Ainsi, le PRNG qui permettent non seulement produit une très bonne séquence (je l'ai testé avec Ent et Die Hard), mais aussi d'accéder à un sous-séquence si vous connaissez le numéro de l'étape. Alors, est-il généralement autorisé à utiliser Fortuna comme 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. Je lis le travail de Liskov, Rivest et Wagner, mais ne pouvait pas comprendre ce qui était la principale différence entre un algorithme de chiffrement dans un mode de fonctionnement et un chiffre tweakable. Ils ont dit qu'ils ont suggéré d'apporter cette approche de haut niveau à l'intérieur du chiffrement lui-même, mais par exemple dans mon cas XOR le texte brut avec le tweak, est-ce un tweak ou non?

Answer 1

Je pense que vous voudrez peut-être chercher comment « chiffrements par bloc tweakable » travail et un coup d'oeil sur la façon dont le problème de chiffrement du disque est résolu: théorie de chiffrement de disque . Chiffrement tout le disque est similaire à votre problème: le chiffrement de chaque secteur doit être fait indépendamment (vous voulez le cryptage indépendant des données à différents décalages) et pourtant tout cela doit être sécurisé. Il y a beaucoup de travail à ce sujet. Wikipedia semble donner un bon aperçu.

ÉDITÉ ajouter: Re votre edit: Oui, vous essayez de faire un chiffrement par bloc tweakable sur AES par XOR le tweak avec le texte en clair. Plus concrètement, vous avez Enc (T, K, M) = AES (K, f (T) XOR M) où AES (K, ...) des moyens de cryptage AES avec la clé K et f (T) est une fonction de le tweak (dans votre cas, je suppose que c'est Fortuna). J'ai eu un bref aperçu du document que vous avez mentionné et pour autant que je le vois, il est possible de montrer que cette méthode ne pas produire un chiffrement par bloc tweakable sécurisé. L'idée (basé sur les définitions de la section 2 de la Liskov, Rivest, papier Wagner) est le suivant. Nous avons accès à l'une ou l'autre oracle de chiffrement ou une permutation aléatoire et nous voulons dire que l'on nous interagissons avec. Nous pouvons régler le T tweak et le M et nous plaintext retourner le cryptogramme correspondant, mais nous ne savons pas la clé qui est utilisée. Voici comment déterminer si nous utilisons la construction AES (K, f (T) XOR M). Choix des deux valeurs différentes T, T 'calculer f (T), f (T'). Ramasser tout message M et calculer le deuxième message en tant que M '= M xor f (T) xor f (T'). Maintenant, demandez l'oracle pour chiffrer M encryptage en utilisant tweak T et M « en utilisant tweak T ». Si nous traitons la construction considérée, les sorties seront identiques. Si nous traitons les permutations aléatoires, les sorties seront presque certainement (avec une probabilité de 1-2 ^ -128) différent. C'est parce que les deux entrées aux chiffrements AES seront les mêmes, de sorte que les cryptogrammes seront également identiques. Ce ne serait pas le cas lorsque l'on utilise des permutations aléatoires, parce que la probabilité que les deux sorties sont identiques est 2 ^ -128. L'essentiel est que XOR tweak à l'entrée est probablement pas une méthode sécurisée.

Le document donne quelques exemples de ce qu'ils peuvent se révéler être une construction sûre. La plus simple semble être Enc (T, K, M) = AES (K, T xor AES (K, M)). Vous avez besoin de deux chiffrements par bloc, mais ils prouvez la sécurité de cette construction. Ils mentionnent également des variantes plus rapides, mais ils ont besoin (familles de fonctions presque XOR universel) primitives supplémentaires.

Answer 2

Même si je pense que votre approche est assez sûr, je ne vois aucun avantage sur CTR. Vous avez le même problème, que vous est n'injectez pas vrai hasard au cryptogramme. Le décalage est une entrée systématique connue. Même si elle est crypté avec une clé, il est toujours pas au hasard.

Une autre question est de savoir comment gardez-vous sécuriser le FileUniqueKey? Encryptée avec mot de passe? lorsque vous utilisez plusieurs clés sont mis en place un ensemble de problèmes tas.

Mode compteur est accepté pratique pour chiffrer les fichiers d'accès aléatoire. Même si elle a toutes sortes de vulnérabilités, il est tout bien étudié si le risque est mesurable.