O Excel expõe duas coisas chamadas "senha", e apenas uma delas é criptografia. A senha de abertura protege por meio de uma cifra real: sem ela, o arquivo não pode ser lido de forma alguma. Já as senhas de proteção de planilha e pasta de trabalho não fazem nada parecido. Elas apenas definem uma flag que um editor cooperativo concorda em respeitar, e uma pasta de trabalho que carrega apenas essa flag é um arquivo ZIP comum legível com os dados em texto simples. Escolha a opção errada e você enviará uma folha de pagamento que parece bloqueada no Excel, mas pode ser lida em qualquer editor de texto
A prova disso leva dez segundos. Renomeie um arquivo .xlsx protegido para .zip, abra-o em qualquer ferramenta de descompactação e examine o arquivo xl/worksheets/sheet1.xml. Se os valores das células estiverem lá em UTF-8 simples, o arquivo não está criptografado, não importa quantas solicitações de senha o Excel faça quando alguém tenta editar uma célula. Essa lacuna sobrevive por anos dentro de equipes que assumem que a proteção de planilhas equivale a confidencialidade, e geralmente vem à tona no dia em que uma auditoria de segurança executa exatamente esse renomeamento
O HotXLS é uma biblioteca nativa de planilhas para Delphi e C++Builder, e mantém esses dois recursos em lados opostos dessa linha. A proteção de planilha e de pasta de trabalho são restrições de edição baseadas em um hash legado deliberadamente fraco. O método SaveAsEncrypted produz um pacote criptografado por AES que nada menos do que a senha conseguirá abrir. As seções abaixo cobrem o que essa chamada grava, a assimetria com a qual você deve planejar sua arquitetura (o HotXLS grava arquivos criptografados, mas não consegue lê-los de volta) e como o caminho XLS mais antigo se diferencia
Por que a proteção de planilhas não é criptografia
Os métodos Protect nas planilhas e o ProtectWorkbook na pasta de trabalho armazenam um hash de 4 dígitos hexadecimais da senha. Esse é o algoritmo legado que o OOXML e o BIFF herdaram do Excel dos anos 1990, e a documentação do formato nunca afirma que ele faça mais do que impedir edições acidentais. O pacote continua sendo um ZIP legível comum: dados de células, fórmulas e strings compartilhadas ficam todos em XML de texto simples. O padrão torna isso pior, não melhor. Cada célula começa com Locked=True, portanto chamar Protect sem antes desbloquear um intervalo de entrada congela toda a planilha contra edições, ao mesmo tempo em que deixa todos os valores visíveis
Nada disso torna a proteção inútil. Direcionar usuários para intervalos editáveis e estabilizar um layout para impressão são tarefas reais, abordadas em nosso artigo sobre proteção de planilhas e configuração de página. Mas essas são tarefas de usabilidade. No instante em que o requisito for confidencialidade, a única API aplicável é a SaveAsEncrypted
O que o SaveAsEncrypted realmente grava
A implementação segue a Criptografia Padrão ECMA-376, especificada na seção 2.3.4 do [MS-OFFCRYPTO]. A senha passa por 50.000 iterações de SHA-1 para derivar uma chave AES-128. Um bloco verificador, criptografado com AES-128 no modo ECB, permite que um consumidor confirme a senha antes de descriptografar qualquer coisa, e todo o pacote da pasta de trabalho é então criptografado com AES-128 no modo CBC. O que vai para o disco não é um arquivo ZIP. Trata-se de um arquivo OLE composto contendo os fluxos (streams) EncryptionInfo, EncryptedPackage e DataSpaces, sem nenhum diretório xl/ para que uma ferramenta de arquivamento liste, razão pela qual o teste de renomeamento agora não revela nada legível. O Excel 2007 e posteriores o abrem apenas com a senha, e o LibreOffice atual também lê a Criptografia Standard
var
Book: TXLSXWorkbook;
Sheet: TXLSXWorksheet;
rc: Integer;
begin
Book := TXLSXWorkbook.Create;
try
Sheet := Book.Sheets.Add('Payroll');
Sheet.Cells[1, 1].Value := 'Employee';
Sheet.Cells[1, 2].Value := 'Net pay';
Sheet.Cells[2, 1].Value := 'A. Garcia';
Sheet.Cells[2, 2].Value := 4815.16;
rc := Book.SaveAsEncrypted('payroll-2026-06.xlsx', PasswordFromVault);
if rc <> 1 then
raise Exception.CreateFmt('Encrypted save failed (rc=%d)', [rc]);
finally
Book.Free;
end;
end;Trate a variável de senha com o mesmo cuidado que uma string de conexão. Busque-a de um cofre de chaves (vault) ou de um serviço de segredos gerados no último momento, nunca a registre em logs e nunca a grave na própria pasta de trabalho. A verificação do código de retorno não é uma formalidade opcional. Um salvamento criptografado que falha no meio do caminho deve abortar a entrega, porque a única alternativa de retorno (fallback) que o código chamador pode oferecer é uma cópia não criptografada, e essa cópia é exatamente o tipo de incidente que esse recurso existe para evitar
Também existe um teste de aceitação verificável por máquina que não custa quase nada: chame o método CanReadEncrypted no arquivo que você acabou de gravar. Ele retorna verdadeiro apenas quando a saída é realmente um contêiner de criptografia, de modo que verificar isso por meio de uma asserção (assert) após cada salvamento criptografado detecta a regressão que mais importa — um caminho de código que silenciosamente retornou a um SaveAs simples —, no momento em que ocorre, e não semanas depois na caixa de entrada de um cliente. A palavra final ainda pertence a uma abertura manual no Excel com a senha real durante os testes de lançamento
Somente gravação por design: tratando a exceção EXlsxEncryptionNotImplemented
Aqui está a assimetria que deve moldar a arquitetura do seu pipeline: o HotXLS criptografa ao salvar, mas não descriptografa ao abrir. O método OpenEncrypted gera a exceção EXlsxEncryptionNotImplemented quando apontado para um pacote criptografado real; em uma pasta de trabalho simples, ele apenas prossegue para um Open normal. A varredura complementar CanReadEncrypted detecta o contêiner de criptografia OLE com baixo custo computacional, de modo que o código de entrada possa rotear esses arquivos sem disparar a exceção:
var
Book: TXLSXWorkbook;
begin
Book := TXLSXWorkbook.Create;
try
if Book.CanReadEncrypted(FileName) then
begin
// Encrypted container: HotXLS cannot decrypt it.
Writeln(FileName + ': needs manual decryption in Excel first');
Exit;
end;
try
Book.OpenEncrypted(FileName, ''); // plain files fall through to Open
Writeln(FileName + ': opened, ' + IntToStr(Book.Sheets.Count) + ' sheet(s)');
except
on EXlsxEncryptionNotImplemented do
Writeln(FileName + ': encrypted - routed to manual queue');
end;
finally
Book.Free;
end;
end;Essa assimetria possui uma leitura arquitetônica clara: criptografe na borda de entrega, por último. Mantenha o mestre em texto simples dentro do seu limite de confiança — em um banco de dados, em um repositório de documentos ou em um compartilhamento com controle de acesso — e produza a cópia criptografada como a etapa final antes que o arquivo saia do sistema. Um pipeline que arquiva apenas a saída criptografada bloqueia a si mesmo de acessar seus próprios dados, porque nenhuma etapa posterior do mesmo sistema poderá reabrir esses arquivos. Quando um processo posterior do HotXLS precisar da pasta de trabalho novamente, entregue a ele o mestre em texto simples, nunca o artefato de entrega
Criptografia Padrão AES-128 e o limite de conformidade AES-256
A criptografia de arquivos do Office vem em duas gerações. A Criptografia Standard, que o HotXLS grava, usa AES-128 com derivação de chave SHA-1. A criptografia Agile chegou mais tarde e adota AES-256 com SHA-512 e um contêiner de chave diferente, descrito em XML. Ambas são abertas de forma transparente no Excel, e o AES-128 ainda é computacionalmente robusto para proteger um arquivo em trânsito para um cliente
A diferença deixa de ser acadêmica no dia em que um questionário de segurança solicita "criptografia AES-256 de arquivos em repouso." A Criptografia Standard não atende a essa exigência, não importa quão forte seja a senha, e nenhum parâmetro do SaveAsEncrypted altera o algoritmo que ele emite. Portanto, declare o perfil com precisão na sua documentação de segurança: AES-128, Criptografia Padrão ECMA-376, derivação de chave SHA-1 com 50.000 iterações. Uma afirmação defensável que sobreviva à revisão vale mais do que uma otimista que desmorona sob uma auditoria
A rota legada XLS: RC4 para gravação, RC4 e XOR para leitura
O BIFF facade tem a forma oposta. Sua criptografia é mais antiga e mais fraca, mas a viagem de ida e volta é completa: o que ele grava, também pode ler de volta. Definir o EncryptionPassword antes do SaveAs produz um arquivo .xls criptografado por RC4 através do mecanismo BIFF FilePass, e o Open com um parâmetro de senha lê todos os três esquemas legados: RC4, RC4 CryptoAPI e a antiga ofuscação XOR:
var
Writer, Reader: IXLSWorkbook; // interface refs: no manual Free
begin
Writer := TXLSWorkbook.Create;
Writer.Sheets.Add.Cells.Item[1, 1].Value := 'Confidential';
Writer.EncryptionPassword := 'S3cret!';
Writer.SaveAs('confidential.xls');
Reader := TXLSWorkbook.Create;
if Reader.Open('confidential.xls', 'S3cret!') > 0 then
Writeln(Reader.Sheets[1].Cells.Item[1, 1].Value); // Entries are 1-based
end;O RC4 é uma criptografia obsoleta e nunca deve proteger dados importantes hoje; seu único valor restante é a interoperabilidade com sistemas que ainda trocam arquivos .xls. O lado da leitura, no entanto, é muito útil em trabalhos de migração. Um arquivo legado protegido por senha é aberto com Open(FileName, Password), migra para o modelo OOXML e é protegido novamente por meio do caminho AES — uma atualização unidirecional executada sem o Excel em nenhuma parte do ciclo. Para entregas criptografadas de alto volume, as observações sobre taxa de transferência de gravação em nosso artigo sobre gravações em fluxo para tarefas em lote no servidor se aplicam à fase de construção de conteúdo que ocorre antes da criptografia
Criptografia e proteção não são rivais
Mais um ponto que vale a pena esclarecer, porque surge no momento em que alguém lê o aviso no topo desta página como "a proteção é inútil." Não é. Criptografia e proteção respondem a perguntas diferentes e se acumulam perfeitamente. A criptografia decide quem pode abrir o arquivo; a proteção decide o que um leitor que já está dentro dele pode alterar. Uma entrega de folha de pagamento pode razoavelmente fazer as duas coisas: criptografar o pacote para que apenas o portador da senha o veja e, em seguida, bloquear as células de fórmulas para que o destinatário possa filtrar e ordenar, mas não reescrever silenciosamente os cálculos. O erro nunca é adicionar proteção. O erro é deixar que sua presença substitua a criptografia quando o requisito for confidencialidade
O lado da custódia de senhas não possui rede de segurança, e isso ocorre por design. A derivação de chave de 50.000 iterações existe para tornar a adivinhação cara, e nada dentro do arquivo serve como depósito de segurança (escrow) para o segredo. Uma senha perdida significa dados perdidos. Gere, entregue e armazene essas senhas com a mesma disciplina que você aplica a credenciais de banco de dados, e a criptografia cumprirá o seu papel
A criptografia real de arquivos é feita por uma única chamada no HotXLS. A disciplina reside em tudo ao redor da chamada: a custódia da senha, o limite de somente gravação que impede o HotXLS de reabrir sua própria saída e uma declaração de algoritmo que você possa defender em uma auditoria. O SaveAsEncrypted e a viagem de ida e volta legada são fornecidos com o HotXLS Component, rodando nativamente em processos Delphi e C++Builder sem automação do Excel em qualquer lugar do caminho