本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

C3R 加密用戶端的準則

C3R 加密用戶端是一種工具，可讓組織將敏感資料整合在一起，從資料分析中獲得新的見解。該工具加密限制了任何一方和過程 AWS 中可以學到的內容。雖然這非常重要，但以密碼方式保護資料安全的程序可能會在運算和儲存資源方面增加顯著的額外負荷。因此，了解使用每個設置的權衡以及如何優化設置，同時仍保持所需的密碼編譯保證是非常重要的。本主題著重於 C3R 加密用戶端和結構描述中不同設定的效能影響。

所有 C3R 加密用戶端加密設定都提供不同的加密保證。在預設情況下，協同作業層級設定最安全。在建立協同作業的同時啟用其他功能會削弱隱私保證，從而允許對密文進行頻率分析等活動。如需有關如何使用這些設定及其含意的更多資訊，請參閱密碼編譯運算 Clean Rooms。

對資料行類型的效能影響

C3R 使用三種資料行類型：cleartextfingerprint、和。sealed這些欄類型中的每一種都提供不同的密碼編譯保證，並具有不同的預期用途。在下列各節中，我們會討論資料欄類型對效能的影響，以及每個設定對效能的影響。

Cleartext列

Cleartext列不會從其原始格式更改，也不會以任何方式加密處理。此資料行類型無法設定，也不會影響儲存體或運算效能。

Fingerprint列

Fingerprint列是為了用於跨多個表加入數據。為此，產生的密文大小必須始終相同。不過，這些欄會受到協同作業層級設定的影響。 Fingerprint欄可能會對輸出檔案大小產生不同程度的影響，具體取決於輸入中cleartext包含的大小。

fingerprint列的基本開銷

有fingerprint列的基本開銷。這種開銷是恆定的，並代替cleartext字節的大小。

資料行中的資fingerprint料是透過雜湊型訊息驗證碼 (HMAC) 函式以密碼編譯方式處理，該函式會將資料轉換成 32 位元組訊息驗證碼 (MAC)。然後通過 base64 編碼器處理此數據，將字節大小增加了大約 33％。它會預先加上 8 位元組的 C3R 指定，以指定資料所屬的資料行類型以及產生資料行的用戶端版本。最終結果是 52 個字節。然後，將此結果乘以行計數以獲得總基本開銷（如果preserveNulls設置為 true，則使用非總null值的數量）。

下圖顯示了如何 BASE_OVERHEAD = C3R_DESIGNATION + (MAC * 1.33)

fingerprint列中的輸出密文將始終是 52 個字節。如果輸入cleartext資料的平均值超過 52 個位元組 (例如，完整的街道位址)，這可能會大幅減少儲存空間。如果輸入cleartext資料的平均值小於 52 個位元組 (例如，客戶年齡)，這可能會大幅增加儲存空間。

fingerprint欄的協同合作設定

preserveNulls 設定

當協同作業層級設定preserveNulls為 false (預設值) 時，每個null值都會以唯一的隨機 32 位元組取代，並以不相同的方式進行處理。null結果是，每個null值現在是 52 個字節。對於包含非常稀疏資料的資料表，這可能會增加顯著的儲存需求，相較於此設定為true且null值傳遞為null時間。

如果您不需要此設定的隱私權保證，而且偏好在資料集中保留null值，請在建立共同作業時啟用該preserveNulls設定。建preserveNulls立共同作業之後，就無法變更設定。

資料fingerprint欄的範例資料

以下是一組輸入和輸出資料的範例集，其fingerprint中包含要重現的設定。其他協作層級的設定，例如allowCleartext和allowDuplicates不影響結果，可以設定為true或false嘗試在本機複製。

共用密碼範例：wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

協同作業 ID 範例：a1b2c3d4-5678-90ab-cdef-EXAMPLE11111

allowJoinsOnColumnsWithDifferentNames：True此設定不會影響效能或儲存需求。但是，當複製下表中顯示的值時，此設定會使欄名稱選擇不相關。

疑難排解fingerprint欄

