Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés. # Directrices para el cliente de cifrado de C3R El cliente de cifrado de C3R es una herramienta que permite a las organizaciones recopilar datos confidenciales para obtener nueva información procesable a partir del análisis de datos. La herramienta limita criptográficamente lo que puede aprender cualquier parte y AWS en el proceso. Si bien esto es de vital importancia, el proceso de protección criptográfica de los datos puede suponer una sobrecarga considerable, tanto en términos de recursos de computación como de almacenamiento. Por lo tanto, es importante entender las ventajas y desventajas de usar cada ajuste y saber cómo optimizar la configuración sin dejar de mantener las garantías criptográficas deseadas. Este tema se centra en las implicaciones para el rendimiento de las diferentes configuraciones del cliente de cifrado de C3R y los esquemas. Todas las configuraciones de cifrado del cliente de cifrado de C3R ofrecen diferentes garantías criptográficas. De forma predeterminada, los ajustes más seguros son aquellos en el nivel de la colaboración. Al habilitar funciones adicionales al crear una colaboración, se debilitan las garantías de privacidad, ya que se permite realizar actividades como análisis de frecuencia en el texto cifrado. Para obtener más información sobre cómo se utilizan estas configuraciones y cuáles son sus implicaciones, consulte [Computación criptográfica para Clean Rooms](crypto-computing.md). **Topics** + [Implicaciones en el rendimiento de los tipos de columnas](#performance-implications) + [Solución de problemas relacionados con el aumento imprevisto de tamaño del texto cifrado](#troubleshooting-ciphertext-size) ## Implicaciones en el rendimiento de los tipos de columnas C3R utiliza tres tipos de columnas: cleartext, fingerprint y sealed. Cada uno de estos tipos de columnas proporciona diferentes garantías criptográficas y tiene distintos usos previstos. En las siguientes secciones se analizan las implicaciones de rendimiento del tipo de columna y el impacto de cada ajuste en el rendimiento. **Topics** + [Columnas Cleartext](#cleartext-columns) + [Columnas Fingerprint](#guidelines-fingerprint-columns) + [Columnas Sealed](#guidelines-sealed-columns) ### Columnas Cleartext Las columnas Cleartext no se modifican con respecto a su formato original ni se procesan criptográficamente en modo alguno. Este tipo de columna no se puede configurar y no afecta al rendimiento en términos de almacenamiento o de computación. ### Columnas Fingerprint Las columnas Fingerprint están previstas para utilizarse para combinar datos de varias tablas. Para ello, el tamaño del texto cifrado resultante debe ser siempre el mismo. Sin embargo, estas columnas se ven afectadas por los ajustes en el nivel de la colaboración. Las columnas Fingerprint pueden incidir en distinto grado en el tamaño del archivo de salida en función del cleartext contenido en la entrada. **Topics** + [Sobrecarga de base para las columnas fingerprint](#fingerprint-columns-base-overhead) + [Ajustes de colaboración para las columnas fingerprint](#fingerprint-columns-collab-settings) + [Datos de ejemplo para una columna fingerprint](#collab-set-sample-data) + [Solución de problemas con columnas fingerprint](#fingerprint-columns-troubleshooting) #### Sobrecarga de base para las columnas fingerprint Existe una sobrecarga de base para las columnas fingerprint. Esta sobrecarga es constante y sustituye al tamaño de los bytes de cleartext. Los datos de las columnas fingerprint se procesan criptográficamente mediante una función de código de autenticación de mensajes basado en hash (HMAC), que convierte los datos en un código de autenticación de mensajes (MAC) de 32 bytes. A continuación, estos datos se procesan a través de un codificador base64, lo que aumenta el tamaño del byte aproximadamente un 33 por ciento. Va precedido de una designación C3R de 8 bytes para designar el tipo de columna a la que pertenecen los datos y la versión de cliente que los generó. El resultado final es de 52 bytes. Este resultado se multiplica entonces por el número de filas para obtener la sobrecarga de base total (utilice el número total de valores distintos de `null` si `preserveNulls` se establece en true). En la siguiente imagen se muestra cómo * `BASE_OVERHEAD = ` ** `C3R_DESIGNATION + ` ** `(MAC * 1.33)` * ![\[La sobrecarga de base de 52 bytes de una columna fingerprint.\]](http://docs.aws.amazon.com/es_es/clean-rooms/latest/userguide/images/base-overhead-fingerprint.PNG) El texto cifrado de salida de las columnas fingerprint siempre será de 52 bytes. Esto puede suponer una disminución significativa del almacenamiento si el promedio de los datos de cleartext de entrada es superior a 52 bytes (por ejemplo, las direcciones postales completas). Esto puede suponer un aumento significativo del almacenamiento si el promedio de los datos de cleartext de entrada es inferior a 52 bytes (por ejemplo, las edades de los clientes). #### Ajustes de colaboración para las columnas fingerprint ##### Ajuste `preserveNulls` Cuando el ajuste de nivel de la colaboración `preserveNulls` es `false` (predeterminado), cada valor `null` se sustituye por 32 bytes únicos y aleatorios y se procesa como si no fuera `null`. El resultado es que cada valor `null` tiene ahora 52 bytes. Esto puede añadir requisitos de almacenamiento importantes para las tablas que contienen datos muy dispersos en comparación con cuando este ajuste es `true` y los valores `null` se transfieren como `null`. Si no necesita las garantías de privacidad de este ajuste y prefiere retener los valores `null` de sus conjuntos de datos, habilite el ajuste `preserveNulls` en el momento de crear la colaboración. El ajuste `preserveNulls` no se puede cambiar una vez creada la colaboración. #### Datos de ejemplo para una columna fingerprint El siguiente es un ejemplo de conjunto de datos de entrada y salida para una columna fingerprint con los ajustes de configuración que se deben reproducir. Otros ajustes a nivel de la colaboración, como `allowCleartext` y `allowDuplicates`, no afectan a los resultados y se pueden configurar como `true` o `false` si se intenta reproducirlos localmente. **Secreto compartido de ejemplo**: `wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY` **ID de colaboración de ejemplo**: `a1b2c3d4-5678-90ab-cdef-EXAMPLE11111` **allowJoinsOnColumnsWithDifferentNames**: `True` Este ajuste no afecta al rendimiento ni a los requisitos de almacenamiento. Sin embargo, este ajuste hace que la elección del nombre de la columna sea irrelevante al reproducir los valores que se muestran en las siguientes tablas. **Ejemplo 1** | | | | --- |--- | | Input | null | | preserveNulls | TRUE | | Salida | null | | Determinista | Yes | | Bytes de entrada | 0 | | Bytes de salida | 0 | **Ejemplo 2** | | | | --- |--- | | Entrada | null | | preserveNulls | FALSE | | Salida | 01:hmac:3lkFjthvV3IUu6mMvFc1a\$1XAHwgw/ElmOq4p3Yg25kk= | | Determinista | No | | Bytes de entrada | 0 | | Bytes de salida | 52 | **Ejemplo 3** | | | | --- |--- | | Input | empty string | | preserveNulls | - | | Salida | 01:hmac:oKTgi3Gba\$1eUb3JteSz2EMgXUkF1WgM77UP0Ydw5kPQ= | | Determinista | Yes | | Bytes de entrada | 0 | | Bytes de salida | 52 | **Ejemplo 4** | | | | --- |--- | | Input | abcdefghijklmnopqrstuvwxyz | | preserveNulls | - | | Salida | 01:hmac:kU/IqwG7FMmzzshr0B9scomE0UJUEE7j9keTctplGww= | | Determinista | Yes | | Bytes de entrada | 26 | | Bytes de salida | 52 | **Ejemplo 5** | | | | --- |--- | | Input | abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789 | | preserveNulls | - | | Salida | 01:hmac:ks3htnQbw2vdhCRFF6JNzW5LMndJaHG57uvE26mBtSs= | | Determinista | Yes | | Bytes de entrada | 62 | | Bytes de salida | 52 | #### Solución de problemas con columnas fingerprint **¿Por qué el texto cifrado de mis columnas fingerprint es varias veces mayor que el tamaño del cleartext que figuraba en ellas?** El texto cifrado de una columna de fingerprint tiene siempre una longitud de 52 bytes. Si los datos de entrada eran pequeños (por ejemplo, las edades de los clientes), mostrarán un aumento considerable de tamaño. Esto también puede ocurrir si el ajuste `preserveNulls` se define como `false`. **¿Por qué el texto cifrado de mis columnas de fingerprint es varias veces más pequeño que el cleartext que contiene?** El texto cifrado de una columna de fingerprint tiene siempre una longitud de 52 bytes. Si los datos de entrada eran grandes (por ejemplo, las direcciones completas de los clientes), su tamaño se reducirá considerablemente. **¿Cómo sé si necesito las garantías criptográficas que ofrece `preserveNulls`?** Lamentablemente, la respuesta es que depende. Como mínimo, se deben revisar los [Parámetros de computación criptográfica](crypto-computing-parameters.md) en cuanto a la forma en que el ajuste `preserveNulls` protege sus datos. No obstante, le recomendamos que consulte los requisitos de manejo de datos de su organización y cualquier contrato aplicable a la colaboración correspondiente. **¿Por qué tengo que incurrir en la sobrecarga de base64?** Para permitir la compatibilidad con los formatos de archivo tabulares como CSV, es necesaria la codificación base64. Si bien algunos formatos de archivo como Parquet podrían admitir representaciones binarias de datos, es importante que todos los participantes en una colaboración representen los datos de la misma manera para garantizar que los resultados de las consultas sean correctos. ### Columnas Sealed Las columnas Sealed están diseñadas para utilizarse para transferir datos entre los miembros de una colaboración. El texto cifrado de estas columnas no es determinista y tiene un impacto significativo tanto en el rendimiento como en el almacenamiento en función de cómo se configuren las columnas. Estas columnas se pueden configurar de forma individual y, a menudo, son las que más influyen en el rendimiento del cliente de cifrado de C3R y en el tamaño del archivo de salida resultante. **Topics** + [Sobrecarga de base para las columnas sealed](#sealed-columns-base-overhead) + [Ajustes de colaboración para las columnas sealed](#sealed-columns-collab-settings) + [Columnas sealed de configuración de esquema: tipos de relleno](#sealed-collab-pad-type) + [Datos de ejemplo para una columna sealed](#sealed-collab-sample-data) + [Solución de problemas con columnas sealed](#troubleshooting-sealed-columns) #### Sobrecarga de base para las columnas sealed Existe una sobrecarga de base para las columnas sealed. Esta sobrecarga es constante y se suma al tamaño de los bytes de cleartext y de relleno (si los hubiera). Antes de cualquier cifrado, a los datos de las columnas sealed se les añade como prefijo un carácter de 1 byte que designa el tipo de datos que contienen. Si se selecciona el relleno, los datos se rellenan y se añaden 2 bytes que indican el tamaño del relleno. Tras añadir estos bytes, los datos se procesan criptográficamente mediante AES-GCM y se almacenan con IV (12 bytes), nonce (32 bytes) y Auth Tag (16 bytes). A continuación, estos datos se procesan a través de un codificador base64, lo que aumenta el tamaño del byte aproximadamente un 33 por ciento. Los datos van precedidos de una designación C3R de 7 bytes para indicar el tipo de columna a la que pertenecen los datos y la versión de cliente utilizada para generarlos. El resultado es una sobrecarga de base final de 91 bytes. A continuación, este resultado se puede multiplicar por el número de filas para obtener la sobrecarga de base total (utilice el número total de valores no nulos si `preserveNulls` está definido como true). En la siguiente imagen se muestra cómo * `BASE_OVERHEAD = C3R_DESIGNATION + ((NONCE + IV + DATA_TYPE + PAD_SIZE + AUTH_TAG) * 1.33)` * ![\[La sobrecarga de base de 91 bytes de una columna sealed.\]](http://docs.aws.amazon.com/es_es/clean-rooms/latest/userguide/images/base-overhead-sealed.PNG) #### Ajustes de colaboración para las columnas sealed ##### Ajuste `preserveNulls` Cuando el ajuste en el nivel de la colaboración `preserveNulls` es `false` (predeterminado), cada valor `null` es único, aleatorio de 32 bytes, y se procesa como si no fuera `null`. El resultado es que cada valor `null` tiene ahora 91 bytes (más si se rellena). Esto puede añadir requisitos de almacenamiento importantes para las tablas que contienen datos muy dispersos en comparación con cuando este ajuste es `true` y los valores `null` se transfieren como `null`. Si no necesita las garantías de privacidad de este ajuste y prefiere retener los valores `null` de sus conjuntos de datos, habilite el ajuste `preserveNulls` en el momento de crear la colaboración. El ajuste `preserveNulls` no se puede cambiar una vez creada la colaboración. #### Columnas sealed de configuración de esquema: tipos de relleno **Topics** + [Tipo de relleno `none`](#pad-type-none) + [Tipo de relleno `fixed`](#pad-type-fixed) + [Tipo de relleno `max`](#pad-type-max) ##### Tipo de relleno `none` Seleccionar el tipo de relleno `none` no añade ningún relleno al cleartext ni añade ninguna sobrecarga adicional a la sobrecarga de base descrita anteriormente. La ausencia de relleno se traduce en el tamaño de salida más eficiente en términos de espacio. Sin embargo, no proporciona las mismas garantías de privacidad que los tipos de relleno `fixed` y `max`. Esto se debe a que el tamaño del cleartext subyacente es discernible a partir del tamaño del texto cifrado. ##### Tipo de relleno `fixed` Seleccionar un tipo de relleno `fixed` es una medida que salvaguarda la privacidad para ocultar la longitud de los datos contenidos en una columna. Esto se hace rellenando todo el cleartext hasta la `pad_length` antes del cifrado. Cualquier dato que supere ese tamaño provoca un fallo del cliente de cifrado de C3R. Dado que el relleno se añade al cleartext antes de cifrarlo, AES-GCM utiliza un mapeo 1 a 1 de cleartext a texto cifrado en bytes. La codificación base64 añadirá un 33 por ciento. La sobrecarga de almacenamiento adicional del relleno se puede calcular restando la longitud media del cleartext del valor de `pad_length` y multiplicándola por 1,33. El resultado es la sobrecarga promedio de relleno por registro. Este resultado puede entonces multiplicarse por el número de filas para obtener la sobrecarga de relleno total (utilice el número total de valores no `null` si `preserveNulls` está definido como `true`). `PADDING_OVERHEAD = (PAD_LENGTH - AVG_CLEARTEXT_LENGTH) * 1.33 * ROW_COUNT` Se recomienda seleccionar la `pad_length` mínima que abarque el mayor valor de columna. Por ejemplo, si el mayor valor es de 50 bytes, basta con una `pad_length` de 50. Un valor superior a ese solo añadirá sobrecarga de almacenamiento adicional. El relleno fijo no añade ninguna sobrecarga de computación significativa. ##### Tipo de relleno `max` Seleccionar un tipo de relleno `max` es una medida que salvaguarda la privacidad para ocultar la longitud de los datos contenidos en una columna. Esto se hace rellenando todos los cleartext hasta el valor más alto de la columna, más la `pad_length` adicional, antes de cifrarla. Por lo general, el relleno `max` proporciona las mismas garantías que el relleno `fixed` para un único conjunto de datos, al tiempo que permite no conocer el valor de cleartext más alto de la columna. Sin embargo, es posible que el relleno `max` no ofrezca las mismas garantías de privacidad que el relleno `fixed` en todas las actualizaciones, ya que el valor más alto de cada conjuntos de datos podría variar. Se recomienda seleccionar una `pad_length` adicional de 0 al usar el relleno `max`. Esta longitud rellena todos los valores para que tengan el mismo tamaño que el mayor valor de la columna. Un valor superior a ese solo añadirá sobrecarga de almacenamiento adicional. Si conoce el valor de cleartext más alto de una columna determinada, le recomendamos que utilice el tipo de relleno `fixed` en su lugar. El uso del relleno `fixed` crea coherencia entre los conjuntos de datos actualizados. El uso del relleno `max` hace que cada subconjunto de datos se rellene hasta el mayor valor presente en el subconjunto. #### Datos de ejemplo para una columna sealed El siguiente es un ejemplo de conjunto de datos de entrada y salida para una columna sealed con los ajustes de configuración que se deben reproducir. Otros ajustes en el nivel de la colaboración, `allowCleartext`, `allowJoinsOnColumnsWithDifferentNames` y `allowDuplicates`, no afectan a los resultados y se pueden definir como `true` o `false` si se intentan reproducir localmente. Aunque estos son los ajustes básicos que se deben reproducir, la columna sealed no es determinista y los valores cambiarán de una vez a otra. El objetivo es mostrar los bytes de entrada en comparación con los bytes de salida. Los valores `pad_length` de ejemplo se han elegido de forma intencionada. Muestran que el relleno `fixed` da como resultado los mismos valores que el relleno `max` con los ajustes de `pad_length` mínima recomendada o cuando se desea un relleno adicional. **Secreto compartido de ejemplo**: `wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY` **ID de colaboración de ejemplo**: `a1b2c3d4-5678-90ab-cdef-EXAMPLE11111` **Topics** + [Tipo de relleno `none`](#sealed-pad-type-none) + [Tipo de relleno `fixed` (ejemplo 1)](#sealed-pad-type-fixed) + [Tipo de relleno `fixed` (ejemplo 2)](#sealed-pad-type-fixed-2) + [Tipo de relleno `max` (ejemplo 1)](#sealed-pad-type-max) + [Tipo de relleno `max` (ejemplo 2)](#sealed-pad-type-max-2) ##### Tipo de relleno `none` **Ejemplo 1** | | | | --- |--- | | Input | null | | preserveNulls | TRUE | | Salida | null | | Determinista | Yes | | Bytes de entrada | 0 | | Bytes de salida | 0 | **Ejemplo 2** | | | | --- |--- | | Entrada | null | | preserveNulls | FALSE | | Salida | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfssGSPbNIJfG3iXmu6cbCUrizuV | | Determinista | No | | Bytes de entrada | 0 | | Bytes de salida | 91 | **Ejemplo 3** | | | | --- |--- | | Input | empty string | | preserveNulls | - | | Salida | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfstGSPEM6qR8DWC2PB2GMlX41YK | | Determinista | No | | Bytes de entrada | 0 | | Bytes de salida | 91 | **Ejemplo 4** | | | | --- |--- | | Input | abcdefghijklmnopqrstuvwxyz | | preserveNulls | - | | Salida | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfsteEE1GKEPiRzyh0h7t6OmWMLTWCvO2ckr6pkx9sGL5VLDQeHzh6DmPpyWNuI= | | Determinista | No | | Bytes de entrada | 26 | | Bytes de salida | 127 | **Ejemplo 5** | | | | --- |--- | | Input | abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789 | | preserveNulls | - | | Salida | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfsteEE1GKEPiRzyh0h7t6OmWMLTWCvO2ckr6plwtH/8tRFnn2rF91bcB9G4\$1n8GiRfJNmqdP4/QOQ3cXb/pbvPcnnohrHIGSX54ua\$11/JfcVjc= | | Determinista | No | | Bytes de entrada | 62 | | Bytes de salida | 175 | ##### Tipo de relleno `fixed` (ejemplo 1) En este ejemplo, `pad_length` es 62 y la mayor entrada es de 62 bytes. **Ejemplo 1** | | | | --- |--- | | Input | null | | preserveNulls | TRUE | | Salida | null | | Determinista | Yes | | Bytes de entrada | 0 | | Bytes de salida | 0 | **Ejemplo 2** | | | | --- |--- | | Entrada | null | | preserveNulls | FALSE | | Salida | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfssGSNWfMRp7nSb7SMX2s3JKLOhK1\$17r75Tk\$1Mx9jy48Fcg1yOPvBqRSZ7oqy1V3UKfYTLEZb/hCz7oaIneVsrcoNpATs0GzbnLkor4L\$1/aSuA= | | Determinista | No | | Bytes de entrada | 0 | | Bytes de salida | 175 | **Ejemplo 3** | | | | --- |--- | | Input | empty string | | preserveNulls | - | | Salida | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfstGSNWfMRp7nSb7SMX2s3JKLOhK1\$17r75Tk\$1Mx9jy48Fcg1yOPvBqRSZ7oqy1V3UKfYTLEZb/hCz7oaIneVsrcoLB53l07VZpA6OwkuXu29CA= | | Determinista | No | | Bytes de entrada | 0 | | Bytes de salida | 175 | **Ejemplo 4** | | | | --- |--- | | Input | abcdefghijklmnopqrstuvwxyz | | preserveNulls | - | | Salida | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfsteEE1GKEPiRzyh0h7t6OmWMLTWCvO2ckr6pkx9jy48Fcg1yOPvBqRSZ7oqy1V3UKfYTLEZb/hCz7oaIneVsrcutBAcO\$1Mb9tuU2KIHH31AWg= | | Determinista | No | | Bytes de entrada | 26 | | Bytes de salida | 175 | **Ejemplo 5** | | | | --- |--- | | Input | abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789 | | preserveNulls | - | | Salida | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfsteEE1GKEPiRzyh0h7t6OmWMLTWCvO2ckr6plwtH/8tRFnn2rF91bcB9G4\$1n8GiRfJNmqdP4/QOQ3cXb/pbvPcnnohrHIGSX54ua\$11/JfcVjc= | | Determinista | No | | Bytes de entrada | 62 | | Bytes de salida | 175 | ##### Tipo de relleno `fixed` (ejemplo 2) En este ejemplo, `pad_length` es 162 y la mayor entrada es de 62 bytes. **Ejemplo 1** | | | | --- |--- | | Input | null | | preserveNulls | TRUE | | Salida | null | | Determinista | Yes | | Bytes de entrada | 0 | | Bytes de salida | 0 | **Ejemplo 2** | | | | --- |--- | | Entrada | null | | preserveNulls | FALSE | | Salida | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfssGSNWfMRp7nSb7SMX2s3JKLOhK1\$17r75Tk\$1Mx9jy48Fcg1yOPvBqRSZ7oqy1V3UKfYTLEZb/hCz7oaIneVsrcnkB0xbLWD7zNdAqQGR0rXoSESdW0I0vpNoGcBfv4cJbG0A3h1DvtkSSVc2B80OOGppzdDqhrUVN5wFNyn8vgfPMqDaeJk5bn\$18o4WtG/ClipNcjDXvXVtK4vfCohcCA6uwrmwv/xAySX\$1xcntotL703aBTBb | | Determinista | No | | Bytes de entrada | 0 | | Bytes de salida | 307 | **Ejemplo 3** | | | | --- |--- | | Input | empty string | | preserveNulls | - | | Salida | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfstGSNWfMRp7nSb7SMX2s3JKLOhK1\$17r75Tk\$1Mx9jy48Fcg1yOPvBqRSZ7oqy1V3UKfYTLEZb/hCz7oaIneVsrcnkB0xbLWD7zNdAqQGR0rXoSESdW0I0vpNoGcBfv4cJbG0A3h1DvtkSSVc2B80OOGppzdDqhrUVN5wFNyn8vgfPMqDaeJk5bn\$18o4WtG/ClipNcjDXvXVtK4vfCohcCA6uwrmwv84lVaT9Yd\$16oQx65/\$1gdVT | | Determinista | No | | Bytes de entrada | 0 | | Bytes de salida | 307 | **Ejemplo 4** | | | | --- |--- | | Input | abcdefghijklmnopqrstuvwxyz | | preserveNulls | - | | Salida | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfsteEE1GKEPiRzyh0h7t6OmWMLTWCvO2ckr6pkx9jy48Fcg1yOPvBqRSZ7oqy1V3UKfYTLEZb/hCz7oaIneVsrcnkB0xbLWD7zNdAqQGR0rXoSESdW0I0vpNoGcBfv4cJbG0A3h1DvtkSSVc2B80OOGppzdDqhrUVN5wFNyn8vgfPMqDaeJk5bn\$18o4WtG/ClipNcjDXvXVtK4vfCohcCA6uwrmwtX5Hnl\$1WyfO6ks3QMaRDGSf | | Determinista | No | | Bytes de entrada | 26 | | Bytes de salida | 307 | **Ejemplo 5** | | | | --- |--- | | Input | abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789 | | preserveNulls | - | | Salida | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfsteEE1GKEPiRzyh0h7t6OmWMLTWCvO2ckr6plwtH/8tRFnn2rF91bcB9G4\$1n8GiRfJNmqdP4/QOQ3cXb/pbvPcnkB0xbLWD7zNdAqQGR0rXoSESdW0I0vpNoGcBfv4cJbG0A3h1DvtkSSVc2B80OOGppzdDqhrUVN5wFNyn8vgfPMqDaeJk5bn\$18o4WtG/ClipNcjDXvXVtK4vfCohcCA6uwrmwjkJXQZOgPdeFX9Yr/8alV5i | | Determinista | No | | Bytes de entrada | 62 | | Bytes de salida | 307 | ##### Tipo de relleno `max` (ejemplo 1) En este ejemplo, `pad_length` es 0 y la mayor entrada es de 62 bytes. **Ejemplo 1** | | | | --- |--- | | Input | null | | preserveNulls | TRUE | | Salida | null | | Determinista | Yes | | Bytes de entrada | 0 | | Bytes de salida | 0 | **Ejemplo 2** | | | | --- |--- | | Entrada | null | | preserveNulls | FALSE | | Salida | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfssGSNWfMRp7nSb7SMX2s3JKLOhK1\$17r75Tk\$1Mx9jy48Fcg1yOPvBqRSZ7oqy1V3UKfYTLEZb/hCz7oaIneVsrcoNpATs0GzbnLkor4L\$1/aSuA= | | Determinista | No | | Bytes de entrada | 0 | | Bytes de salida | 175 | **Ejemplo 3** | | | | --- |--- | | Input | empty string | | preserveNulls | - | | Salida | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfstGSNWfMRp7nSb7SMX2s3JKLOhK1\$17r75Tk\$1Mx9jy48Fcg1yOPvBqRSZ7oqy1V3UKfYTLEZb/hCz7oaIneVsrcoLB53l07VZpA6OwkuXu29CA= | | Determinista | No | | Bytes de entrada | 0 | | Bytes de salida | 175 | **Ejemplo 4** | | | | --- |--- | | Input | abcdefghijklmnopqrstuvwxyz | | preserveNulls | - | | Salida | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfsteEE1GKEPiRzyh0h7t6OmWMLTWCvO2ckr6pkx9jy48Fcg1yOPvBqRSZ7oqy1V3UKfYTLEZb/hCz7oaIneVsrcutBAcO\$1Mb9tuU2KIHH31AWg= | | Determinista | No | | Bytes de entrada | 26 | | Bytes de salida | 175 | **Ejemplo 5** | | | | --- |--- | | Input | abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789 | | preserveNulls | - | | Salida | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfsteEE1GKEPiRzyh0h7t6OmWMLTWCvO2ckr6plwtH/8tRFnn2rF91bcB9G4\$1n8GiRfJNmqdP4/QOQ3cXb/pbvPcnnohrHIGSX54ua\$11/JfcVjc= | | Determinista | No | | Bytes de entrada | 62 | | Bytes de salida | 175 | ##### Tipo de relleno `max` (ejemplo 2) En este ejemplo, `pad_length` es 100 y la mayor entrada es de 62 bytes. **Ejemplo 1** | | | | --- |--- | | Input | null | | preserveNulls | TRUE | | Salida | null | | Determinista | Yes | | Bytes de entrada | 0 | | Bytes de salida | 0 | **Ejemplo 2** | | | | --- |--- | | Entrada | null | | preserveNulls | FALSE | | Salida | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfssGSNWfMRp7nSb7SMX2s3JKLOhK1\$17r75Tk\$1Mx9jy48Fcg1yOPvBqRSZ7oqy1V3UKfYTLEZb/hCz7oaIneVsrcnkB0xbLWD7zNdAqQGR0rXoSESdW0I0vpNoGcBfv4cJbG0A3h1DvtkSSVc2B80OOGppzdDqhrUVN5wFNyn8vgfPMqDaeJk5bn\$18o4WtG/ClipNcjDXvXVtK4vfCohcCA6uwrmwv/xAySX\$1xcntotL703aBTBb | | Determinista | No | | Bytes de entrada | 0 | | Bytes de salida | 307 | **Ejemplo 3** | | | | --- |--- | | Input | empty string | | preserveNulls | - | | Salida | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfstGSNWfMRp7nSb7SMX2s3JKLOhK1\$17r75Tk\$1Mx9jy48Fcg1yOPvBqRSZ7oqy1V3UKfYTLEZb/hCz7oaIneVsrcnkB0xbLWD7zNdAqQGR0rXoSESdW0I0vpNoGcBfv4cJbG0A3h1DvtkSSVc2B80OOGppzdDqhrUVN5wFNyn8vgfPMqDaeJk5bn\$18o4WtG/ClipNcjDXvXVtK4vfCohcCA6uwrmwv84lVaT9Yd\$16oQx65/\$1gdVT | | Determinista | No | | Bytes de entrada | 0 | | Bytes de salida | 307 | **Ejemplo 4** | | | | --- |--- | | Input | abcdefghijklmnopqrstuvwxyz | | preserveNulls | - | | Salida | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfsteEE1GKEPiRzyh0h7t6OmWMLTWCvO2ckr6pkx9jy48Fcg1yOPvBqRSZ7oqy1V3UKfYTLEZb/hCz7oaIneVsrcnkB0xbLWD7zNdAqQGR0rXoSESdW0I0vpNoGcBfv4cJbG0A3h1DvtkSSVc2B80OOGppzdDqhrUVN5wFNyn8vgfPMqDaeJk5bn\$18o4WtG/ClipNcjDXvXVtK4vfCohcCA6uwrmwtX5Hnl\$1WyfO6ks3QMaRDGSf | | Determinista | No | | Bytes de entrada | 26 | | Bytes de salida | 307 | **Ejemplo 5** | | | | --- |--- | | Input | abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789 | | preserveNulls | - | | Salida | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfsteEE1GKEPiRzyh0h7t6OmWMLTWCvO2ckr6plwtH/8tRFnn2rF91bcB9G4\$1n8GiRfJNmqdP4/QOQ3cXb/pbvPcnkB0xbLWD7zNdAqQGR0rXoSESdW0I0vpNoGcBfv4cJbG0A3h1DvtkSSVc2B80OOGppzdDqhrUVN5wFNyn8vgfPMqDaeJk5bn\$18o4WtG/ClipNcjDXvXVtK4vfCohcCA6uwrmwjkJXQZOgPdeFX9Yr/8alV5i | | Determinista | No | | Bytes de entrada | 62 | | Bytes de salida | 307 | #### Solución de problemas con columnas sealed **¿Por qué el texto cifrado de mis columnas sealed es varias veces mayor que el tamaño del cleartext que figuraba en ellas?** Esto depende de varios factores. Por un lado, el texto cifrado de una columna Cleartext siempre tiene una longitud mínima de 91 bytes. Si los datos de entrada eran pequeños (por ejemplo, las edades de los clientes), mostrarán un aumento considerable de tamaño. En segundo lugar, si `preserveNulls` se hubiera definido como `false` y los datos de entrada contuvieran un gran número de valores `null`, cada uno de esos valores `null` se habrá convertido en 91 bytes de texto cifrado. Por último, si se utiliza el relleno, por definición, se añaden bytes a los datos de cleartext antes de cifrarlos. **La mayoría de los datos de una columna sealed son muy pequeños y necesito utilizar relleno. ¿Puedo simplemente eliminar los valores grandes y procesarlos por separado para ahorrar espacio?** No le recomendamos que elimine los valores grandes y los procese por separado. Al hacerlo, se modifican las garantías de privacidad que ofrece el cliente de cifrado de C3R. Como modelo de amenaza, presuponga que un observador puede ver ambos conjuntos de datos cifrados. Si el observador ve que un subconjunto de datos tiene una columna considerablemente más o menos rellena que otro subconjunto, puede hacer inferencias sobre el tamaño de los datos de cada subconjunto. Por ejemplo, imaginemos que una columna `fullName` se rellena hasta un total de 40 bytes en un archivo y se rellena hasta 800 bytes en otro archivo. Un observador podría deducir que un conjunto de datos contiene el nombre más largo del mundo (747 bytes). **¿Debo proporcionar un relleno adicional al usar el tipo de relleno `max`?** No. Al utilizar el relleno `max`, se recomienda establecer en 0 la `pad_length` (también conocida como relleno adicional *complementario* al mayor valor de la columna). **¿Puedo elegir una `pad_length` grande al usar el relleno `fixed` para evitar tener que preocuparme de que quepa el valor más grande?** Sí, pero la gran longitud de relleno es ineficiente y utiliza más almacenamiento del necesario. Le recomendamos que compruebe el tamaño del mayor valor y que defina la `pad_length` con ese valor. **¿Cómo sé si necesito las garantías criptográficas que ofrece `preserveNulls`?** Lamentablemente, la respuesta es que depende. Como mínimo, se deben revisar los [Computación criptográfica para Clean Rooms](crypto-computing.md) en cuanto a la forma en que el ajuste `preserveNulls` protege sus datos. No obstante, le recomendamos que consulte los requisitos de manejo de datos de su organización y cualquier contrato aplicable a la colaboración correspondiente. **¿Por qué tengo que incurrir en la sobrecarga de base64?** Para permitir la compatibilidad con los formatos de archivo tabulares, como CSV, es necesaria la codificación base64. Si bien algunos formatos de archivo como Parquet podrían admitir representaciones binarias de datos, es importante que todos los participantes en una colaboración representen los datos de la misma manera para garantizar que los resultados de las consultas sean correctos. ## Solución de problemas relacionados con el aumento imprevisto de tamaño del texto cifrado Supongamos que ha cifrado los datos y que el tamaño de los datos resultantes es sorprendentemente grande. Los siguientes pasos pueden ayudarle a identificar dónde se produjo el aumento de tamaño y qué medidas puede adoptar, si las hubiera. ### Identificar dónde se produjo el aumento de tamaño Antes de poder averiguar por qué los datos cifrados son significativamente más grandes que los datos de cleartext, primero debe identificar dónde reside el aumento de tamaño. Las columnas de Cleartext se pueden ignorar con total seguridad porque permanecen inalteradas. Observe las columnas fingerprint y sealed restantes, y elija una que parezca significativa. ### Identificar el motivo por el que se produjo el aumento de tamaño Una columna de fingerprint o una columna sealed pueden contribuir al aumento de tamaño. **Topics** + [¿Procede el aumento de tamaño de una columna fingerprint?](#size-increase-from-fingerprint) + [¿Procede el aumento de tamaño de una columna sealed?](#size-increase-from-sealed) #### ¿Procede el aumento de tamaño de una columna fingerprint? Si la columna que más contribuye al aumento del almacenamiento es una columna fingerprint, es probable que se deba a que los datos de cleartext son pequeños (por ejemplo, la edad de los clientes). Cada texto cifrado de fingerprint resultante tiene una longitud de 52 bytes. Lamentablemente, no se puede hacer nada al respecto sobre una column-by-column base sólida. Para obtener más información, consulte [Sobrecarga de base para las columnas fingerprint](#fingerprint-columns-base-overhead) para conocer los detalles de esta columna, incluida su incidencia en los requisitos de almacenamiento. La otra causa posible del aumento de tamaño de una columna fingerprint es el ajuste de la colaboración `preserveNulls`. Si el ajuste de la colaboración para `preserveNulls` está deshabilitado (ajuste predeterminado), todos los valores `null` de las columnas fingerprint se convertirán en 52 bytes de texto cifrado. No hay nada que se pueda hacer al respecto en la colaboración actual. El ajuste `preserveNulls` se define en el momento en que se crea la colaboración, y todos los colaboradores deben usar el mismo ajuste para garantizar que los resultados de la consulta sean correctos. Para obtener más información sobre el ajuste `preserveNulls` y sobre cómo su habilitación afecta a las garantías de privacidad de los datos, consulte [Computación criptográfica para Clean Rooms](crypto-computing.md). #### ¿Procede el aumento de tamaño de una columna sealed? Si la columna que más contribuye al aumento del almacenamiento es una columna sealed, hay algunos detalles que podrían contribuir al aumento de tamaño. Si los datos de cleartext son pequeños (por ejemplo, las edades de los clientes), cada texto cifrado sealed resultante tiene una longitud mínima de 91 bytes. Lamentablemente, no se puede hacer nada al respecto. Para obtener más información, consulte [Sobrecarga de base para las columnas sealed](#sealed-columns-base-overhead) para conocer los detalles de esta columna, incluida su incidencia en los requisitos de almacenamiento. La segunda causa principal del aumento del almacenamiento en columnas sealed es el relleno. El relleno añade bytes adicionales al cleartext antes del cifrado para ocultar el tamaño de los valores individuales de un conjunto de datos. Se recomienda establecer el relleno en el valor mínimo posible para el conjunto de datos. Como mínimo, se debe definir `pad_length` para el relleno `fixed` de manera que abarque el mayor valor posible de la columna. Todo ajuste superior a ese no aportará garantías de privacidad adicionales. Por ejemplo, si sabe que el mayor valor posible de una columna puede ser de 50 bytes, le recomendamos que defina la `pad_length` en 50 bytes. Sin embargo, si la columna sealed utiliza el relleno `max`, le recomendamos que lo defina la `pad_length` en 0 bytes. Esto se debe a que el relleno `max` se refiere al relleno *adicional* que se suma al mayor valor de la columna. La última causa posible del aumento de tamaño de una columna sealed es el ajuste de la colaboración `preserveNulls`. Si el ajuste de la colaboración para `preserveNulls` está deshabilitado (ajuste predeterminado), todos los valores `null` de las columnas sealed se convertirán en 91 bytes de texto cifrado. No hay nada que se pueda hacer al respecto en la colaboración actual. El ajuste `preserveNulls` se define en el momento en que se crea la colaboración, y todos los colaboradores deben usar el mismo ajuste para garantizar que los resultados de la consulta sean correctos. Para obtener más información sobre los efectos de esta configuración y sobre cómo su activación afecta a las garantías de privacidad de sus datos, consulte [Computación criptográfica para Clean Rooms](crypto-computing.md).