Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra. # Directives pour le client de chiffrement C3R Le client de chiffrement C3R est un outil qui permet aux entreprises de rassembler des données sensibles afin de tirer de nouvelles informations de l'analyse des données. L'outil limite cryptographiquement ce qui peut être appris par n'importe quelle partie et AWS au cours du processus. Bien que cela soit d'une importance vitale, le processus de sécurisation cryptographique des données peut entraîner une surcharge importante en termes de ressources de calcul et de stockage. Il est donc important de comprendre les inconvénients liés à l'utilisation de chaque paramètre et de savoir comment optimiser les paramètres tout en maintenant les garanties cryptographiques souhaitées. Cette rubrique se concentre sur les implications en termes de performances des différents paramètres du client et des schémas de chiffrement C3R. Tous les paramètres de chiffrement du client de chiffrement C3R fournissent des garanties cryptographiques différentes. Les paramètres de collaboration sont les plus sécurisés par défaut. L'activation de fonctionnalités supplémentaires lors de la création d'une collaboration affaiblit les garanties de confidentialité, ce qui permet d'effectuer des activités telles que l'analyse des fréquences sur le texte chiffré. Pour plus d'informations sur la manière dont ces paramètres sont utilisés et sur leurs implications, consultez[Informatique cryptographique pour Clean Rooms](crypto-computing.md). **Topics** + [Implications sur les performances pour les types de colonnes](#performance-implications) + [Résolution des problèmes liés aux augmentations imprévues de la taille du texte chiffré](#troubleshooting-ciphertext-size) ## Implications sur les performances pour les types de colonnes C3R utilise trois types de colonnes : cleartextfingerprint, etsealed. Chacun de ces types de colonnes fournit des garanties cryptographiques différentes et a des utilisations prévues différentes. Dans les sections suivantes, les implications du type de colonne sur les performances sont abordées ainsi que l'impact de chaque paramètre sur les performances. **Topics** + [Cleartextcolonnes](#cleartext-columns) + [Fingerprintcolonnes](#guidelines-fingerprint-columns) + [Sealedcolonnes](#guidelines-sealed-columns) ### Cleartextcolonnes Cleartextles colonnes ne sont pas modifiées par rapport à leur format d'origine et ne sont en aucun cas traitées cryptographiquement. Ce type de colonne ne peut pas être configuré et n'a aucune incidence sur les performances de stockage ou de calcul. ### Fingerprintcolonnes Fingerprintles colonnes sont destinées à être utilisées pour joindre des données sur plusieurs tables. À cette fin, la taille du texte chiffré obtenu doit toujours être la même. Toutefois, ces colonnes sont affectées par les paramètres de collaboration. Fingerprintles colonnes peuvent avoir différents degrés d'impact sur la taille du fichier de sortie en fonction du cleartext contenu de l'entrée. **Topics** + [Frais généraux de base pour les fingerprint colonnes](#fingerprint-columns-base-overhead) + [Paramètres de collaboration pour les fingerprint colonnes](#fingerprint-columns-collab-settings) + [Exemple de données pour une fingerprint colonne](#collab-set-sample-data) + [fingerprintColonnes de dépannage](#fingerprint-columns-troubleshooting) #### Frais généraux de base pour les fingerprint colonnes Il existe un surcoût de base pour les fingerprint colonnes. Cette surcharge est constante et remplace la taille des cleartext octets. Les données des fingerprint colonnes sont traitées cryptographiquement par le biais d'une fonction HMAC (Hash Based Message Authentication Code), qui transforme les données en un code d'authentification de message (MAC) de 32 octets. Ces données sont ensuite traitées via un encodeur base64, ce qui ajoute environ 33 % à la taille des octets. Il est précédé d'une désignation C3R à 8 octets pour désigner le type de colonne à laquelle appartiennent les données et la version du client qui les a produites. Le résultat final est de 52 octets. Ce résultat est ensuite multiplié par le nombre de lignes pour obtenir le surcoût total de base (utilisez le nombre total de `null` valeurs non égales s'il `preserveNulls` est défini sur true). L'image suivante montre comment *`BASE_OVERHEAD = `*`C3R_DESIGNATION + `*`(MAC * 1.33)`*** ![\[La surcharge de base de 52 octets pour une fingerprint colonne.\]](http://docs.aws.amazon.com/fr_fr/clean-rooms/latest/userguide/images/base-overhead-fingerprint.PNG) Le texte chiffré de sortie dans les fingerprint colonnes sera toujours de 52 octets. Cela peut entraîner une diminution significative de la capacité de stockage si les cleartext données d'entrée dépassent en moyenne plus de 52 octets (par exemple, les adresses postales complètes). Cela peut représenter une augmentation significative du stockage si les cleartext données d'entrée sont en moyenne inférieures à 52 octets (par exemple, l'âge du client). #### Paramètres de collaboration pour les fingerprint colonnes ##### Paramètre `preserveNulls` Lorsque le paramètre au niveau de la collaboration `preserveNulls` est `false` (par défaut), chaque `null` valeur est remplacée par 32 octets uniques et aléatoires et traitée comme si ce n'était pas le cas. `null` Le résultat est que chaque `null` valeur est désormais de 52 octets. Cela peut ajouter des exigences de stockage importantes pour les tables contenant très peu de données par rapport à ce paramètre `true` et à ce que `null` les valeurs sont transmises sous forme `null` de. Si vous n'avez pas besoin des garanties de confidentialité de ce paramètre et que vous préférez conserver `null` les valeurs de vos ensembles de données, activez le `preserveNulls` paramètre au moment de la création de la collaboration. Le `preserveNulls` paramètre ne peut pas être modifié une fois la collaboration créée. #### Exemple de données pour une fingerprint colonne Voici un exemple de jeu de données d'entrée et de sortie pour une fingerprint colonne avec des paramètres à reproduire. D'autres paramètres de collaboration n'ont `allowDuplicates` pas d'impact sur les résultats et peuvent être définis au fur `true` et à mesure que `allowCleartext` `false` vous essayez de reproduire localement. **Exemple de secret partagé** : `wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY` **Exemple d'identifiant de collaboration** : `a1b2c3d4-5678-90ab-cdef-EXAMPLE11111` **allowJoinsOnColumnsWithDifferentNames**: `True` ce paramètre n'a aucune incidence sur les performances ou les exigences de stockage. Toutefois, ce paramètre rend le choix du nom de colonne non pertinent lors de la reproduction des valeurs indiquées dans les tableaux suivants. **Exemple 1** | | | | --- |--- | | Input | null | | preserveNulls | TRUE | | Output | null | | Déterministe | Yes | | Octets d'entrée | 0 | | Octets de sortie | 0 | **Exemple 2** | | | | --- |--- | | Input | null | | preserveNulls | FALSE | | Output | 01:hmac:3lkFjthvV3IUu6mMvFc1a\$1XAHwgw/ElmOq4p3Yg25kk= | | Déterministe | No | | Octets d'entrée | 0 | | Octets de sortie | 52 | **Exemple 3** | | | | --- |--- | | Input | empty string | | preserveNulls | - | | Output | 01:hmac:oKTgi3Gba\$1eUb3JteSz2EMgXUkF1WgM77UP0Ydw5kPQ= | | Déterministe | Yes | | Octets d'entrée | 0 | | Octets de sortie | 52 | **Exemple 4** | | | | --- |--- | | Input | abcdefghijklmnopqrstuvwxyz | | preserveNulls | - | | Output | 01:hmac:kU/IqwG7FMmzzshr0B9scomE0UJUEE7j9keTctplGww= | | Déterministe | Yes | | Octets d'entrée | 26 | | Octets de sortie | 52 | **Exemple 5** | | | | --- |--- | | Input | abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789 | | preserveNulls | - | | Output | 01:hmac:ks3htnQbw2vdhCRFF6JNzW5LMndJaHG57uvE26mBtSs= | | Déterministe | Yes | | Octets d'entrée | 62 | | Octets de sortie | 52 | #### fingerprintColonnes de dépannage **Pourquoi le texte chiffré de mes fingerprint colonnes est-il plusieurs fois supérieur à la taille du texte cleartext qui y est inscrit ?** Le texte chiffré d'une fingerprint colonne a toujours une longueur de 52 octets. Si vos données d'entrée étaient petites (par exemple, l'âge des clients), elles indiqueront une augmentation significative de leur taille. Cela peut également se produire si le `preserveNulls` paramètre est réglé sur`false`. **Pourquoi le texte chiffré de mes fingerprint colonnes est-il plusieurs fois plus petit que la taille du texte cleartext qui y figure ?** Le texte chiffré d'une fingerprint colonne a toujours une longueur de 52 octets. Si vos données d'entrée sont volumineuses (par exemple, les adresses complètes des clients), leur taille diminuera considérablement. **Comment savoir si j'ai besoin des garanties cryptographiques fournies par `preserveNulls` ?** Malheureusement, la réponse est que cela dépend. Au minimum, [Paramètres de calcul cryptographique](crypto-computing-parameters.md) il convient de vérifier la manière dont le `preserveNulls` paramètre protège vos données. Cependant, nous vous recommandons de faire référence aux exigences de traitement des données de votre organisation et à tout contrat applicable à la collaboration correspondante. **Pourquoi dois-je supporter la surcharge de base64 ?** Pour garantir la compatibilité avec les formats de fichiers tabulaires tels que CSV, le codage base64 est nécessaire. Bien que certains formats de fichier Parquet puissent prendre en charge les représentations binaires des données, il est important que tous les participants à une collaboration représentent les données de la même manière afin de garantir des résultats de requête corrects. ### Sealedcolonnes Sealedles colonnes sont destinées à être utilisées pour transférer des données entre les membres d'une collaboration. Le texte chiffré de ces colonnes n'est pas déterministe et a un impact significatif sur les performances et le stockage en fonction de la configuration des colonnes. Ces colonnes peuvent être configurées individuellement et ont souvent le plus grand impact sur les performances du client de chiffrement C3R et sur la taille du fichier de sortie qui en résulte. **Topics** + [Frais généraux de base pour les sealed colonnes](#sealed-columns-base-overhead) + [Paramètres de collaboration pour les sealed colonnes](#sealed-columns-collab-settings) + [sealedColonnes des paramètres du schéma : types de rembourrage](#sealed-collab-pad-type) + [Exemple de données pour une sealed colonne](#sealed-collab-sample-data) + [sealedColonnes de dépannage](#troubleshooting-sealed-columns) #### Frais généraux de base pour les sealed colonnes Il existe un surcoût de base pour les sealed colonnes. Cette surcharge est constante et s'ajoute à la taille des octets cleartext et de remplissage (le cas échéant). Avant tout chiffrement, les données des sealed colonnes sont précédées d'un caractère de 1 octet désignant le type de données contenues. Si le rembourrage est sélectionné, les données sont ensuite complétées et ajoutées avec 2 octets indiquant la taille du pad. Une fois ces octets ajoutés, les données sont traitées cryptographiquement à l'aide d'AES-GCM et stockées avec les IV (12 octets), nonce (32 octets) et Auth Tag (16 octets). Ces données sont ensuite traitées via un encodeur base64, ce qui ajoute environ 33 % à la taille des octets. Les données sont précédées d'une désignation C3R à 7 octets pour indiquer le type de colonne auquel elles appartiennent et la version du client utilisée pour les produire. Le résultat est un surdébit de base final de 91 octets. Ce résultat peut ensuite être multiplié par le nombre de lignes pour obtenir le surcoût total de base (utilisez le nombre total de valeurs non nulles s'il `preserveNulls` est défini sur true). L'image suivante montre comment *`BASE_OVERHEAD = C3R_DESIGNATION + ((NONCE + IV + DATA_TYPE + PAD_SIZE + AUTH_TAG) * 1.33)`* ![\[La surcharge de base de 91 octets pour une sealed colonne.\]](http://docs.aws.amazon.com/fr_fr/clean-rooms/latest/userguide/images/base-overhead-sealed.PNG) #### Paramètres de collaboration pour les sealed colonnes ##### Paramètre `preserveNulls` Lorsque le paramètre au niveau de la collaboration `preserveNulls` est `false` (par défaut), chaque `null` valeur est unique, aléatoire de 32 octets et traitée comme si ce n'était pas le cas. `null` Le résultat est que chaque `null` valeur est désormais de 91 octets (plus si elle est complétée). Cela peut ajouter des exigences de stockage importantes pour les tables contenant très peu de données par rapport à ce paramètre `true` et à ce que `null` les valeurs sont transmises sous forme `null` de. Si vous n'avez pas besoin des garanties de confidentialité de ce paramètre et que vous préférez conserver `null` les valeurs de vos ensembles de données, activez le `preserveNulls` paramètre au moment de la création de la collaboration. Le `preserveNulls` paramètre ne peut pas être modifié une fois la collaboration créée. #### sealedColonnes des paramètres du schéma : types de rembourrage **Topics** + [Type de pad `none`](#pad-type-none) + [Type de pad `fixed`](#pad-type-fixed) + [Type de pad `max`](#pad-type-max) ##### Type de pad `none` La sélection d'un type de pad `none` n'ajoute aucun rembourrage à la surcharge de base décrite précédemment cleartext et n'ajoute aucune surcharge supplémentaire à la surcharge de base décrite précédemment. L'absence de rembourrage permet d'obtenir la taille de sortie la plus économe en espace. Cependant, il n'offre pas les mêmes garanties de confidentialité que les types de rembourrage `fixed` et de `max` rembourrage. Cela est dû au fait que la taille du sous-jacent cleartext est perceptible à partir de la taille du texte chiffré. ##### Type de pad `fixed` La sélection d'un type de pad `fixed` est une mesure de protection de la vie privée qui permet de masquer la longueur des données contenues dans une colonne. Cela se fait en complétant le tout dans le champ cleartext fourni `pad_length` avant qu'il ne soit crypté. Toute donnée dépassant cette taille entraîne l'échec du client de chiffrement C3R. Étant donné que le remplissage est ajouté cleartext avant d'être chiffré, AES-GCM dispose d'un mappage 1 à 1 entre les octets du texte chiffré. cleartext Le codage base64 ajoutera 33 %. La surcharge de stockage supplémentaire du rembourrage peut être calculée en soustrayant la longueur moyenne du de la valeur cleartext du `pad_length` et en la multipliant par 1,33. Le résultat est le surcoût moyen de remplissage par enregistrement. Ce résultat peut ensuite être multiplié par le nombre de lignes pour obtenir la surcharge de remplissage totale (utilisez le nombre total de `null` valeurs non égales si la valeur `preserveNulls` est définie sur`true`). `PADDING_OVERHEAD = (PAD_LENGTH - AVG_CLEARTEXT_LENGTH) * 1.33 * ROW_COUNT` Nous vous recommandons de sélectionner le minimum `pad_length` qui englobe la plus grande valeur d'une colonne. Par exemple, si la valeur la plus élevée est de 50 octets, une valeur `pad_length` de 50 est suffisante. Une valeur supérieure à cette valeur ne fera qu'augmenter la charge de stockage. Le rembourrage fixe n'entraîne aucune surcharge de calcul significative. ##### Type de pad `max` La sélection d'un type de pad `max` est une mesure de protection de la vie privée qui permet de masquer la longueur des données contenues dans une colonne. Cela se fait en ajoutant le tout cleartext à la plus grande valeur de la colonne, plus le montant supplémentaire, `pad_length` avant qu'il ne soit chiffré. En général, `max` le remplissage fournit les mêmes garanties que le remplissage `fixed` d'un seul ensemble de données, tout en permettant de ne pas connaître la plus grande cleartext valeur de la colonne. Cependant, le `max` remplissage peut ne pas fournir les mêmes garanties de confidentialité que le `fixed` remplissage entre les mises à jour, car la valeur la plus élevée des ensembles de données individuels peut être différente. Nous vous recommandons de sélectionner une valeur supplémentaire `pad_length` de 0 lorsque vous utilisez le `max` rembourrage. Cette longueur permet à toutes les valeurs d'avoir la même taille que la plus grande valeur de la colonne. Une valeur supérieure à cette valeur ne fera qu'augmenter la charge de stockage. Si la cleartext valeur la plus élevée est connue pour une colonne donnée, nous vous recommandons d'utiliser plutôt le type `fixed` pad. L'utilisation `fixed` du rembourrage assure la cohérence entre les ensembles de données mis à jour. L'`max`utilisation du remplissage permet de compléter chaque sous-ensemble de données à la valeur la plus élevée figurant dans le sous-ensemble. #### Exemple de données pour une sealed colonne Voici un exemple de jeu de données d'entrée et de sortie pour une sealed colonne avec des paramètres à reproduire. D'autres paramètres de collaboration tels que `allowCleartext``allowJoinsOnColumnsWithDifferentNames`, et `allowDuplicates` n'ont pas d'impact sur les résultats et peuvent être définis au fur `true` et à mesure que `false` vous essayez de reproduire localement. Bien qu'il s'agisse des paramètres de base à reproduire, la sealed colonne n'est pas déterministe et les valeurs changent à chaque fois. L'objectif est d'afficher les octets entrants par rapport aux octets sortants. Les `pad_length` valeurs d'exemple ont été choisies intentionnellement. Ils montrent que le `fixed` rembourrage donne les mêmes valeurs que le `max` rembourrage avec les `pad_length` paramètres minimaux recommandés ou lorsqu'un rembourrage supplémentaire est souhaité. **Exemple de secret partagé** : `wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY` **Exemple d'identifiant de collaboration** : `a1b2c3d4-5678-90ab-cdef-EXAMPLE11111` **Topics** + [Type de pad `none`](#sealed-pad-type-none) + [Type de tampon `fixed` (exemple 1)](#sealed-pad-type-fixed) + [Type de tampon `fixed` (exemple 2)](#sealed-pad-type-fixed-2) + [Type de tampon `max` (exemple 1)](#sealed-pad-type-max) + [Type de tampon `max` (exemple 2)](#sealed-pad-type-max-2) ##### Type de pad `none` **Exemple 1** | | | | --- |--- | | Input | null | | preserveNulls | TRUE | | Output | null | | Déterministe | Yes | | Octets d'entrée | 0 | | Octets de sortie | 0 | **Exemple 2** | | | | --- |--- | | Input | null | | preserveNulls | FALSE | | Output | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfssGSPbNIJfG3iXmu6cbCUrizuV | | Déterministe | No | | Octets d'entrée | 0 | | Octets de sortie | 91 | **Exemple 3** | | | | --- |--- | | Input | empty string | | preserveNulls | - | | Output | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfstGSPEM6qR8DWC2PB2GMlX41YK | | Déterministe | No | | Octets d'entrée | 0 | | Octets de sortie | 91 | **Exemple 4** | | | | --- |--- | | Input | abcdefghijklmnopqrstuvwxyz | | preserveNulls | - | | Output | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfsteEE1GKEPiRzyh0h7t6OmWMLTWCvO2ckr6pkx9sGL5VLDQeHzh6DmPpyWNuI= | | Déterministe | No | | Octets d'entrée | 26 | | Octets de sortie | 127 | **Exemple 5** | | | | --- |--- | | Input | abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789 | | preserveNulls | - | | Output | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfsteEE1GKEPiRzyh0h7t6OmWMLTWCvO2ckr6plwtH/8tRFnn2rF91bcB9G4\$1n8GiRfJNmqdP4/QOQ3cXb/pbvPcnnohrHIGSX54ua\$11/JfcVjc= | | Déterministe | No | | Octets d'entrée | 62 | | Octets de sortie | 175 | ##### Type de tampon `fixed` (exemple 1) Dans cet exemple, `pad_length` c'est 62 et la plus grande entrée est 62 octets. **Exemple 1** | | | | --- |--- | | Input | null | | preserveNulls | TRUE | | Output | null | | Déterministe | Yes | | Octets d'entrée | 0 | | Octets de sortie | 0 | **Exemple 2** | | | | --- |--- | | Input | null | | preserveNulls | FALSE | | Output | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfssGSNWfMRp7nSb7SMX2s3JKLOhK1\$17r75Tk\$1Mx9jy48Fcg1yOPvBqRSZ7oqy1V3UKfYTLEZb/hCz7oaIneVsrcoNpATs0GzbnLkor4L\$1/aSuA= | | Déterministe | No | | Octets d'entrée | 0 | | Octets de sortie | 175 | **Exemple 3** | | | | --- |--- | | Input | empty string | | preserveNulls | - | | Output | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfstGSNWfMRp7nSb7SMX2s3JKLOhK1\$17r75Tk\$1Mx9jy48Fcg1yOPvBqRSZ7oqy1V3UKfYTLEZb/hCz7oaIneVsrcoLB53l07VZpA6OwkuXu29CA= | | Déterministe | No | | Octets d'entrée | 0 | | Octets de sortie | 175 | **Exemple 4** | | | | --- |--- | | Input | abcdefghijklmnopqrstuvwxyz | | preserveNulls | - | | Output | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfsteEE1GKEPiRzyh0h7t6OmWMLTWCvO2ckr6pkx9jy48Fcg1yOPvBqRSZ7oqy1V3UKfYTLEZb/hCz7oaIneVsrcutBAcO\$1Mb9tuU2KIHH31AWg= | | Déterministe | No | | Octets d'entrée | 26 | | Octets de sortie | 175 | **Exemple 5** | | | | --- |--- | | Input | abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789 | | preserveNulls | - | | Output | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfsteEE1GKEPiRzyh0h7t6OmWMLTWCvO2ckr6plwtH/8tRFnn2rF91bcB9G4\$1n8GiRfJNmqdP4/QOQ3cXb/pbvPcnnohrHIGSX54ua\$11/JfcVjc= | | Déterministe | No | | Octets d'entrée | 62 | | Octets de sortie | 175 | ##### Type de tampon `fixed` (exemple 2) Dans cet exemple, `pad_length` c'est 162 et la plus grande entrée est 62 octets. **Exemple 1** | | | | --- |--- | | Input | null | | preserveNulls | TRUE | | Output | null | | Déterministe | Yes | | Octets d'entrée | 0 | | Octets de sortie | 0 | **Exemple 2** | | | | --- |--- | | Input | null | | preserveNulls | FALSE | | Output | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfssGSNWfMRp7nSb7SMX2s3JKLOhK1\$17r75Tk\$1Mx9jy48Fcg1yOPvBqRSZ7oqy1V3UKfYTLEZb/hCz7oaIneVsrcnkB0xbLWD7zNdAqQGR0rXoSESdW0I0vpNoGcBfv4cJbG0A3h1DvtkSSVc2B80OOGppzdDqhrUVN5wFNyn8vgfPMqDaeJk5bn\$18o4WtG/ClipNcjDXvXVtK4vfCohcCA6uwrmwv/xAySX\$1xcntotL703aBTBb | | Déterministe | No | | Octets d'entrée | 0 | | Octets de sortie | 307 | **Exemple 3** | | | | --- |--- | | Input | empty string | | preserveNulls | - | | Output | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfstGSNWfMRp7nSb7SMX2s3JKLOhK1\$17r75Tk\$1Mx9jy48Fcg1yOPvBqRSZ7oqy1V3UKfYTLEZb/hCz7oaIneVsrcnkB0xbLWD7zNdAqQGR0rXoSESdW0I0vpNoGcBfv4cJbG0A3h1DvtkSSVc2B80OOGppzdDqhrUVN5wFNyn8vgfPMqDaeJk5bn\$18o4WtG/ClipNcjDXvXVtK4vfCohcCA6uwrmwv84lVaT9Yd\$16oQx65/\$1gdVT | | Déterministe | No | | Octets d'entrée | 0 | | Octets de sortie | 307 | **Exemple 4** | | | | --- |--- | | Input | abcdefghijklmnopqrstuvwxyz | | preserveNulls | - | | Output | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfsteEE1GKEPiRzyh0h7t6OmWMLTWCvO2ckr6pkx9jy48Fcg1yOPvBqRSZ7oqy1V3UKfYTLEZb/hCz7oaIneVsrcnkB0xbLWD7zNdAqQGR0rXoSESdW0I0vpNoGcBfv4cJbG0A3h1DvtkSSVc2B80OOGppzdDqhrUVN5wFNyn8vgfPMqDaeJk5bn\$18o4WtG/ClipNcjDXvXVtK4vfCohcCA6uwrmwtX5Hnl\$1WyfO6ks3QMaRDGSf | | Déterministe | No | | Octets d'entrée | 26 | | Octets de sortie | 307 | **Exemple 5** | | | | --- |--- | | Input | abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789 | | preserveNulls | - | | Output | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfsteEE1GKEPiRzyh0h7t6OmWMLTWCvO2ckr6plwtH/8tRFnn2rF91bcB9G4\$1n8GiRfJNmqdP4/QOQ3cXb/pbvPcnkB0xbLWD7zNdAqQGR0rXoSESdW0I0vpNoGcBfv4cJbG0A3h1DvtkSSVc2B80OOGppzdDqhrUVN5wFNyn8vgfPMqDaeJk5bn\$18o4WtG/ClipNcjDXvXVtK4vfCohcCA6uwrmwjkJXQZOgPdeFX9Yr/8alV5i | | Déterministe | No | | Octets d'entrée | 62 | | Octets de sortie | 307 | ##### Type de tampon `max` (exemple 1) Dans cet exemple, la valeur `pad_length` est 0 et la plus grande entrée est de 62 octets. **Exemple 1** | | | | --- |--- | | Input | null | | preserveNulls | TRUE | | Output | null | | Déterministe | Yes | | Octets d'entrée | 0 | | Octets de sortie | 0 | **Exemple 2** | | | | --- |--- | | Input | null | | preserveNulls | FALSE | | Output | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfssGSNWfMRp7nSb7SMX2s3JKLOhK1\$17r75Tk\$1Mx9jy48Fcg1yOPvBqRSZ7oqy1V3UKfYTLEZb/hCz7oaIneVsrcoNpATs0GzbnLkor4L\$1/aSuA= | | Déterministe | No | | Octets d'entrée | 0 | | Octets de sortie | 175 | **Exemple 3** | | | | --- |--- | | Input | empty string | | preserveNulls | - | | Output | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfstGSNWfMRp7nSb7SMX2s3JKLOhK1\$17r75Tk\$1Mx9jy48Fcg1yOPvBqRSZ7oqy1V3UKfYTLEZb/hCz7oaIneVsrcoLB53l07VZpA6OwkuXu29CA= | | Déterministe | No | | Octets d'entrée | 0 | | Octets de sortie | 175 | **Exemple 4** | | | | --- |--- | | Input | abcdefghijklmnopqrstuvwxyz | | preserveNulls | - | | Output | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfsteEE1GKEPiRzyh0h7t6OmWMLTWCvO2ckr6pkx9jy48Fcg1yOPvBqRSZ7oqy1V3UKfYTLEZb/hCz7oaIneVsrcutBAcO\$1Mb9tuU2KIHH31AWg= | | Déterministe | No | | Octets d'entrée | 26 | | Octets de sortie | 175 | **Exemple 5** | | | | --- |--- | | Input | abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789 | | preserveNulls | - | | Output | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfsteEE1GKEPiRzyh0h7t6OmWMLTWCvO2ckr6plwtH/8tRFnn2rF91bcB9G4\$1n8GiRfJNmqdP4/QOQ3cXb/pbvPcnnohrHIGSX54ua\$11/JfcVjc= | | Déterministe | No | | Octets d'entrée | 62 | | Octets de sortie | 175 | ##### Type de tampon `max` (exemple 2) Dans cet exemple, `pad_length` c'est 100 et la plus grande entrée est 62 octets. **Exemple 1** | | | | --- |--- | | Input | null | | preserveNulls | TRUE | | Output | null | | Déterministe | Yes | | Octets d'entrée | 0 | | Octets de sortie | 0 | **Exemple 2** | | | | --- |--- | | Input | null | | preserveNulls | FALSE | | Output | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfssGSNWfMRp7nSb7SMX2s3JKLOhK1\$17r75Tk\$1Mx9jy48Fcg1yOPvBqRSZ7oqy1V3UKfYTLEZb/hCz7oaIneVsrcnkB0xbLWD7zNdAqQGR0rXoSESdW0I0vpNoGcBfv4cJbG0A3h1DvtkSSVc2B80OOGppzdDqhrUVN5wFNyn8vgfPMqDaeJk5bn\$18o4WtG/ClipNcjDXvXVtK4vfCohcCA6uwrmwv/xAySX\$1xcntotL703aBTBb | | Déterministe | No | | Octets d'entrée | 0 | | Octets de sortie | 307 | **Exemple 3** | | | | --- |--- | | Input | empty string | | preserveNulls | - | | Output | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfstGSNWfMRp7nSb7SMX2s3JKLOhK1\$17r75Tk\$1Mx9jy48Fcg1yOPvBqRSZ7oqy1V3UKfYTLEZb/hCz7oaIneVsrcnkB0xbLWD7zNdAqQGR0rXoSESdW0I0vpNoGcBfv4cJbG0A3h1DvtkSSVc2B80OOGppzdDqhrUVN5wFNyn8vgfPMqDaeJk5bn\$18o4WtG/ClipNcjDXvXVtK4vfCohcCA6uwrmwv84lVaT9Yd\$16oQx65/\$1gdVT | | Déterministe | No | | Octets d'entrée | 0 | | Octets de sortie | 307 | **Exemple 4** | | | | --- |--- | | Input | abcdefghijklmnopqrstuvwxyz | | preserveNulls | - | | Output | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfsteEE1GKEPiRzyh0h7t6OmWMLTWCvO2ckr6pkx9jy48Fcg1yOPvBqRSZ7oqy1V3UKfYTLEZb/hCz7oaIneVsrcnkB0xbLWD7zNdAqQGR0rXoSESdW0I0vpNoGcBfv4cJbG0A3h1DvtkSSVc2B80OOGppzdDqhrUVN5wFNyn8vgfPMqDaeJk5bn\$18o4WtG/ClipNcjDXvXVtK4vfCohcCA6uwrmwtX5Hnl\$1WyfO6ks3QMaRDGSf | | Déterministe | No | | Octets d'entrée | 26 | | Octets de sortie | 307 | **Exemple 5** | | | | --- |--- | | Input | abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789 | | preserveNulls | - | | Output | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfsteEE1GKEPiRzyh0h7t6OmWMLTWCvO2ckr6plwtH/8tRFnn2rF91bcB9G4\$1n8GiRfJNmqdP4/QOQ3cXb/pbvPcnkB0xbLWD7zNdAqQGR0rXoSESdW0I0vpNoGcBfv4cJbG0A3h1DvtkSSVc2B80OOGppzdDqhrUVN5wFNyn8vgfPMqDaeJk5bn\$18o4WtG/ClipNcjDXvXVtK4vfCohcCA6uwrmwjkJXQZOgPdeFX9Yr/8alV5i | | Déterministe | No | | Octets d'entrée | 62 | | Octets de sortie | 307 | #### sealedColonnes de dépannage **Pourquoi le texte chiffré de mes sealed colonnes est-il plusieurs fois supérieur à la taille du texte cleartext qui y est inscrit ?** Cela dépend de plusieurs facteurs. D'une part, le texte chiffré d'une Cleartext colonne a toujours une longueur d'au moins 91 octets. Si vos données d'entrée étaient petites (par exemple, l'âge des clients), elles indiqueront une augmentation significative de leur taille. Ensuite, si vous avez `preserveNulls` défini ce paramètre sur `false` et que vos données d'entrée contenaient un grand nombre de `null` valeurs, chacune de ces `null` valeurs aura été transformée en 91 octets de texte chiffré. Enfin, si vous utilisez le rembourrage, par définition, des octets sont ajoutés aux cleartext données avant qu'elles ne soient chiffrées. **La plupart de mes données dans une sealed colonne sont très petites et je dois utiliser le rembourrage. Puis-je simplement supprimer les grandes valeurs et les traiter séparément pour économiser de l'espace ?** Nous vous déconseillons de supprimer des valeurs importantes et de les traiter séparément. Cela modifie les garanties de confidentialité fournies par le client de chiffrement C3R. En tant que modèle de menace, supposons qu'un observateur puisse voir les deux ensembles de données chiffrés. Si l'observateur constate qu'une colonne d'un sous-ensemble de données est plus ou moins remplie qu'un autre sous-ensemble, il peut tirer des conclusions sur la taille des données de chaque sous-ensemble. Supposons, par exemple, qu'une `fullName` colonne soit complétée à un total de 40 octets dans un fichier et à 800 octets dans un autre fichier. Un observateur peut supposer qu'un ensemble de données contient le nom le plus long du monde (747 octets). **Dois-je fournir un rembourrage supplémentaire lorsque j'utilise ce type de `max` rembourrage ?** Non. Lorsque vous utilisez le `max` rembourrage, nous recommandons que le`pad_length`, également connu sous le nom de rembourrage supplémentaire *au-delà* de la plus grande valeur de la colonne, soit défini sur 0. **Puis-je simplement en choisir une grande `pad_length` lorsque j'utilise un `fixed` rembourrage pour ne pas me demander si la plus grande valeur convient ?** Oui, mais la grande longueur du pad est inefficace et utilise plus d'espace de stockage que nécessaire. Nous vous recommandons de vérifier la taille de la plus grande valeur et de la `pad_length` définir sur cette valeur. **Comment savoir si j'ai besoin des garanties cryptographiques fournies par `preserveNulls` ?** Malheureusement, la réponse est que cela dépend. Au minimum, [Informatique cryptographique pour Clean Rooms](crypto-computing.md) il convient de vérifier la manière dont le `preserveNulls` paramètre protège vos données. Cependant, nous vous recommandons de faire référence aux exigences de traitement des données de votre organisation et à tout contrat applicable à la collaboration correspondante. **Pourquoi dois-je supporter la surcharge de base64 ?** Pour garantir la compatibilité avec les formats de fichiers tabulaires tels que CSV, le codage base64 est nécessaire. Bien que certains formats de fichier Parquet puissent prendre en charge les représentations binaires des données, il est important que tous les participants à une collaboration représentent les données de la même manière afin de garantir des résultats de requête corrects. ## Résolution des problèmes liés aux augmentations imprévues de la taille du texte chiffré Supposons que vous ayez chiffré vos données et que la taille des données obtenues soit étonnamment importante. Les étapes suivantes peuvent vous aider à identifier l'endroit où l'augmentation de taille s'est produite et les mesures que vous pouvez prendre, le cas échéant. ### Identification de l'endroit où l'augmentation de taille s'est produite Avant de pouvoir déterminer pourquoi vos données chiffrées sont nettement plus volumineuses que vos cleartext données, vous devez d'abord identifier l'origine de l'augmentation de taille. Cleartextles colonnes peuvent être ignorées en toute sécurité car elles sont inchangées. Examinez le reste fingerprint des sealed colonnes et choisissez-en une qui semble significative. ### Identifier la raison pour laquelle l'augmentation de taille s'est produite Une fingerprint colonne ou une sealed colonne peut contribuer à l'augmentation de la taille. **Topics** + [L'augmentation de taille provient-elle d'une fingerprint colonne ?](#size-increase-from-fingerprint) + [L'augmentation de taille provient-elle d'une sealed colonne ?](#size-increase-from-sealed) #### L'augmentation de taille provient-elle d'une fingerprint colonne ? Si la colonne qui contribue le plus à l'augmentation du stockage est une fingerprint colonne, cela est probablement dû au fait que les cleartext données sont petites (par exemple, l'âge du client). Chaque fingerprint texte chiffré obtenu a une longueur de 52 octets. Malheureusement, rien ne peut être fait à ce sujet sur une column-by-column base solide. Pour plus d'informations, voir [Frais généraux de base pour les fingerprint colonnes](#fingerprint-columns-base-overhead) les détails de cette colonne, notamment son impact sur les exigences de stockage. L'autre cause possible de l'augmentation de la taille d'une fingerprint colonne est le paramètre de collaboration,`preserveNulls`. Si le paramètre de collaboration pour `preserveNulls` est désactivé (paramètre par défaut), toutes les `null` valeurs des fingerprint colonnes seront devenues 52 octets de texte chiffré. Rien ne peut être fait pour cela dans le cadre de la collaboration actuelle. Le `preserveNulls` paramètre est défini au moment de la création d'une collaboration et tous les collaborateurs doivent utiliser le même paramètre pour garantir des résultats de requête corrects. Pour plus d'informations sur ce `preserveNulls` paramètre et sur l'impact de son activation sur les garanties de confidentialité de vos données, consultez[Informatique cryptographique pour Clean Rooms](crypto-computing.md). #### L'augmentation de taille provient-elle d'une sealed colonne ? Si la colonne qui contribue le plus à l'augmentation du stockage est une sealed colonne, certains détails peuvent contribuer à l'augmentation de la taille. Si les cleartext données sont petites (par exemple, l'âge du client), chaque sealed texte chiffré obtenu a une longueur d'au moins 91 octets. Malheureusement, rien ne peut être fait à ce sujet. Pour plus d'informations, voir [Frais généraux de base pour les sealed colonnes](#sealed-columns-base-overhead) les détails de cette colonne, notamment son impact sur les exigences de stockage. La deuxième cause principale de l'augmentation du stockage dans les sealed colonnes est le rembourrage. Le remplissage ajoute des octets supplémentaires cleartext avant le chiffrement afin de masquer la taille des valeurs individuelles d'un ensemble de données. Nous vous recommandons de définir le rembourrage à la valeur minimale possible pour votre ensemble de données. Au minimum, le `pad_length` `fixed` remplissage doit être défini de manière à inclure la plus grande valeur possible dans la colonne. Tout paramètre supérieur n'ajoute aucune garantie de confidentialité supplémentaire. Par exemple, si vous savez que la plus grande valeur possible d'une colonne peut être de 50 octets, nous vous recommandons de la `pad_length` définir sur 50 octets. Toutefois, si la sealed colonne utilise un `max` remplissage, nous vous recommandons de définir la `pad_length` valeur sur 0 octet. Cela est dû au fait que le `max` rembourrage fait référence au rembourrage *supplémentaire* au-delà de la plus grande valeur de la colonne. La dernière cause possible de l'augmentation de la taille d'une sealed colonne est le paramètre de collaboration,`preserveNulls`. Si le paramètre de collaboration pour `preserveNulls` est désactivé (paramètre par défaut), toutes les `null` valeurs des sealed colonnes seront devenues 91 octets de texte chiffré. Rien ne peut être fait pour cela dans le cadre de la collaboration actuelle. Le `preserveNulls` paramètre est défini au moment de la création d'une collaboration, et tous les collaborateurs doivent utiliser le même paramètre pour garantir des résultats de requête corrects. Pour plus d'informations sur ce paramètre et sur l'impact de son activation sur les garanties de confidentialité de vos données, consultez[Informatique cryptographique pour Clean Rooms](crypto-computing.md).