為什麼我的fingerprint列中的密文比進入cleartext它的大小大幾倍？

fingerprint列中的密文總是長度為 52 個字節。如果您輸入的數據很小（例如，客戶的年齡），則規模將顯著增加。如果preserveNulls設定設定為，也可能發生這種情況false。

為什麼我的fingerprint列中的密文比進入cleartext它的大小小小幾倍？

fingerprint列中的密文總是長度為 52 個字節。如果您輸入的數據很大（例如，客戶的完整街道地址），則大小將顯著減少。

我如何知道我是否需要由提供的加密保證？preserveNulls

不幸的是，答案是，這取決於。至少密碼計算參數應檢閱preserveNulls設定如何保護您的資料。不過，我們建議您參考組織的資料處理要求，以及適用於個別協同合作的任何合約。

為什麼我必須承擔 base64 的開銷？

為了允許與表格文件格式（例如 CSV）的兼容性，需要 base64 編碼。雖然某些檔案格式 (例如) Parquet 可能支援資料的二進位表示，但協同合作中的所有參與者都必須以相同的方式表示資料，以確保正確的查詢結果。

Sealed列

Sealed列是為了用於在協作的成員之間傳輸數據。這些資料行中的密碼文字不具決定性，並且會根據資料行的設定方式，對效能和儲存有重大影響。您可以個別設定這些資料行，而且通常會對 C3R 加密用戶端的效能和產生的輸出檔案大小造成最大的影響。

sealed列的基本開銷

有sealed列的基本開銷。此開銷是恆定的，除了和填充（如果有cleartext的話）字節的大小之外。

在進行任何加密之前，資料行中的資sealed料會預先加上 1 個位元組字元，以指定所包含的資料類型。如果選擇填充，則數據被填充並附加 2 個字節，說明墊大小。新增這些位元組之後，會使用 AES-GCM 以密碼編譯方式處理資料，並使用 IV (12 位元組)、(32 位元組) 和 nonce Auth Tag (16 位元組) 來儲存資料。然後通過 base64 編碼器處理此數據，將字節大小增加了大約 33％。資料會預先加上 7 位元組 C3R 指定，以指定資料所屬的資料行類型，以及用來產生資料行的用戶端版本。結果是 91 個字節的最終基本開銷。然後，該結果可以乘以行計數以獲得總基本開銷（如果preserveNulls設置為 true，則使用非空值的總數）。

下圖顯示了如何 BASE_OVERHEAD = C3R_DESIGNATION + ((NONCE + IV + DATA_TYPE + PAD_SIZE + AUTH_TAG) * 1.33)

sealed欄的協同合作設定

preserveNulls 設定

當協同作業層級設定preserveNulls為 false (預設值) 時，每個null值都是唯一的，隨機 32 個位元組，並且會像處理不一樣。null結果是，每個null值現在是 91 個字節（如果填充更多）。對於包含非常稀疏資料的資料表，這可能會增加顯著的儲存需求，相較於此設定為true且null值傳遞為null時間。

如果您不需要此設定的隱私權保證，而且偏好在資料集中保留null值，請在建立共同作業時啟用該preserveNulls設定。建preserveNulls立共同作業之後，就無法變更設定。

結構描述設定sealed欄：填補類型

墊片類型 none

選取的焊接類型none不會增加任何填充，cleartext並且不會為前面描述的基本開銷增加額外的開銷。沒有填充會產生最節省空間的輸出大小。但是，它不提供fixed與和max填充類型相同的隱私保證。這是因為底層的大小可以cleartext從密文的大小中辨別出來。

墊片類型 fixed

選取的填補類型fixed是隱私權保留計量，用於隱藏欄中包含的資料長度。這是通過在加密pad_length之前填充所提供的所有內cleartext容來完成的。任何超過該大小的資料都會導致 C3R 加密用戶端失敗。

鑑於填充在加密cleartext之前已添加到填充，因此 AES-GCM 具有對應到密文字節的 1 對 1。cleartext基礎 64 編碼將增加 33%。填充的額外存儲開銷可以通過cleartext從的值中減去的平均長度pad_length並將其乘以 1.33 來計算。其結果是每個記錄填充的平均開銷。然後，該結果可以乘以行數以獲得總填充開銷（如果preserveNulls設置為，則使用非總null值的數量true）。

