eCryptfs에서 허용되는 최대 파일 이름 (및 폴더) 크기는 얼마입니까?

44

저는 새로운 eCryptfs 사용자이며 어디에서나 찾을 수 없다는 매우 기본적인 질문이 있습니다. Linux를 사용하는 Synology NAS를 통해 eCryptfs를 사용하고 싶습니다.

Synology의 암호화 앱 (eCryptfs)을 통해 내 폴더 (EXT4)를 암호화하려고 할 때 파일 이름 길이가 45자를 초과 할 수 없다는 오류가 발생합니다 (암호화 없음).

제한이 실제로 45자인 경우 eCryptfs는 대부분 사용 가능한 도구가 아닐 수 있습니다.

eCryptfs로 파일 및 폴더를 암호화 할 때 허용되는 최대 파일 이름 크기는 얼마입니까? 리눅스는 255 자입니까?

filenames ecryptfs synology

— 파브리
소스

6

ecryptfs가 파일 이름을 암호화하는 방식은 어리석은 일입니다. 먼저 고정 문자열 "ECRYPTFS_FNEK_ENCRYPTED"를 추가하여 20 바이트 이상을 제공합니다. 각 파일 이름에. 그런 다음 동일한 이름을 다르게 보이기 위해 너무 많은 임의 바이트를 추가합니다. EncFS는 훨씬 효율적인 방식으로이를 수행합니다.

70

전체 공개 : 저는 eCryptfs 사용자 공간 유틸리티의 저자이자 현재 관리자입니다.

좋은 질문입니다!

Linux는 대부분의 파일 시스템 (EXT4 포함)의 최대 파일 이름 길이가 255 자이며 최대 경로는 4096 자입니다.

eCryptfs 는 계층 파일 시스템입니다. EXT4와 같은 다른 파일 시스템 위에 쌓이며 실제로 디스크에 데이터를 쓰는 데 사용됩니다. eCryptfs는 항상 파일 내용을 암호화하지만 선택적으로 파일 이름을 암호화하거나 숨길 수 있습니다.

파일 이름이 암호화되지 않은 경우 하위 파일 시스템에 기록 된 파일 이름이 단순히 일치하므로 최대 255 자의 파일 이름을 안전하게 작성하고 내용을 암호화 할 수 있습니다. 공격자는 index.html또는 의 내용을 읽을 수 없지만 budget.xls어떤 파일 이름이 있는지 알 수 있습니다. 사용 사례에 따라 민감한 정보가 유출되거나 유출되지 않을 수 있습니다.

파일 이름이 암호화되면 상황이 조금 더 복잡해집니다. eCryptfs는 암호화 된 파일 이름 앞에 암호화 된 파일 이름을 명확하게 식별 할 수 있도록 약간의 데이터를 추가합니다. 또한 암호화 자체는 파일 이름을 "패딩"합니다.

예를 들어 암호화 된 파일이 ~/.bashrc있습니다. 이 파일 이름은 내 키를 사용하여 다음과 같이 암호화됩니다.

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

분명히, 7 자 파일 이름은 이제 7 자 이상을 암호화해야합니다. 경험적으로, 143 자보다 긴 문자 파일 이름은 암호화하기 위해> 255자를 요구하기 시작합니다. 따라서 eCryptfs 업스트림 개발자는 일반적으로 파일 이름을 ~ 140 자로 제한하는 것이 좋습니다.

이제 Synology NAS는 eCryptfs와 Linux를 내장하고 사용하여 장치의 데이터를 암호화하고 보호하는 상용 제품입니다. 우리 (eCryptfs의 업스트림 개발자)는 Synology 또는 해당 제품과 아무 관련이 없지만 일반적으로 eCryptfs 가 야생에서 사용되는 것을 기쁘게 생각합니다 . 45 자 추천은 인쇄상의 오류 (140 자 추천) 또는 훨씬 더 보수적 인 추정 인 것 같습니다.

— 더스틴 커클랜드
소스

필자는 자체 "너무 긴 파일 이름"을 해결하는 FUSE 오버레이 파일 시스템을보고 언더 레이 파일 시스템을 사용하여 프록시 1 : 1로 유지하고 싶습니다. 이러한 FUSE fs는 다른 파일 시스템 (ecryptfs, EncFS)에 유용하지만 현재 지원되는 파일 이름은 변경되지 않습니다. 그리고 다시, 선택 사항입니다. -나의 소원 : unix.stackexchange.com/q/283149/9689

— Grzegorz Wierzowiecki

17

이 답변은 완전히 정확하지 않습니다. 파일 이름의 최대 크기는 255 바이트 또는 C / C ++ 문자 유형입니다. 그러나 파일 이름의 최대 문자는 다릅니다. 대부분의 시스템에서 기본값 인 UTF-8을 사용하는 경우 UTF-16, 63-127을 사용하는 경우 파일 이름은 63-255 자 (일명 코드 포인트)입니다. 1 개의 문자는 저장 공간에서 하나 이상의 바이트 일 수 있으며 시스템 사용자가 사용중인 코드 세트에 따라 다릅니다.

— Rahly

