prestodb/presto · error · ParquetCryptoRuntimeException

Column encrypted with footer key in file with plaintext foot

Error message

Column encrypted with footer key in file with plaintext footer

What it means

A column's crypto metadata declares ENCRYPTION_WITH_FOOTER_KEY (the column is encrypted with the same key as the footer), but the footer itself was read as plaintext. The library throws because in a plaintext-footer file every encrypted column must use its own column key; footer-key encryption is only valid when the footer is encrypted (otherwise there is no footer key to recover).

Source

Thrown at presto-parquet/src/main/java/com/facebook/presto/parquet/cache/MetadataReader.java:224

                                    || (filePath != null && filePath.equals(columnChunk.getFile_path())),
                            "all column chunks of the same row group must be in the same file");

                    ColumnMetaData metaData = columnChunk.meta_data;
                    ColumnCryptoMetaData cryptoMetaData = columnChunk.getCrypto_metadata();
                    ColumnPath columnPath = null;
                    boolean encryptedMetadata = false;

                    if (null == cryptoMetaData) { // Plaintext column
                        columnPath = getPath(metaData);
                        if (fileDecryptor.isPresent() && !fileDecryptor.get().plaintextFile()) {
                            // mark this column as plaintext in encrypted file decryptor
                            fileDecryptor.get().setColumnCryptoMetadata(columnPath, false, false, (byte[]) null, columnOrdinal);
                        }
                    }
                    else {  // Encrypted column
                        if (cryptoMetaData.isSetENCRYPTION_WITH_FOOTER_KEY()) { // Column encrypted with footer key
                            if (!encryptedFooter) {
                                throw new ParquetCryptoRuntimeException("Column encrypted with footer key in file with plaintext footer");
                            }
                            if (null == metaData) {
                                throw new ParquetCryptoRuntimeException("ColumnMetaData not set in Encryption with Footer key");
                            }
                            if (!fileDecryptor.isPresent()) {
                                throw new ParquetCryptoRuntimeException("Column encrypted with footer key: No keys available");
                            }
                            columnPath = getPath(metaData);
                            fileDecryptor.get().setColumnCryptoMetadata(columnPath, true, true, (byte[]) null, columnOrdinal);
                        }
                        else { // Column encrypted with column key
                            try {
                                // TODO: We decrypted data before filter projection. This could send unnecessary traffic to KMS. This so far not seen a problem in production.
                                // In parquet-mr, it uses lazy decryption but that required to change ColumnChunkMetadata. We will improve it later.
                                EncryptionWithColumnKey columnKeyStruct = cryptoMetaData.getENCRYPTION_WITH_COLUMN_KEY();
                                List<String> pathList = columnKeyStruct.getPath_in_schema();
                                byte[] columnKeyMetadata = columnKeyStruct.getKey_metadata();
                                columnPath = ColumnPath.get(pathList.toArray(new String[pathList.size()]));

View on GitHub (pinned to 55bb57d202)

Solutions

Regenerate the file with a compliant encryption-aware writer (parquet-mr with column encryption configured correctly)
If columns are truly footer-key encrypted, re-write the file with an encrypted footer
Check the writing library version — some older writers emitted inconsistent plaintext-footer/footer-key combos
If the file is actually unencrypted, read it without a decryptor so this branch isn't taken

Example fix

// before: writer config mismatch
conf.set("parquet.encryption.column.keys", "keyA: col.ssn"); // footer left plaintext
// after
conf.set("parquet.encryption.footer.key", "footerKey"); // footer-key columns require encrypted footer

Defensive patterns

Strategy: try-catch

Try / catch

try {
    readParquetMetadata(dataSource);
} catch (ParquetCryptoRuntimeException e) {
    if (e.getMessage().contains("encrypted with footer key in file with plaintext footer")) {
        // treat file as corrupt/nonconformant: surface a table-read error
        throw new DataCorruptionException(file, e);
    } else throw e;
}

Prevention

Write encrypted Parquet only with spec-compliant writers (parquet-mr >= encryption support)
Always configure a footer key when using footer-key-encrypted columns
Round-trip validate encrypted files after writing

When it happens

Trigger: convertToParquetMetadata processes a column chunk whose cryptoMetaData has ENCRYPTION_WITH_FOOTER_KEY set while encryptedFooter is false (plaintext footer read mode).

Common situations: Corrupt or hand-edited Parquet files mixing plaintext footers with footer-key-encrypted columns; files written by nonconformant writers that misuse the encryption metadata fields; version mismatch between writer and reader encryption spec interpretation.

Related errors

AI-assisted analysis of prestodb/presto@55bb57d202 (2026-09-04). Data as JSON: /api/errors/e92b720adc9bf37e. Report an issue: GitHub.