PADDING_OVERHEAD = (PAD_LENGTH - AVG_CLEARTEXT_LENGTH) * 1.33 * ROW_COUNT

我們建議您選取包pad_length含欄中最大值的最小值。例如，如果最大值為 50 個字節，則 50 pad_length 的 a 就足夠了。大於此值的值只會增加額外的儲存空間負荷。

固定填充不會增加任何顯著的計算開銷。

墊片類型 max

選取的填補類型max是隱私權保留計量，用於隱藏欄中包含的資料長度。這是通過在加密pad_length之前cleartext將列中的所有值填充到最大值以及其他值來完成的。通常，max填充提供與單個數據集fixed填充相同的保證，同時允許不知道列中的最大cleartext值。但是，max填充可能不會提供與跨更新fixed填充相同的隱私保證，因為個別資料集中的最大值可能會有所不同。

我們建議您在使用max填充時選取額外pad_length的 0。此長度會填補所有值，使其大小與欄中的最大值相同。大於此值的值只會增加額外的儲存空間負荷。

如果指定欄中已知最大cleartext值，建議您改用fixed墊片類型。使用fixed填補可在更新的資料集間建立一致 使用max填補會導致數據的每個子集被填充到子集中的最大值。

資料sealed欄的範例資料

以下是一組輸入和輸出資料的範例集，其sealed中包含要重現的設定。其他協同作業層級的設定 allowCleartextallowJoinsOnColumnsWithDifferentNames，例如、且allowDuplicates不會影響結果，而且可以設定為true或false嘗試在本機複製。雖然這些是要重現的基本設定，但sealed資料行是不具決定性的，而且每次都會變更值。目標是顯示與字節輸出相比的字節。範例pad_length值是有意選擇的。它們表明fixed填充結果與使用建議的最小pad_length設置max填充或需要其他填充時的填充相同的值。

共用密碼範例：wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

協同作業 ID 範例：a1b2c3d4-5678-90ab-cdef-EXAMPLE11111

墊片類型 none

墊片類型 fixed (範例 1)

在這個例子中，pad_length是 62，最大的輸入是 62 字節。

墊片類型 fixed (範例 2)

在這個例子中，pad_length是 162，最大的輸入是 62 字節。

墊片類型 max (範例 1)

在此範例中，pad_length為 0，最大輸入為 62 個位元組。

墊片類型 max (範例 2)

在這個例子中，pad_length是 100，最大的輸入是 62 字節。

疑難排解sealed欄

為什麼我的sealed列中的密文比進入cleartext它的大小大幾倍？

這取決於幾個因素。首先，Cleartext列中的密文總是至少為 91 字節的長度。如果您輸入的數據很小（例如，客戶的年齡），則規模將顯著增加。其次，如果設置preserveNulls為，false並且您的輸入數據包含大量的null值，那麼這些null值中的每一個都將被轉換為 91 字節的密文。最後，如果您使用填充，根據定義，字節被加密之前添加到cleartext數據中。

我在一sealed列中的大部分數據都非常小，我需要使用填充。我可以刪除大值並單獨處理它們以節省空間嗎？

我們不建議您移除較大的值並個別處理它們。這樣做會變更 C3R 加密用戶端所提供的隱私權保證。作為威脅模型，假設觀察者可以看到兩個加密的數據集。如果觀察者看到一個數據子集的列填充顯著大於或少於另一個子集，他們可以對每個子集中的數據的大小進行推論。例如，假設fullName資料行在一個檔案中填滿總共 40 個位元組，而且在另一個檔案中填補到 800 個位元組。觀察者可能會假設一個數據集包含世界上最長的 name747 字節）。

使用填充類型時是否需要提供額外的max填充？

沒有 使用max填補時，我們建議將 (也稱為超出欄中最大值的額外填充) 設定為 0。pad_length

