dd, cat & openssl: tamanho do bloco e tamanho do buffer

1

Aqui ele diz que ao usar dd a dm-crypt para sobrescrever um dispositivo de bloco, somente o tamanho padrão do bloco dd deve ser usado porque o tamanho do bloco dm-crypt é o mesmo (512 bytes) e aumentar o tamanho do bloco de dd pode impedir que os blocos finais sejam gravados para.

Isso também se aplica a openssl (no Linux)?

Aqui Gilles diz que o padrão buffer do openssl tamanho é 8kB. O tamanho do buffer é o mesmo que o tamanho do bloco neste contexto?

Dado que o tamanho de bloco padrão de dd é 512, se eu quisesse usar um tamanho de bloco de 1M em dd , eu também teria que definir -bufsize para o mesmo número de openssl ? É -bufsize em bytes?

Da mesma forma, é desaconselhável usar cat a openssl , dado que o tamanho de bloco padrão (e não configurável) de cat é 128kB?

    
por EmmaV 11.12.2015 / 03:51

1 resposta

2

TLDR não importa (se eu acertar)

Primeiro, a linha de comando openssl faz cerca de 50 coisas diferentes; apenas dois deles recebem dados de entrada em massa: enc para criptografar ou descriptografar um "arquivo" ou codificar / decodificar base64 como um caso especial que não é realmente criptografia e dgst para hash e, opcionalmente, assinar ou verificar um "arquivo ". Desses, apenas enc produz saída que poderia ser útil para "sobrescrever" alguma coisa, então eu suponho que você quer dizer isso; rand também pode produzir saída em massa, mas não vinculada a nenhuma entrada.

Em segundo lugar, o problema em a pergunta que você vinculou é atraso devido à espera por um bloco de dados de cifra ou por um pedaço de codificação (base64) pela rede . Se você está preocupado apenas em obter resultados corretos, o atraso não importa, e se a fonte não for remota, ela não será atrasada de qualquer maneira.

openssl enc usando uma cifra e modo de bloco , particularmente CBC que é o padrão, por padrão usa PKCS # 5 padding (assim chamado; oficialmente é PKCS # 7 com base no PKCS # 5, mas muitas pessoas, incluindo o OpenSSL, apenas dizem PKCS # 5). Isso permite que ele criptografe e decriptografe qualquer número de bytes de dados que caibam em um "arquivo" de entrada e saída, como suportado pelo SO e sistema de arquivos. O arquivo criptografado (com preenchimento adicionado) é sempre um múltiplo exato do tamanho do bloco da cifra usada. Para criptografia baseada em senha com salt, também o padrão, o texto cifrado é de até 32 bytes a mais do que o texto simples, portanto, na criptografia, talvez seja necessário permitir isso. Se você especificar -nopad (para um cifra / modo de bloco), o preenchimento será desativado e o texto simples deverá ser um múltiplo exato do tamanho do bloco de cifras. Se não for, um erro ocorre e a saída está incompleta - embora geralmente não vazia, o que pode confundir pessoas ou scripts / etc inseguros em pensar que é válido quando não é.

Se você usar uma cifra de fluxo (atualmente apenas RC4) ou um modo de fluxo de uma cifra de bloco (CFB OFB CTR) nenhum preenchimento é necessário ou usado e o texto simples pode ser qualquer número de bytes (que se encaixam em arquivos). Para PBE com salt, o texto cifrado ainda é maior em 16 bytes. (Aviso: algumas versões listam erroneamente os modos CCM e GCM como suportados em enc ; eles não funcionam realmente se você tentar usá-los.)

-bufsize é (apenas) o tamanho usado para ler e gravar dados. Ele não precisa estar relacionado ao tamanho do bloco da cifragem, embora, por padrão, seja uma potência média de 2 e os blocos de tamanho de todas as cifras de bloco suportadas sejam pequenas potências de 2, de modo que elas se dividam uniformemente. A lógica da cifra manipula grandes dados como um fluxo dividido em partes de qualquer tamanho ou tamanho; apenas o comprimento total é importante. Mas é menos eficiente lidar com lotes de pequenos pedaços porque faz mais chamadas para a biblioteca C e (muitas vezes) SO.

cat piped em openssl enc input está bom, embora se ele ler apenas um "arquivo" não há benefício em apenas fazer com que o arquivo stdin (redirecionado) de openssl , ou o argumento -in . Da mesma forma, não há mal nem benefício em usar dd se apenas copia os dados; se você usar qualquer uma das outras funcionalidades de dd como converter EBCDIC e / ou registros de tamanho fixo (típico de dados de mainframe IBM), obviamente, isso é necessário. E se você quiser as estatísticas sobre 1234+0 records in etc, você precisa de dd ou similar.

    
por 11.12.2015 / 13:16