Qual é o tamanho máximo permitido para o nome de arquivo (e pasta) com o eCryptfs?

44

Sou um novo usuário do eCryptfs e tenho uma pergunta muito básica que não consegui encontrar em nenhum lugar. Estou interessado em usar o eCryptfs através do meu Synology NAS que usa Linux.

Ao tentar criptografar minha pasta (EXT4) por meio do aplicativo de criptografia da Synology (eCryptfs), encontro erros que indicam que o tamanho do meu nome de arquivo não pode exceder 45 caracteres (portanto, sem criptografia).

Se o limite é realmente de 45 caracteres, o eCryptfs pode não ser uma ferramenta utilizável para a maioria.

Qual é o tamanho máximo permitido para o nome de arquivo ao criptografar arquivos e pastas com o eCryptfs? O Linux é 255 caracteres?

filenames ecryptfs synology

— Fabry
fonte

6

A maneira como o ecryptfs criptografa os nomes de arquivos é ridícula. Primeiro, ele fornece mais de 20 bytes acrescentando uma string fixa "ECRYPTFS_FNEK_ENCRYPTED". para cada nome de arquivo. Em seguida, acrescenta muitos bytes aleatórios para que nomes idênticos pareçam diferentes. O EncFS faz isso de uma maneira muito mais eficiente.

70

Divulgação completa: Sou um dos autores e atual mantenedor dos utilitários de espaço de usuário do eCryptfs.

Ótima pergunta!

O Linux possui um tamanho máximo de nome de arquivo de 255 caracteres para a maioria dos sistemas de arquivos (incluindo EXT4) e um caminho máximo de 4096 caracteres.

O eCryptfs é um sistema de arquivos em camadas. Ele empilha em cima de outro sistema de arquivos, como o EXT4, que é realmente usado para gravar dados no disco. O eCryptfs sempre criptografa o conteúdo do arquivo, mas opcionalmente pode criptografar os nomes de arquivos (obscuros) (ou não).

Se os nomes de arquivos não estiverem criptografados, você poderá gravar com segurança nomes de arquivos com até 255 caracteres e seu conteúdo, pois os nomes de arquivos gravados no sistema de arquivos inferior serão compatíveis. Embora um invasor não consiga ler o conteúdo de index.htmlou budget.xls, ele saberá quais nomes de arquivos existem. Isso pode (ou não) vazar informações confidenciais, dependendo do seu caso de uso.

Se os nomes de arquivos são criptografados, as coisas ficam um pouco mais complicadas. O eCryptfs acrescenta um pouco de dados na frente do nome do arquivo criptografado, para que ele possa identificar definitivamente os nomes de arquivos criptografados. Além disso, a criptografia em si envolve "preencher" o nome do arquivo.

Por exemplo, eu tenho um arquivo criptografado ~/.bashrc,. Este nome de arquivo é criptografado usando minha chave para:

/home/kirkland/.Private/ECRYPTFS_FNEK_ENCRYPTED.dWek2i3.WxXtwxzQdkM23hiYK757lNI7Ydf0xqZ1LpDovrdnruDb1-5l67.EU--

Claramente, esse nome de arquivo com 7 caracteres agora exige que mais de 7 caracteres sejam criptografados. Empiricamente, descobrimos que os nomes de arquivos com mais de 143 caracteres começam a exigir> 255 caracteres para criptografar. Portanto, nós (como desenvolvedores do eCryptfs upstream) normalmente recomendamos que você limite seus nomes de arquivos para ~ 140 caracteres.

Agora, tudo isso dito, o Synology NAS é um produto comercial que incorpora e usa eCryptfs e Linux para criptografar e proteger dados no dispositivo. Nós (os desenvolvedores upstream do eCryptfs) não temos nada a ver com a Synology ou seus produtos, embora geralmente gostemos de ver o eCryptfs usado na natureza . Parece-me que a recomendação de 45 caracteres é um erro tipográfico (da recomendação de 140 caracteres) ou simplesmente uma estimativa muito mais conservadora.

— Dustin Kirkland
fonte

Eu adoraria ver que o FUSE sobrepõe o sistema de arquivos que resolve por si próprio "nomes de arquivos muito longos" e fica apenas com proxy 1: 1 com o sistema de arquivos subjacente. Esses FUSE fs seriam úteis para diferentes sistemas de arquivos (ecryptfs, EncFS), enquanto os nomes de arquivos atualmente suportados não mudariam nada. E, novamente, seria opcional. - Meu desejo: unix.stackexchange.com/q/283149/9689

— Grzegorz Wierzowiecki

17

Esta resposta não está totalmente correta. O tamanho máximo de um nome de arquivo é de 255 bytes ou tipos de caracteres C / C ++. Mas o máximo de caracteres em um nome de arquivo varia. Ao usar UTF-8, que é o padrão para a maioria dos sistemas, o nome do arquivo pode ter entre 63 a 255 caracteres (também conhecido como Code Points), se você estiver usando UTF-16, 63-127. É importante observar que 1 caractere pode ter um ou mais bytes no espaço de armazenamento e depende do conjunto de códigos que o usuário do sistema está usando.

— Rahly 30/05