我可以在使用fixed填充pad_length時選擇一個大號，以避免擔心最大值是否適合？

是的，但是較大的墊片長度效率低下，並且使用了比必要的更多存儲空間。我們建議您檢查以查看最大值的大小，並將其設定pad_length為該值。

我如何知道我是否需要由提供的加密保證？preserveNulls

不幸的是，答案是，這取決於。至少密碼編譯運算 Clean Rooms應檢閱preserveNulls設定如何保護您的資料。不過，我們建議您參考組織的資料處理要求，以及適用於個別協同合作的任何合約。

為什麼我必須承擔 base64 的開銷？

為了允許與表格文件格式（例如 CSV）的兼容性，需要 base64 編碼。雖然某些檔案格式 (例如) Parquet 可能支援資料的二進位表示，但協同合作中的所有參與者都必須以相同的方式表示資料，以確保正確的查詢結果。

疑難排解密文大小意外增加

假設您加密了數據，並且生成的數據的大小非常大。下列步驟可協助您識別大小增加的位置，以及您可以採取的動作 (如果有的話)。

確定大小增加發生的地方

在疑難排解加密資料大於資料的原因之前，您cleartext必須先確定大小增加的位置。 Cleartext列可以安全地被忽略，因為它們是不變的。查看剩餘的fingerprint和sealed列，然後選擇一個看起來很重要的列。

確定大小增加發生的原因

資fingerprint料行或sealed資料行可能會導致大小增加。

大小增加是來自fingerprint列嗎？

如果最有助於增加儲存空間的資料行是一個資料fingerprint欄，這可能是因為cleartext資料很小 (例如，客戶年齡)。每個產生的fingerprint密文長度為 52 個位元組。不幸的是，沒有什麼可以做這個問題的 column-by-column 基礎上。如需詳細資訊，請參閱此fingerprint列的基本開銷資料行的詳細資訊，包括它如何影響儲存需求。

fingerprint欄中大小增加的另一個可能原因是協同作業設定preserveNulls。如果停用的協同作業設定 (預設設定)，fingerprint資料行中的所有null值都會變成 52 個位元組的加密文字。preserveNulls在目前的協同合作中，沒有任何事情可以做到這一點。建立協同作業時會preserveNulls設定此設定，且所有協同合作者都必須使用相同的設定，才能確保查詢結果正確無誤。有關preserveNulls設置以及啟用它如何影響數據的隱私保證的更多信息，請參閱。密碼編譯運算 Clean Rooms

大小增加是來自sealed列嗎？

如果最有助於增加儲存空間的資料行是一個資料sealed欄，則有一些細節可能會導致大小增加。

如果數cleartext據很小（例如，客戶年齡），則每個產生的sealed密文長度至少為 91 個字節。不幸的是，對此問題無法做任何事情。如需詳細資訊，請參閱此sealed列的基本開銷資料行的詳細資訊，包括它如何影響儲存需求。

sealed列中存儲增加的第二個主要原因是填充。填充會在加密cleartext之前將額外的位元組加入，以隱藏資料集中個別值的大小。我們建議您將數據集的填充設置為最小可能的值。至少，fixed填充必須設置pad_length為包含列中的最大可能值。任何比這更高的設置都不會增加額外的隱私保證。例如，如果您知道資料行中的最大可能值可以是 50 個位元組，建議您將設定pad_length為 50 個位元組。不過，如果資sealed料行使用max填充，我們建議您將設定pad_length為 0 個位元組。這是因為max填充指的是超出列中最大值的附加填充。

sealed欄中大小增加的最後可能原因是協同合作設定preserveNulls。如果停用的協同作業設定 (預設設定)，sealed資料行中的所有null值都會變成 91 位元組的加密文字。preserveNulls在目前的協同合作中，沒有任何事情可以做到這一點。此preserveNulls設定是在建立協同合作時設定的，且所有協同合作者都必須使用相同的設定，才能確保查詢結果正確無誤。有關此設置的更多信息以及啟用它如何影響數據的隱私保證，請參閱。密碼編譯運算 Clean Rooms