fts encrypted
1.0.0
Remarque: le jeton fait référence au jeton lexical , pas à un jeton cryptographique . Par exemple, un tokenizer peut transformer «apprendre», «apprendre», «appris» tous dans le jeton «Learn».
Si vous n'avez pas besoin de cryptage, Tantivy est meilleur dans tous les sens.
Une démonstration de base GUI utilisant Dioxus et l'ensemble de messagerie ENRON est disponible sur mon github ici. Il s'agit principalement de montrer que la vitesse de recherche est décente pour le type d'ensembles de données observés stockés sur les applications côté client.
C'est toujours un travail en cours. Aucune garantie concernant cette bibliothèque ou ses dépendances, dans la mise en œuvre, conceptuellement ou autrement, ne sont faites. Aucun audit de sécurité n'a jamais été effectué. Utiliser à vos risques et périls.
Chaque mot-clé d'une recherche ou d'un index est tokenisé. Ce jeton et le nom de la table dans lequel il se produit, sont hachés avec Blake2B-128, puis cryptés avec AES-128-ECB avant d'être stockés ou utilisés pour les requêtes.
Encrypt(Hash(token + table_name))
Le mode ECB est utilisé pour le cryptage. La BCE fait que le texte en clair identique devient identique, mais ce n'est pas une préoccupation pour des valeurs uniques comme le hachage d'un jeton et un nom de table. Cela signifie que le même jeton aura un texte chiffré différent s'il se produit dans des tables distinctes.
Un ID de document est chiffré par AES-128-ECB. Ceci est ensuite associé à un compteur 32 bits.
Étant donné qu'un ID de document apparaît plusieurs fois et que le nombre d'ID de document est beaucoup plus petit que ce qui peut être énuméré avec 128 bits, les ID de document peuvent être compressés.
En supposant 1 000 jetons / documents uniques, le coût pour stocker les occurrences d'un jeton dans les documents est:
| Documents | Non optimisé | 32 bits |
|---|---|---|
| 1000 | 16 Mo | 4 Mo |
| 10k | 160 Mo | 40 Mo |
| 50k | 800 Mo | 200 Mo |
| 100k | 1,6 Go | 400 Mo |
| 250k | 4 Go | 1 Go |
| million | 16 GB | 4 Go |
| milliard | 16 To | 4 To |
La différenciation représente les valeurs dans une séquence comme la différence entre eux. Cela crée des valeurs qui peuvent être représentées avec moins de bits, ce qui permet un bitpacking plus serré.
La caisse de bitpacking est utilisée pour la différence et les blocs de bitpacking de 128 entiers.
La différenciation fonctionne mieux lorsque les valeurs sont triées, mais le maintien des valeurs triées et bitpaquées nécessiterait de réencoder toutes les valeurs lorsqu'une entrée hors ordre est ajoutée. L'utilisation d'une approche amortie avec une collection de valeurs hors ordre peut réduire le coût des changements en les amortissant.
| Numéro de couche | Schéma d'emballage | Tri | Difficulté |
|---|---|---|---|
| 0 | Aucun - 32 bits (<128 INTS) | Aucun | Non |
| 1+ | Bitpacker4x (128 INTS) | Couches Amoung mondialement supérieures à 0 | Oui |
Environ 9 000 à 10 000 e-mails d'Enron plus courts ont été compressés et la taille de DB FTS résultante était de 235 Mo en utilisant le codage 32 bits. L'utilisation de la différenciation amorti et du bitpacking en couches a changé cela à 21 Mo.
La suppression d'un fichier est ... coûteuse ... Amortisation Todo
Todo explore. Quelque chose comme Rocksdb MemTable ou Sled. Stockez les changements de mémoire, puis rincez toutes les 500 ms ou lorsque la limite de mémoire est atteinte.
Triez des mots par seau par les 3 ou 4 premiers caractères (pas tokenisés), compresse? et crypter. Bloquer le chiffre d'affaires avec quelque chose avec une diffusion comme CBC ou GCM (cryptage Authenicated). Cela signifierait que la saisie semi-automatique se déclencherait après 3 ou 4 caractères. C'est toujours à l'étape conceptuelle.
L'intégrité des données est facultative en hachant le fichier de la base de données à un temps proche et en stockant une version chiffrée du hachage.
Il n'y a pas de diffusion sur les ID de document chiffrés. L'ajout de diffusion nécessiterait un chiffre d'affaires des ID de document à l'aide d'un IV généré de manière aléatoire. Cela rendrait également la compression impossible. Le stockage de l'IV ajouterait 128 bits par jeton et paire de documents (pour AES CBC).
Ce qui suit est visible par un attaquant sans clé:
Dans le cas d'un index sur une liste de patients dans un cabinet d'un médecin, un attaquant sans clé pourrait voir le nombre de patients et une distribution de jetons utilisés dans les documents. Ils ne pouvaient voir aucun texte en clair, comme des noms ou d'autres identifiants, et ils ne pouvaient même pas voir le document de document d'aucun patient. Ils pourraient voir si deux patients partagent un jeton de recherche, mais rien sur lequel les patients ou les informations partagées.
Par exemple, si l'indice de recherche n'a été construit que sur des noms dans un pays avec des noms de famille communs, tels que le Vietnam, vous pouvez faire une analyse de fréquence et déterminer le nombre probable de patients atteints de nom de famille Nguyen (38% de la population du Vietnam). Cela s'appuie sur votre (distribution de noms de famille) préalable pour l'ensemble de données à portée de main. Il ne serait également efficace que par rapport aux noms communs, qui ne s'identifie pas et ne serait pas susceptible de distinguer en toute confiance les documents contenant même le second du troisième nom de famille le plus commun au Vietnam (TRAN à 11% et LE à 10%).
Une fois les informations supplémentaires ajoutées à l'indice de recherche, telles que l'âge, la ville natale, l'adresse, la description, etc., la capacité de procéder à l'analyse de fréquence disparaît pratiquement.
Une préoccupation peut être la non-représentation de stocker des ensembles de données uniques, où une analyse de fréquence d'un grand ensemble de données en texte clair connu pourrait être utilisée pour montrer qu'au-delà d'un doute raisonnable, un appareil donné avait indexé cet ensemble de données. Cela ne affecterait apparemment que les dissidents dans les pays autoritaires ou les criminels. Cela peut être atténué par le cryptage complet du disque lorsque l'appareil est désactivé.
Soit d1 un document avec un jeton t1 . Soit t2 un jeton dont le hachage entre en collision avec t1 et n'est pas un jeton du document d1 .
Les faux positifs, où des résultats supplémentaires non liés ont été inclus dans un résultat de recherche, peuvent se produire à d1 si la recherche contient t2 et non t1 .
Les faux négatifs, le cas échéant des résultats pertinents ont été omis d'un résultat de recherche, ne peut se produire que si l'un des jetons en collision a été supprimé pour un document. Cela entraînerait également que l'autre jeton soit "supprimé".
Les faux positifs ou négatifs ne s'appliquent qu'aux documents qui ont l'un des jetons en collision, lorsque l'autre jeton en collision est présent dans la requête de recherche. Cela rend les enjeux d'une telle collision très bas.
Le risque réel d'une collision est comiquement petit pour les hachages de 128 bits (voir le problème d'anniversaire sur Wikipedia).
Le cryptage 64 bits ne se traduit que quelques mégaoctets d'économies d'espace pour de très grands index. L'anglais a environ 1 000 000 de mots et moins de jetons. 64 millions de bits ne sont que 8 Mo. Étant donné les distributions de type de loi de puissance observées dans les langues, où la centaine supérieure des mots peut comprendre la moitié de la fréquence, les économies réelles seraient considérablement moindres.