Sugestão para o desenvolvedor: divida os nomes criptografados em subdiretórios ocultos do usuário final para obter o comprimento necessário, excedendo potencialmente o limite máximo de comprimento máximo do nome do linux, se um sistema de arquivos externo precisar. Um único arquivo ou diretório se torna "ENCRYPTFS-01-OF-04 [.....] / ENCRYPTFS-02-OF-04 [.....] / ENCRYPTFS-03-OF-04 [..... ] / ENCRYPTFS-04-OF-04 [.....] "- Linux btrfs, ext1-4 e outros não possuem profundidade máxima de diretório definida, para que o sistema de arquivos possa lidar com a expansão de nomes de arquivos e diretórios em vários subdiretórios não expostos como este .

— Dale Mahalko

1

Minha sugestão seria armazenar os metadados que você está armazenando nos xattrs, em vez de no nome do arquivo. : |

— precisa saber é o seguinte

1

Você diz que o eCryptfs "pode opcionalmente criptografar nomes de arquivos (obscuros) (ou não)". Como desabilito a criptografia de nome de arquivo para recuperar meus nomes completos de 255 caracteres em vez de limitar-me a 143 caracteres? A propósito, acredito que a maneira como eu instalei o eCryptfs foi marcando a caixa ou o que for "Diretório inicial criptografado" durante o processo de instalação do Ubuntu.

— Gabriel Staples

11

Esse tópico é muito interessante, porque eu estava pensando exatamente a mesma coisa. Posso conviver com a necessidade de renomear 20 arquivos de 50.000 se os nomes de arquivos precisarem ter 140 caracteres ou menos, mas 45 ou menos não é possível (na minha situação), porque seria necessário renomear muitos arquivos.

Fiz exatamente a mesma pergunta diretamente à Synology (mesmo apontando para o presente artigo), e a resposta foi interessante: "O limite do nome do arquivo do compartilhamento criptografado é de 143 bytes. Pode ter até 140 caracteres latinos puros ou 45 CJK (chinês , Japonês e coreano) ".

Após esta resposta, fiz mais testes, testando arquivos com 45, 46, 140, 143 e 144 caracteres. Meus testes mostram que arquivos com até 143 caracteres (não bytes, ao contrário do que a Synology me disse) serão criptografados, mas arquivos com 144 caracteres impedirão que uma pasta seja criptografada. No entanto, a mensagem de erro que recebo do meu NAS é que o nome do arquivo precisa ter menos de 45 caracteres (enquanto a realidade é que deve ter menos de 144 caracteres).

Eu não fiz testes com caracteres CJK ... Mas, para quem está lendo isso, parece que você está bem até 143 caracteres, apesar do que o sistema diz.

— sdasdrewr
fonte

7

Gostaria de esclarecer que o linux tem um limite de 255 bytes por nome de arquivo, não 255 caracteres. Essa é uma diferença significativa e, se você usar, por exemplo, codificação UTF-8, poderá acabar com nomes de arquivos com no máximo 100 caracteres.

— Richard Jelinek
fonte

1

63 é o máximo se cada caractere usar a codificação máxima de 4 bytes por ponto de código. É o mesmo para qualquer um dos esquemas UTF (UTF-16 e UTF-32)

— Rahly

@Rahly Isso pode eventualmente mudar, no entanto. Antes que o ponto de código máximo Unicode válido fosse reduzido para U+10FFFFatender às limitações do UCS-2 (basicamente UTF-16 sem pares substitutos), o UTF-8 poderia exigir até 6 bytes para representar um ponto de código de 32 bits devido à maneira como codifica "início do caractere" e "continuação do caractere" para garantir que a sincronização do analisador possa ser adquirida novamente, não importa onde você comece a analisar em um fluxo de bytes. É sempre possível que eles decidam reverter essa decisão porque estão ficando sem pontos de código não atribuídos.

— #

1

Mas altamente improvável, a menos que eles comecem a adicionar personagens como loucos. A partir do U8.0, apenas 120k são atribuídos. Eles adicionaram ~ 8k caracteres nesta iteração. Se eles continuarem, será necessário expandir na versão ~ 106.

— Rahly

E acho que eles também teriam que matar o Windows e o JavaScript primeiro, já que ambos dependem do UTF-16. (Ele pode ser possível corrigir esta situação no caso de JavaScript, embora?)

— Samb

1

O comprimento do nome do arquivo ecrypt foi apenas um problema para mim, pois eu precisava de uma subárvore específica do meu diretório home para suportar nomes de arquivos longos e, finalmente, percebi que poderia simplesmente criar um sistema de arquivos dentro de um arquivo e montar:

dd if=/dev/zero of=/home/me/.some.img bs=1024 count=1024
mkfs.ext3 /home/me/.some.img
chmod 777 /home/me/longfilenames
sudo mount /home/me/.some.img /home/me/longfilenames

Provavelmente, existem todos os tipos de problemas de eficiência com isso, mas é suficiente para o meu caso, em que os arquivos são apenas resultados de testes criados periodicamente para meus próprios objetivos locais.

Meus colegas colocaram sua imagem em / tmp - os dados do teste não são particularmente confidenciais: queremos principalmente proteger nosso código-fonte, não nossos resultados.

— android.weasel
fonte