개발자에게 제안 : 최종 사용자로부터 숨겨져있는 서브 디렉토리로 암호화 된 이름을 분할하여 필요한 길이를 얻습니다. 외부 파일 시스템에 필요한 경우 Linux 최대 이름 길이 제한을 초과 할 수도 있습니다. 단일 파일 또는 디렉토리가 "ENCRYPTFS-01-OF-04 [.....] / ENCRYPTFS-02-OF-04 [.....] / ENCRYPTFS-03-OF-04 [.....가됩니다. ] / ENCRYPTFS-04-OF-04 [.....] "-Linux btrfs, ext1-4 및 기타 디렉토리에는 최대 정의 된 디렉토리 깊이가 없으므로 파일 시스템은 노출되지 않은 여러 서브 디렉토리에서 확장 된 파일 및 디렉토리 이름을 처리 할 수 있습니다. .

— Dale Mahalko

1

내 제안은 파일 이름 대신 xattrs에 저장하는 모든 메타 데이터를 저장하는 것이 었습니다. : |

— Trejkaz

1

eCryptfs는 "선택적으로 파일 이름을 암호화 (불명확) 할 수 있습니다"라고 말합니다. 어떻게 할 비활성화 파일 이름 난 다시 내 전체 255 문자 파일 이름을 얻을 수있는 대신에 143 개 문자로 제한되지 않도록 암호화를? 나는 eCryptfs를 설치 한 방법은 우분투 설치 과정에서 "암호화 된 홈 디렉토리"에 대한 상자 나 다른 것을 체크하는 것이라고 생각합니다.

— 가브리엘 스테이 플스

11

이 스레드는 내가 똑같은 것을 궁금해했기 때문에 매우 흥미 롭습니다. 파일 이름이 140 자 이하이어야하는 경우 50 000 중에서 20 개의 파일 이름을 바꾸어야하지만 45 개 이하의 파일은 너무 많은 파일의 이름을 바꿔야하기 때문에 실현 가능하지 않습니다 (내 상황에서는).

나는 똑같은 질문을 Synology에 직접 물었고 (현재 기사를 가리 키더라도) 그들의 대답은 흥미 롭습니다. "암호화 된 공유의 파일 이름 제한은 143 바이트입니다. 최대 140 개의 순수 라틴 문자 또는 45 CJK (중국어) , 일본어 및 한국어) 문자입니다. "

이 답변에 이어 45, 46, 140, 143 및 144 자의 파일로 테스트하면서 더 많은 테스트를했습니다. 필자의 테스트에 따르면 최대 143 자 (Synology의 말과 달리 바이트가 아님)의 파일은 암호화되지만 144자인 파일은 암호화 할 폴더를 예방합니다. 그러나 NAS에서 얻는 오류 메시지는 파일 이름이 45 자 미만이어야한다는 것입니다 (실제로는 144 자 미만이어야 함).

나는 CJK 문자로 테스트를하지 않았다 ...하지만 이것을 읽는 사람에게는 시스템이 알려주는 내용에도 불구하고 143 문자까지 괜찮아 보입니다.

— sdasdrewr
소스

7

리눅스는 파일 이름 당 255 바이트가 아니라 255 바이트 제한이 있음을 분명히하고 싶습니다. 이것은 중요한 차이점이며 UTF-8 인코딩과 같은 예를 들어 최대 100 자의 파일 이름으로 끝날 수 있습니다.

— 리차드 제 린크
소스

1

모든 문자가 코드 포인트 당 최대 4 바이트의 인코딩을 사용하는 경우 최대 값은 63입니다. 이것은 모든 UTF 스키마 (UTF-16 및 UTF-32)에 동일합니다

— Rahly

@Rahly 그래도 결국 바뀔 수 있습니다. 최대 유효한 유니 코드 코드 포인트가 U+10FFFFUCS-2 (기본적으로 대리 쌍이없는 UTF-16)의 제한을 충족시키기 위해 축소되기 전에 UTF-8은 인코딩 방식으로 인해 32 비트 코드 포인트를 나타내는 데 최대 6 바이트가 필요할 수 있습니다. 바이트 스트림 내에서 구문 분석을 시작하는 위치에 상관없이 구문 분석기 동기화를 다시 확보 할 수 있도록 "문자 시작"및 "문자 연속". 할당되지 않은 코드 포인트가 부족하여 결국 결정을 취소하기로 결정할 가능성이 항상 있습니다.

— ssokolow 2016 년

1

그러나 그들이 화 같은 캐릭터를 추가하기 시작하지 않는 한, 가능성이 낮습니다. U8.0 기준으로 120k 만 할당됩니다. 이 반복에서 ~ 8k자를 추가했습니다. 그들이 그것을 유지한다면 ~ 106 버전으로 확장해야합니다.

— Rahly

그리고 UTF-16에 의존하기 때문에 Windows에서 JavaScript를 먼저 종료해야한다고 생각합니다. ( 수도 있지만, 자바 스크립트의 경우이 문제를 해결할 수있을?)

— SAMB

1

ecrypt의 파일 이름 길이는 긴 파일 이름을 지원하기 위해 홈 디렉토리의 특정 하위 트리가 필요하다는 점에서 나에게만 문제가되었으며 결국 파일 내에 파일 시스템을 만들고 간단히 마운트 할 수 있다는 것을 깨달았습니다.

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

아마도 모든 종류의 효율성 문제가있을 수 있지만 파일이 내 로컬 목적을 위해 주기적으로 생성 된 테스트 결과 인 경우에는 충분합니다.

내 동료들은 이미지를 / tmp에 넣었습니다. 테스트 데이터는 특히 기밀이 아닙니다. 우리는 주로 테스트 결과가 아닌 소스 코드를 보호하려고합니다.

— android.weasel
소스