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.
# Computación criptográfica para Clean Rooms
Computación criptográfica para Clean Rooms [(C3R) es una capacidad AWS Clean Rooms que se puede utilizar además de las reglas de análisis.](analysis-rules.md) Con C3R, las organizaciones pueden recopilar datos confidenciales para obtener nuevos conocimientos a partir del análisis de datos al tiempo que limitan criptográficamente la información que puede conocer cualquiera de las partes que interviene en el proceso. C3R lo pueden utilizar dos o más partes que deseen colaborar con sus datos confidenciales, pero que estén obligadas a usar solo datos cifrados en la nube.
El cliente de cifrado C3R es una herramienta de cifrado del lado del cliente que puede utilizar para [cifrar sus datos](glossary.md#glossary-encryption) y utilizarlos con ellos. AWS Clean Rooms Cuando utiliza el cliente de cifrado C3R, los datos permanecen protegidos criptográficamente mientras se utilizan en una colaboración. AWS Clean Rooms Al igual que en una AWS Clean Rooms colaboración habitual, los datos de entrada son tablas de bases de datos relacionales y el cálculo se expresa como una consulta SQL. Sin embargo, C3R admite solo un subconjunto limitado de consultas SQL en datos cifrados.
En concreto, C3R es compatible con SQL JOIN y SELECT declaraciones sobre datos protegidos criptográficamente. Cada columna de la tabla de entrada se puede utilizar exactamente en uno de los siguientes tipos de instrucciones SQL:
+ Columnas que están protegidas criptográficamente para su uso en JOIN las declaraciones se llaman **fingerprint columnas**.
+ Columnas que están protegidas criptográficamente para su uso en SELECT las declaraciones se llaman **sealed columnas**.
+ Columnas que no están protegidas criptográficamente para su uso en JOIN o SELECT las declaraciones se llaman **cleartext columnas**.
En algunos casos, GROUP BY las declaraciones se apoyan en fingerprint columnas. Para obtener más información, consulte [Columnas Fingerprint](crypto-computing-column-types.md#fingerprint-columns). Actualmente, C3R no admite el uso de otras construcciones de SQL en datos cifrados, como WHERE cláusulas o funciones agregadas como SUM y AVERAGE, incluso si de otro modo estarían permitidas por las reglas de análisis pertinentes.
C3R está diseñado para proteger los datos de celdas específicas de una tabla. Con la configuración predeterminada de C3R, los datos subyacentes que un cliente pone a disposición de terceros a través de una colaboración permanecen cifrados mientras el contenido se utiliza en AWS Clean Rooms. C3R utiliza el cifrado AES-GCM estándar de la industria para todos sealed columnas y una función pseudoaleatoria estándar del sector, conocida como código de autenticación de mensajes (HMAC) basado en hash, para proteger fingerprint columnas.
A pesar de que C3R cifra los datos de las tablas, es posible que aún se pueda inferir la siguiente información:
+ Información sobre las propias tablas, incluido el número de columnas, los nombres de columna y el número de filas de la tabla.
+ Como ocurre con la mayoría de las formas de cifrado estándar, C3R no intenta ocultar la longitud de los valores cifrados. C3R ofrece la posibilidad de rellenar los valores cifrados para ocultar la longitud exacta del texto sin cifrar. Sin embargo, aun así se podría revelar un límite superior de la longitud del texto sin cifrar de cada columna a un tercero.
+ Información de registro, como cuándo se agregó una fila determinada a una tabla cifrada de C3R.
Para obtener más información acerca de CR3, consulte los siguientes temas.
**Topics**
+ [Consideraciones al utilizar la computación criptográfica para Clean Rooms](crypto-computing-considerations.md)
+ [Tipos de archivo y de datos admitidos en computación criptográfica para Clean Rooms](crypto-computing-file-types.md)
+ [Nombres de columnas en computación criptográfica para Clean Rooms](crypto-computing-column-names.md)
+ [Tipos de columnas en computación criptográfica para Clean Rooms](crypto-computing-column-types.md)
+ [Parámetros de computación criptográfica](crypto-computing-parameters.md)
+ [Indicadores opcionales en computación criptográfica para Clean Rooms](crypto-computing-optional-flags.md)
+ [Consultas con computación criptográfica para Clean Rooms](crypto-computing-queries.md)
+ [Directrices para el cliente de cifrado de C3R](crypto-computing-guidelines.md)
# Consideraciones al utilizar la computación criptográfica para Clean Rooms
La computación criptográfica para Clean Rooms (C3R) busca maximizar la protección de los datos. Sin embargo, algunos casos de uso pueden beneficiarse de niveles más bajos de protección de datos a cambio de funcionalidades adicionales. Puede hacer estas concesiones específicas modificando C3R a partir de su configuración más segura. Como cliente, debe conocer estas ventajas y desventajas, y determinar si son apropiadas para su caso de uso. Entre las ventajas que debe considerar se incluyen las siguientes:
**Topics**
+ [Permitir cleartext mixto y datos cifrados en sus tablas](#allow-mixed-plaintext-and-encrypted-data)
+ [Permitir valores repetidos en columnas fingerprint](#allow-repeated-values)
+ [Disminuir las restricciones de nomenclatura de las columnas fingerprint](#loose-restrictions-on-join-column-names)
+ [Determinar cómo se representan los valores NULL](#determine-null-values)
Para obtener más información sobre cómo establecer parámetros para estos escenarios, consulte [Parámetros de computación criptográfica](crypto-computing-parameters.md).
## Permitir cleartext mixto y datos cifrados en sus tablas
Hacer que todos los datos se cifren en el cliente proporciona la máxima protección de datos. Sin embargo, esto limita ciertos tipos de consultas (por ejemplo, la función de agregación SUM). El riesgo de permitir datos de cleartext es que es factible que cualquier persona con acceso a las tablas cifradas pueda inferir cierta información sobre los valores cifrados. Esto podría hacerse realizando un análisis estadístico de los datos de cleartext y de los datos relacionados.
Por ejemplo, supongamos que tiene las columnas de `City` y `State`. La columna `City` es cleartext y la columna `State` está cifrada. Cuando ve el valor `Chicago` en la columna `City`, esto le ayuda a determinar con una alta probabilidad que el `State` es `Illinois`. Por el contrario, si una columna es `City` y la otra columna es `EmailAddress`, es poco probable que un cleartext `City` revele algo sobre una `EmailAddress` cifrada.
Para obtener más información acerca del parámetro para este escenario, consulte [Parámetro Permitir columnas cleartext](crypto-computing-parameters.md#parameter-allowcleartext).
## Permitir valores repetidos en columnas fingerprint
Para optar por un método más seguro, presuponemos que cualquier columna fingerprint contiene exactamente una instancia de una variable. En una columna fingerprint no se puede repetir ningún elemento. El cliente de cifrado de C3R asigna estos valores cleartext a valores únicos que son indistinguibles de los valores aleatorios. Por lo tanto, es imposible inferir información acerca del cleartext a partir de estos valores aleatorios.
El riesgo de los valores repetidos en una columna fingerprint es que estos valores repetidos resulten en valores repetidos que parezcan aleatorios. Por lo tanto, cualquier persona que tenga acceso a las tablas cifradas podría, en teoría, realizar un análisis estadístico de las columnas fingerprint que podría revelar información sobre los valores cleartext.
De nuevo, presupongamos que la columna fingerprint es `State`, y que cada fila de la tabla corresponde a un hogar estadounidense. Un análisis de frecuencia permitiría inferir qué estado es `California` y cuál es `Wyoming` con una alta probabilidad. Esta inferencia es posible porque `California` tiene muchos más residentes que `Wyoming`. Por el contrario, presupongamos que la columna fingerprint está en un identificador de hogar y que cada hogar aparece en la base de datos entre 1 y 4 veces en una base de datos de millones de entradas. Es poco probable que un análisis de frecuencia revele información útil.
Para obtener más información acerca del parámetro para este escenario, consulte [Parámetro Permitir duplicados](crypto-computing-parameters.md#parameter-allowduplicates).
## Disminuir las restricciones de nomenclatura de las columnas fingerprint
De forma predeterminada, presuponemos que, cuando se combinan dos tablas utilizando columnas fingerprint cifradas, dichas columnas tienen el mismo nombre en cada tabla. El motivo técnico de este resultado es que, de forma predeterminada, deducimos una clave criptográfica diferente para cifrar cada columna fingerprint. Esa clave se deriva de una combinación de la clave secreta compartida de la colaboración y el nombre de la columna. Si intentamos combinar dos columnas con nombres de columna diferentes, obtenemos claves diferentes y no podemos procesar una combinación válida.
Para solucionar este problema, puede desactivar la característica que deriva las claves a partir de cada nombre de columna. A continuación, el cliente de cifrado de C3R utiliza una única clave derivada para todas las columnas fingerprint. El riesgo reside en que se pueda realizar otro tipo de análisis de frecuencia que pueda revelar información.
Volvamos al ejemplo de `City` y `State`. Si derivamos los mismos valores aleatorios para cada columna fingerprint (al no incorporar el nombre de columna), `New York` tiene el mismo valor aleatorio en las columnas `City` y `State`. Nueva York es una de las pocas ciudades de EE. UU. donde el nombre de `City` coincide con el nombre del `State` nombre. Por el contrario, si su conjunto de datos tiene valores completamente diferentes en cada columna, no se filtra información.
Para obtener más información acerca del parámetro para este escenario, consulte [Parámetro Permitir JOIN de columnas con nombres diferentes](crypto-computing-parameters.md#parameter-allowjoin).
## Determinar cómo se representan los valores NULL
La opción que tiene a su disposición consiste en procesar criptográficamente los valores NULL (cifrado y HMAC) como cualquier otro valor. Si no procesa los valores NULL como cualquier otro valor, es posible que se revele información.
Por ejemplo, supongamos que NULL en la columna `Middle Name` de cleartext señala a las personas sin segundo nombre. Si no cifra esos valores, filtrará qué filas de la tabla cifrada se utilizan para personas sin segundo nombre. Esa información podría ser una señal de identificación para algunas personas de ciertas poblaciones. Sin embargo, si procesa los valores NULL criptográficamente, algunas consultas SQL actúan de forma diferente. Por ejemplo, las cláusulas GROUP BY no agruparán los valores fingerprint NULL en columnas fingerprint.
Para obtener más información acerca del parámetro para este escenario, consulte [Parámetro Conservar valores NULL](crypto-computing-parameters.md#parameter-preservenulls).
# Tipos de archivo y de datos admitidos en computación criptográfica para Clean Rooms
El cliente de cifrado de C3R reconoce los siguientes tipos de archivo:
+ Archivos CSV
+ Archivos de Parquet
Puede utilizar el indicador `--fileFormat` del cliente de cifrado de C3R para especificar un formato de archivo de forma explícita. Cuando se especifica de forma explícita, el formato de archivo no viene determinado por la extensión del archivo.
**Topics**
+ [Archivos CSV](#csv-file-type)
+ [Archivos de Parquet](#parquet-file-type)
+ [Cifrar valores que no son de cadena](#encrypt-non-string-values)
## Archivos CSV
Se presupone que un archivo con la extensión .csv tiene formato CSV y contiene texto codificado en UTF-8. El cliente de cifrado de C3R trata todos los valores como cadenas.
### Propiedades admitidas en los archivos .csv
El cliente de cifrado de C3R requiere que los archivos .csv tengan las siguientes propiedades:
+ Puede contener o no una fila de encabezado inicial que designe de manera exclusiva cada columna.
+ Delimitado por comas. (actualmente no se admiten delimitadores personalizados).
+ Texto codificado en UTF-8.
#### Recorte de espacios en blanco de las entradas .csv
Los espacios en blanco iniciales y finales se recortan de las entradas .csv.
#### Codificación NULL personalizada para un archivo .csv
Un archivo .csv puede utilizar una codificación personalizada NULL.
Con el cliente de cifrado de C3R, puede especificar codificaciones personalizadas para las entradas NULL de los datos de entrada utilizando el indicador `--csvInputNULLValue=`. El cliente de cifrado de C3R puede usar codificaciones personalizadas en el archivo de salida generado para las entradas NULL utilizando el indicador `--csvOutputNULLValue=`.
**nota**
Una entrada NULL se considera *carente* de contenido, especialmente en el contexto de un formato tabular más enriquecido, como una tabla SQL. Aunque el formato .csv no admite explícitamente esta caracterización por razones históricas, es una convención habitual considerar que una entrada vacía que contiene solo espacios en blanco es NULL. Por lo tanto, ese es el comportamiento predeterminado del cliente de cifrado de C3R, y se puede personalizar según sea necesario.
### ¿Cómo interpreta C3R las entradas .csv?
La siguiente tabla proporciona ejemplos de cómo se serializan las entradas .csv (de cleartext a cleartext, para mayor claridad) en función de los valores (si los hay) que se proporcionan para los indicadores `--csvInputNULLValue=` y `--csvOutputNULLValue=`. Los espacios en blanco iniciales y finales fuera de las comillas se recortan antes de que C3R interprete el significado de cualquier valor.
| `` | `` | Entrada de entrada | Entrada de salida |
| --- |--- |--- |--- |
| Ninguno | Ninguna | ,AnyProduct, | ,AnyProduct, |
| Ninguna | Ninguna | , AnyProduct , | ,AnyProduct, |
| Ninguna | Ninguna | ,"AnyProduct", | ,AnyProduct, |
| Ninguna | Ninguna | , "AnyProduct" , | ,AnyProduct, |
| Ninguna | Ninguna | ,, | ,, |
| Ninguna | Ninguna | , , | ,, |
| Ninguna | Ninguna | ,"", | ,, |
| Ninguna | Ninguna | ," ", | ," ", |
| Ninguna | Ninguna | , " " , | ," ", |
| "AnyProduct" | "NULL" | ,AnyProduct, | ,NULL, |
| "AnyProduct" | "NULL" | , AnyProduct , | ,NULL, |
| "AnyProduct" | "NULL" | ,"AnyProduct", | ,NULL, |
| "AnyProduct" | "NULL" | , "AnyProduct" , | ,NULL, |
| Ninguna | "NULL" | ,, | ,NULL, |
| Ninguna | "NULL" | , , | ,NULL, |
| Ninguna | "NULL" | ,"", | ,NULL, |
| Ninguna | "NULL" | ," ", | ," ", |
| Ninguno | "NULL" | , " " , | ," ", |
| "" | "NULL" | ,, | ,NULL, |
| "" | "NULL" | , , | ,NULL, |
| "" | "NULL" | ,"", | ,"", |
| "" | "NULL" | ," ", | ," ", |
| "" | "NULL" | , " " , | ," ", |
| "\$1"\$1"" | "NULL" | ,, | ,, |
| "\$1"\$1"" | "NULL" | , , | ,, |
| "\$1"\$1"" | "NULL" | ,"", | ,NULL, |
| "\$1"\$1"" | "NULL" | ," ", | ," ", |
| "\$1"\$1"" | "NULL" | , " " , | ," ", |
### Archivo CSV sin encabezados
No es necesario que el archivo .csv de origen tenga encabezados en la primera fila que asignen un nombre exclusivo a cada columna. Sin embargo, un archivo .csv sin una fila de encabezados requiere un esquema de cifrado posicional. Se requiere el esquema de cifrado posicional en lugar del esquema mapeado típico que se usa tanto para los archivos .csv con una fila de encabezado como para los archivos de Parquet.
Un esquema de cifrado posicional especifica las columnas de salida por posición en lugar de por nombre. Un esquema de cifrado mapeado asigna los nombres de columnas de origen a nombres de columnas de destino. Para obtener más información, incluida una explicación detallada y ejemplos de ambos formatos de esquema, consulte [Esquemas de tablas mapeados y posicionales](create-schema.md#mapped-and-positional-schemas).
## Archivos de Parquet
Se presupone que un archivo con la extensión .parquet tiene formato de Apache Parquet.
### Tipos de datos Parquet admitidos
El cliente de cifrado de C3R puede procesar cualquier dato no complejo (es decir, de tipo primitivo) de un archivo Parquet que corresponda a un tipo de datos admitido por AWS Clean Rooms.
Sin embargo, en las columnas sealed solo se pueden usar columnas de cadena.
Se admiten los siguientes tipos de datos de Parquet:
+ Tipo primitivo `Binary` con las siguientes anotaciones lógicas:
+ Ninguno si `--parquetBinaryAsString` está definido (tipo de datos `STRING`)
+ `Decimal(scale, precision)` (tipo de datos `DECIMAL`)
+ `String` (tipo de datos `STRING`)
+ Tipo de datos primitivo `Boolean` sin anotación lógica (tipo de datos `BOOLEAN`)
+ Tipo de datos primitivo `Double` sin anotación lógica (tipo de datos `DOUBLE`)
+ Tipo primitivo `Fixed_Len_Binary_Array` con anotación lógica `Decimal(scale, precision)` (tipo de datos `DECIMAL`)
+ Tipo de datos primitivo `Float` sin anotación lógica (tipo de datos `FLOAT`)
+ Tipo primitivo `Int32` con las siguientes anotaciones lógicas:
+ Ninguna (tipo de datos `INT`)
+ `Date` (tipo de datos `DATE`)
+ `Decimal(scale, precision)` (tipo de datos `DECIMAL`)
+ `Int(16, true)` (tipo de datos `SMALLINT`)
+ `Int(32, true)` (tipo de datos `INT`)
+ Tipo de datos primitivo `Int64` con las siguientes anotaciones lógicas:
+ Ninguna (tipo de datos `BIGINT`)
+ `Decimal(scale, precision)` (tipo de datos `DECIMAL`)
+ `Int(64, true)` (tipo de datos `BIGINT`)
+ `Timestamp(isUTCAdjusted, TimeUnit.MILLIS)` (tipo de datos `TIMESTAMP`)
+ `Timestamp(isUTCAdjusted, TimeUnit.MICROS)` (tipo de datos `TIMESTAMP`)
+ `Timestamp(isUTCAdjusted, TimeUnit.NANOS)` (tipo de datos `TIMESTAMP`)
## Cifrar valores que no son de cadena
Actualmente, solo se admiten valores de cadena en las columnas sealed.
En el caso de los archivos .csv, el cliente de cifrado de C3R trata todos los valores como texto codificado en UTF-8 y no intenta interpretarlos de forma diferente antes del cifrado.
En el caso de las columnas de huella digital, los tipos se agrupan en clases de equivalencia. Una clase de equivalencia es un conjunto de tipos de datos que se pueden comparar de forma inequívoca para determinar su igualdad mediante un tipo de datos representativo.
Las clases de equivalencia permiten asignar huellas dactilares idénticas al mismo valor semántico independientemente de la representación original. Sin embargo, el mismo valor en dos clases de equivalencia no dará como resultado la misma columna de huella digital.
Por ejemplo, al valor `INTEGRAL` `42` se le asignará la misma huella digital independientemente de si originalmente era `SMALLINT`, `INT` o `BIGINT`. Además, el valor `INTEGRAL` `0` nunca coincidirá con el valor `BOOLEAN` `FALSE` (que se representa mediante el valor `0`).
Las columnas de huellas digitales admiten las siguientes clases de equivalencia y los tipos de AWS Clean Rooms datos correspondientes:
| Clase de equivalencia | Tipo de datos AWS Clean Rooms admitido |
| --- | --- |
| BOOLEAN | BOOLEAN |
| DATE | DATE |
| INTEGRAL | BIGINT, INT, SMALLINT |
| STRING | CHAR, STRING, VARCHAR |
# Nombres de columnas en computación criptográfica para Clean Rooms
De forma predeterminada, los nombres de columnas son importantes en computación criptográfica para Clean Rooms.
Si el valor del parámetro **Permitir JOIN de columnas con nombres diferentes** es **false**, se utilizan los nombres de columna durante el cifrado de las columnas fingerprint. Por este motivo, de forma predeterminada, los colaboradores deben coordinarse con antelación y utilizar los mismos nombres de columna de destino para los datos que se utilizarán en las instrucciones JOIN en las consultas. De forma predeterminada, las columnas cifradas para JOIN con nombres diferentes no ejecutan correctamente la instrucción JOIN en ningún valor.
Si el valor del parámetro **Permitir JOIN de columnas con nombres diferentes** es **true**, las instrucciones JOIN en columnas cifradas como columnas fingerprint se ejecutan correctamente. Cifrar los datos con este parámetro puede permitir cierta inferencia de los valores cleartext. Por ejemplo, si una fila tiene el mismo valor de código de autenticación de mensajes basado en hash (HMAC) tanto en la columna `City` como en la columna `State`, el valor podría ser `New York`.
## Normalización de los nombres de encabezado de columna
El cliente de cifrado de C3R normaliza los nombres de los encabezados de columna. Se eliminan todos los espacios en blanco iniciales y finales, y el nombre de la columna se cambia a minúsculas en el resultado transformado.
La normalización se aplica antes de cualquier otro cómputo, cálculo u otra operación que pueda verse afectada por los nombres de columna. El archivo de salida emitido contiene solo los nombres normalizados.
# Tipos de columnas en computación criptográfica para Clean Rooms
En este tema se proporciona información sobre los tipos de columnas en computación criptográfica para Clean Rooms.
**Topics**
+ [Columnas Fingerprint](#fingerprint-columns)
+ [Columnas selladas](#sealed-columns)
+ [Columnas Cleartext](#cleartext-columns)
## Columnas Fingerprint
Las *columnas Fingerprint* son columnas que están protegidas criptográficamente para su uso en instrucciones JOIN.
Los datos de las columnas fingerprint no se pueden descifrar. Solo se pueden descifrar los datos de las columnas selladas.
Las columnas Fingerprint solo deben usarse en las siguientes cláusulas y funciones SQL:
+ JOIN (INNER, OUTER, LEFT, RIGHT, or FULL) frente a otras columnas fingerprint:
+ Si el valor del parámetro `allowJoinsOnColumnsWithDifferentNames` se establece en `false`, ambas columnas fingerprint de la JOIN deben tener también el mismo nombre.
+ `SELECT COUNT()`
+ `SELECT COUNT(DISTINCT )`
+ `GROUP BY` (usar solo si la colaboración ha definido el valor del parámetro `preserveNulls` como `true`).
Las consultas que infrinjan estas restricciones pueden arrojar resultados incorrectos.
## Columnas selladas
Las *columnas selladas* son columnas que están protegidas criptográficamente para su uso en instrucciones SELECT.
Las columnas selladas solo deben usarse en las siguientes cláusulas y funciones SQL:
+ `SELECT`
+ `SELECT ... AS`
+ `SELECT COUNT()`
**nota**
`SELECT COUNT(DISTINCT )` no se admite.
Las consultas que infrinjan estas restricciones pueden arrojar resultados incorrectos.
### Rellenar datos de una columna sealed antes del cifrado
Cuando se especifica que una columna debe ser una columna sealed, C3R pregunta qué tipo de *relleno* se desea elegir. El relleno de datos antes del cifrado es opcional. Sin relleno (un relleno de tipo `none`), la longitud de los datos cifrados indica el tamaño del cleartext. En determinadas circunstancias, el tamaño del cleartext podría dejar revelar el texto sin formato. Con el relleno (relleno de tipo `fixed` o `max`), todos los valores se rellenan primero hasta alcanzar un tamaño común, y entonces se cifran. Con el relleno, la longitud de los datos cifrados no proporciona información sobre la longitud del cleartext original, salvo por indicar un límite superior de su tamaño.
Si desea rellenar una columna y conoce la longitud máxima en bytes de los datos de esa columna, utilice el relleno `fixed`. Utilice un valor `length` que sea al menos tan grande como la mayor longitud en bytes de esa columna.
**nota**
Si un valor supera la `length` proporcionada, se produce un error y el cifrado falla.
Si desea rellenar una columna y no conoce la longitud máxima en bytes de los datos de esa columna, utilice el relleno `max`. Este modo de relleno rellena todos los datos hasta la longitud del valor más largo, más los bytes de `length` adicionales.
**nota**
Es posible que desee cifrar los datos por lotes o actualizar sus tablas con nuevos datos de forma periódica. Tenga en cuenta que el relleno `max` rellenará las entradas hasta la longitud (más el byte de `length`) de la entrada de texto sin formato más larga de un lote determinado. Esto significa que la longitud del texto cifrado puede variar de un lote a otro. Por lo tanto, si conoce la longitud máxima en bytes de una columna, entonces debe utilizar el relleno `fixed` en lugar de `max`.
## Columnas Cleartext
Las *columnas Cleartext* son columnas que no están protegidas criptográficamente para su uso en instrucciones JOIN o SELECT.
Las columnas Cleartext se pueden usar en cualquier parte de la consulta SQL.
# Parámetros de computación criptográfica
Hay parámetros de computación criptográfica disponibles para las colaboraciones que utilizan la computación criptográfica para Clean Rooms (C3R) al [crear una colaboración](create-collaboration.md). Puede crear una colaboración mediante la AWS Clean Rooms consola o la operación de la `CreateCollaboration` API. En la consola, puede establecer valores para los parámetros en **Parámetros de computación criptográfica** después de activar la opción **Admitir computación criptográfica**. Para obtener más información, consulte los siguientes temas.
**Topics**
+ [Parámetro Permitir columnas cleartext](#parameter-allowcleartext)
+ [Parámetro Permitir duplicados](#parameter-allowduplicates)
+ [Parámetro Permitir JOIN de columnas con nombres diferentes](#parameter-allowjoin)
+ [Parámetro Conservar valores NULL](#parameter-preservenulls)
## Parámetro Permitir columnas cleartext
En la consola, puede configurar el parámetro **Permitir columnas cleartext** al [crear una colaboración](create-collaboration.md) para especificar si se permiten los datos cleartext en una tabla con datos cifrados.
En la siguiente tabla se describen los valores del parámetro **Permitir columnas cleartext**.
| Valor del parámetro | Description (Descripción) |
| --- | --- |
| No | No se permiten columnas Cleartext en la tabla cifrada. Todos los datos están protegidos criptográficamente. |
| Sí | Se permiten columnas Cleartext en la tabla cifrada. Las columnas Cleartext no están protegidas criptográficamente y se incluyen como cleartext. Debe tomar nota de lo que los datos cleartext de las filas pueden revelar sobre el resto de datos de la tabla. Para ejecutar SUM o AVG en columnas específicas, las columnas deben estar en cleartext. |
Mediante la operación `CreateCollaboration` de la API, para el parámetro `dataEncryptionMetadata`, puede establecer el valor de `allowCleartext` en `true` o `false`. Para obtener más información sobre las operaciones de la API, consulte [Referencia de la API de AWS Clean Rooms](https://docs.aws.amazon.com/clean-rooms/latest/apireference/Welcome.html).
Las columnas Cleartext corresponden a columnas que se clasifican como cleartext en el esquema específico de la tabla. Los datos de estas columnas no están cifrados y se pueden utilizar de cualquier forma. Cleartextlas columnas pueden resultar útiles si los datos no son confidenciales and/or si se necesita más flexibilidad de la que permite una sealed fingerprint columna o columnas cifradas.
## Parámetro Permitir duplicados
En la consola, puede configurar el parámetro **Permitir duplicados** al [crear una colaboración](create-collaboration.md) para especificar si las columnas cifradas para consultas JOIN pueden contener valores no NULL duplicados.
**importante**
Los parámetros **Permitir duplicados**, [**Permitir JOIN de columnas con nombres diferentes**](#parameter-allowjoin) y [**Conservar los valores NULL**](#parameter-preservenulls) tienen efectos distintos pero relacionados.
En la siguiente tabla se describen los valores del parámetro **Permitir duplicados**.
| Valor del parámetro | Description (Descripción) |
| --- | --- |
| No | No se permiten valores repetidos en una columna fingerprint. Todos los valores de una misma columna fingerprint deben ser únicos. |
| Sí | Se permiten valores repetidos en una columna fingerprint. Si necesita combinar columnas con valores repetidos, defina este valor en **Sí**. Si se establece en **Sí**, los patrones de frecuencia que aparecen en las columnas fingerprint de la tabla de C3R o en los resultados pueden implicar información adicional sobre la estructura de los datos cleartext. |
Mediante la operación `CreateCollaboration` de la API, en el parámetro `dataEncryptionMetadata`, puede establecer el valor de `allowDuplicates` en `true` o `false`. Para obtener más información sobre las operaciones de la API, consulte [Referencia de la API de AWS Clean Rooms](https://docs.aws.amazon.com/clean-rooms/latest/apireference/Welcome.html).
De forma predeterminada, si se deben usar datos cifrados en consultas JOIN, el cliente de cifrado de C3R requiere que esas columnas no tengan valores duplicados. Con este requisito se pretende aumentar la protección de los datos. Este comportamiento puede contribuir a garantizar que los patrones repetidos en los datos no sean observables. Sin embargo, si desea trabajar con datos cifrados en consultas JOIN y no le preocupan los valores duplicados, el parámetro **Permitir duplicados** puede desactivar esta comprobación conservadora.
## Parámetro Permitir JOIN de columnas con nombres diferentes
En la consola, puede configurar el parámetro **Permitir JOIN de columnas con nombres diferentes** al [crear una colaboración](create-collaboration.md) para especificar si se admiten las instrucciones JOIN entre columnas con nombres diferentes.
Para obtener más información, consulte [Normalización de los nombres de encabezado de columna](crypto-computing-column-names.md#column-header-names-normalization)
En la siguiente tabla se describen los valores del parámetro **Permitir JOIN de columnas con nombres diferentes**.
| Valor del parámetro | Description (Descripción) |
| --- | --- |
| No | No se admiten las combinaciones de columnas fingerprint con nombres diferentes. Las instrucciones JOIN solo proporcionan resultados precisos en las columnas que tienen el mismo nombre. El valor **No** proporciona una mayor seguridad de la información, pero requiere que los participantes en la colaboración acuerden previamente los nombres de las columnas. Si dos columnas tienen nombres diferentes cuando se cifran como columnas fingerprint y la opción **Permitir JOIN de columnas con nombres diferentes** está establecida en **No**, las instrucciones JOIN en esas columnas no producen ningún resultado. Esto se debe a que, después del cifrado, no se comparten valores entre ellas. |
| Sí | Se admiten las combinaciones de columnas fingerprint con nombres diferentes. Para mayor flexibilidad, los usuarios pueden establecer este valor en **Sí**, lo que permite las instrucciones JOIN en las columnas independientemente del nombre de la columna. Si se establece en **Sí**, el cliente de cifrado de C3R no tiene en cuenta el nombre de la columna al proteger las columnas fingerprint. Como resultado, en la tabla de C3R se pueden observar valores comunes en distintas columnas fingerprint. Por ejemplo, si una fila tiene el mismo valor JOIN cifrado tanto en una columna `City` como en una columna `State`, sería razonable inferir que ese valor es `New York`. |
Mediante la operación `CreateCollaboration` de la API, para el parámetro `dataEncryptionMetadata`, puede establecer el valor de `allowJoinsOnColumnsWithDifferentNames` en `true` o `false`. Para obtener más información sobre las operaciones de la API, consulte [Referencia de la API de AWS Clean Rooms](https://docs.aws.amazon.com/clean-rooms/latest/apireference/Welcome.html).
De forma predeterminada, el cifrado de las columnas fingerprint se ve afectado por el `targetHeader` de esa columna, establecido en [Paso 4: generar un esquema de cifrado para un archivo tabular](gen-encryption-schema-csv.md). Por lo tanto, el mismo valor cleartext tiene diferentes representaciones cifradas en cada columna fingerprint diferente en la que se cifra.
En algunos casos, este parámetro puede resultar útil para evitar la inferencia de los valores cleartext. Por ejemplo, observar el mismo valor cifrado en las columnas fingerprint `City` y `State` podría llevar a inferir de forma razonable que el valor es `New York`. Sin embargo, el uso de este parámetro requiere una coordinación adicional por adelantado, de modo que todas las columnas que se van a combinar en consultas tengan nombres compartidos.
Puede utilizar el parámetro **Permitir JOIN de columnas con nombres diferentes** para reducir esta restricción. Si el valor del parámetro se establece en `Yes`, permite que todas las columnas cifradas para JOIN se utilicen juntas independientemente del nombre.
## Parámetro Conservar valores NULL
En la consola, puede configurar el parámetro **Conservar valores NULL** al [crear una colaboración](create-collaboration.md) para indicar que no hay ningún valor presente en esa columna.
En la siguiente tabla se describen los valores del parámetro **Conservar valores NULL**.
| Valor del parámetro | Description (Descripción) |
| --- | --- |
| No | Los valores NULL no se conservan. Los valores NULL no aparecen como NULL en una tabla cifrada. Los valores NULL aparecen como valores aleatorios únicos en una tabla de C3R. |
| Sí | Los valores NULL se conservan. Los valores NULL aparecen como NULL en una tabla cifrada. Si se requiere la semántica SQL de los NULL, puede establecer este valor en Sí. Como resultado, las entradas NULL aparecen como NULL en la tabla de C3R, independientemente de si la columna está cifrada o de la configuración del parámetro Permitir duplicados. |
Mediante la operación `CreateCollaboration` de la API, para el parámetro `dataEncryptionMetadata`, puede establecer el valor de `preserveNulls` en `true` o `false`. Para obtener más información sobre las operaciones de la API, consulte [Referencia de la API de AWS Clean Rooms](https://docs.aws.amazon.com/clean-rooms/latest/apireference/Welcome.html).
Si el parámetro **Conservar valores NULL** está establecido en **No** para la colaboración:
1. Las entradas NULL de las columnas `cleartext` permanecen inalteradas.
1. Las entradas NULL de las columnas `fingerprint` cifradas se cifran como valores aleatorios para ocultar su contenido. Combinar una columna cifrada con entradas NULL de la columna cleartext no produce ninguna coincidencia para ninguna de las entradas NULL. No se realizan coincidencias porque cada una recibe su propio contenido aleatorio único.
1. Las entradas NULL de las columnas `sealed` cifradas se cifran.
Cuando el valor del parámetro **Conservar valores NULL** se establece en **Sí** para la colaboración, las entradas NULL de todas las columnas se mantienen como NULL, independientemente de si la columna está cifrada o no.
El parámetro **Conservar valores NULL** resulta útil en escenarios tales como el enriquecimiento de datos, donde se desea compartir una falta de información expresada como NULL. El parámetro **Conservar valores NULL** también es útil en formato fingerprint o HMAC cuando se tienen valores NULL en la columna que se desea ejecutar JOIN o GROUP BY.
Si el valor de los parámetros **Permitir duplicados** y **Conservar valores NULL** se establece en **No**, tener más de una entrada NULL en una columna fingerprint produce un error y detiene el cifrado. Si el valor de cualquiera de los parámetros se establece en **Sí**, no se produce tal error.
# Indicadores opcionales en computación criptográfica para Clean Rooms
En las siguientes secciones se describen los indicadores opcionales que puede configurar al [cifrar datos](encrypt-data.md) utilizando el cliente de cifrado de C3R para personalizar y probar archivos tabulares.
**Topics**
+ [Indicador `--csvInputNULLValue`](#optional-flags-CSVinputNullValue)
+ [Indicador `--csvOutputNULLValue`](#optional-flags-CSVoutputNullValue)
+ [Indicador `--enableStackTraces`](#optional-flags-enablestacktraces)
+ [Indicador `--dryRun`](#optional-flags-dry-run)
+ [Indicador `--tempDir`](#optional-flags-working-dir)
## Indicador `--csvInputNULLValue`
Puede usar el indicador `--csvInputNULLValue` para especificar codificaciones personalizadas para las entradas NULL de los datos de entrada al [cifrar datos](encrypt-data.md) utilizando el cliente de cifrado de C3R.
En la siguiente tabla se resumen el uso y los parámetros de este indicador.
| De uso | Parameters |
| --- | --- |
| Opcional. Los usuarios pueden especificar codificaciones personalizadas para las entradas NULL de los datos de entrada. | Codificación especificada por el usuario de valores NULL en el archivo CSV de entrada |
Una entrada NULL es una entrada que se considera carente de contenido, específicamente en el contexto de un formato tabular más enriquecido, como una tabla SQL. Aunque el formato .CSV no admite explícitamente esta caracterización por razones históricas, es una convención habitual considerar que una entrada vacía que contiene solo espacios en blanco es NULL. Por lo tanto, ese es el comportamiento predeterminado del cliente de cifrado de C3R, y se puede personalizar según sea necesario.
## Indicador `--csvOutputNULLValue`
Puede usar el indicador `--csvOutputNULLValue` para especificar codificaciones personalizadas para las entradas NULL en los datos de salida al [cifrar datos](encrypt-data.md) con el cliente de cifrado de C3R.
En la siguiente tabla se resumen el uso y los parámetros de este indicador.
| De uso | Parameters |
| --- | --- |
| Opcional. Los usuarios pueden especificar codificaciones personalizadas en el archivo de salida generado para las entradas NULL. | Codificación especificada por el usuario de valores NULL en el archivo CSV de salida |
Una entrada NULL es una entrada que se considera carente de contenido, específicamente en el contexto de un formato tabular más enriquecido, como una tabla SQL. Aunque el formato .CSV no admite explícitamente esta caracterización por razones históricas, es una convención habitual considerar que una entrada vacía que contiene solo espacios en blanco es NULL. Por lo tanto, ese es el comportamiento predeterminado del cliente de cifrado de C3R, y se puede personalizar según sea necesario.
## Indicador `--enableStackTraces`
Al [cifrar datos](encrypt-data.md) utilizando el cliente de cifrado de C3R, utilice el indicador `--enableStackTraces` para proporcionar información contextual adicional para notificar errores cuando C3R detecte un error.
AWS no recopila errores. Si encuentras un error, utiliza el seguimiento de pila para solucionar el error tú mismo o envía el seguimiento de pila a Soporte para obtener ayuda.
En la siguiente tabla se resumen el uso y los parámetros de este indicador.
| De uso | Parameters |
| --- | --- |
| Opcional. Se utiliza para proporcionar información contextual adicional para notificar errores cuando el cliente de cifrado de C3R detecta un error. | Ninguno |
## Indicador `--dryRun`
Los comandos [encrypt](encrypt-data.md) y [decrypt](decrypt-data.md) del cliente de cifrado de C3R incluyen un indicador `--dryRun` opcional. El indicador toma todos los argumentos proporcionados por el usuario y comprueba su validez y coherencia.
Puede usar el indicador `--dryRun` para comprobar si su archivo de esquema es válido y coherente con el archivo de entrada correspondiente.
En la siguiente tabla se resumen el uso y los parámetros de este indicador.
| De uso | Parameters |
| --- | --- |
| Opcional. Hace que el cliente de cifrado de C3R analice los parámetros y compruebe los archivos, pero no realiza ningún cifrado ni descifrado. | Ninguno |
## Indicador `--tempDir`
Es posible que desee utilizar un directorio temporal, ya que los archivos cifrados a veces pueden superar en tamaño a los no cifrados, dependiendo de la configuración. Los conjuntos de datos también deben cifrarse por colaboración para funcionar correctamente.
Al [cifrar los datos](encrypt-data.md) utilizando C3R, utilice el indicador `--tempDir` para especificar la ubicación en la que se pueden crear los archivos temporales mientras se procesa la entrada.
En la siguiente tabla se resumen el uso y los parámetros de este indicador.
| De uso | Parameters |
| --- | --- |
| Los usuarios pueden especificar la ubicación en la que se pueden crear los archivos temporales mientras se procesa la entrada. | El valor predeterminado es el directorio temporal del sistema. |
# Consultas con computación criptográfica para Clean Rooms
En este tema se proporciona información sobre cómo escribir consultas que utilicen tablas de datos cifradas mediante computación criptográfica para Clean Rooms.
**Topics**
+ [Consultas que se ramifican en NULL](#queries-branch-on-null)
+ [Asignar una columna de origen a varias columnas de destino](#queries-mapping)
+ [Usar los mismos datos para las consultas JOIN y SELECT](#queries-using-same-data)
## Consultas que se ramifican en NULL
Tener una ramificación de consulta en una instrucción NULL significa usar una sintaxis similar a `IF x IS NULL THEN 0 ELSE 1`.
Las consultas siempre se pueden ramificar en instrucciones NULL en columnas de cleartext.
Las consultas se pueden ramificar en instrucciones NULL en columnas sealed y en columnas fingerprint solo cuando el valor del parámetro **Conservar valores NULL** (`preserveNulls`) está establecido en `true`.
Las consultas que infrinjan estas restricciones pueden arrojar resultados incorrectos.
## Asignar una columna de origen a varias columnas de destino
Una columna de origen puede asignarse a varias columnas de destino. Por ejemplo, puede que desee utilizar tanto JOIN como SELECT en una columna.
Para obtener más información, consulte [Usar los mismos datos para las consultas JOIN y SELECT](#queries-using-same-data).
## Usar los mismos datos para las consultas JOIN y SELECT
Si los datos de una columna no son confidenciales, pueden aparecer en una columna de destino de cleartext, lo que permite utilizarlos para cualquier fin.
Si los datos de una columna son confidenciales y deben usarse tanto para las consultas JOIN como para las consultas SELECT, asigne dicha columna de origen a dos columnas de destino del archivo de salida. Una columna se cifra con el `type` como columna fingerprint y la otra columna se cifra con el `type` como columna sellada. La generación de esquemas interactivos del cliente de cifrado C3R sugiere sufijos de encabezado de `_fingerprint` y `_sealed`. Estos sufijos de encabezado pueden ser una convención útil para diferenciar dichas columnas rápidamente.
# 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).