dd, cat 및 openssl: 블록 크기 및 버퍼 크기

dd, cat 및 openssl: 블록 크기 및 버퍼 크기

여기dd관통 dm-crypt오버레이 블록 장치를 사용할 때 블록 크기는 동일하고(512바이트) 블록 크기를 늘리면 최종 블록이 기록되지 않을 수 있으므로 dd기본 블록 크기만 사용해야 한다고 명시되어 있습니다.dm-cryptdd

이것도 작동 합니까 openssl(Linux에서)?

여기opensslGiles는 그것이 기본값이라고 말했습니다.완충기크기는 8kB입니다. 이 경우 버퍼 크기는 블록 크기와 동일합니까?

기본 블록 크기가 512 인 dd경우 1M의 블록 크기를 사용하려면 이 블록 크기도 같은 숫자로 dd설정해야 합니까 ? 바이트 단위 로 ?-bufsizeopenssl-bufsize

또한 기본(및 구성 불가능) 블록 크기가 128kB인 경우 catthrough를 사용하는 것이 권장되지 않습니까?opensslcat

답변1

TLDR 괜찮아요(제 추측이 맞다면)

우선, openssl명령줄을 사용하여 수행할 수 있는 작업은 약 50가지가 있습니다. 그중 두 가지만 대량 입력 데이터를 사용합니다. 즉, enc"파일"을 암호화 또는 해독하거나 특수한 경우로 base64 인코딩/디코딩(실제로는 암호화가 아님) 및 dgst암호화를 수행합니다. "파일" 해시하고 선택적으로 서명하거나 확인합니다. 이는 무언가를 "덮어쓰는" 데 사용할 수 있는 출력만 생성하므로 일괄 출력을 생성하는 것도 가능하지만 입력에 의존하지 않는다는 enc뜻이라고 가정합니다 .rand

2. 문제는링크에 문제가 있습니다지연암호화 데이터 청크 또는 인코딩된(base64) 청크를 기다리기 때문에인터넷을 통해. 올바른 출력을 얻는 데만 관심이 있다면 지연 시간은 중요하지 않으며, 소스가 원격이 아닌 경우에도 지연되지 않습니다.

openssl enc 블록 암호 및 패턴 사용, 특히 기본적으로 사용되는 기본 CBCPKCS#5 패딩(소위 공식은 PKCS#5를 기반으로 한 PKCS#7이지만 OpenSSL을 포함한 많은 사람들은 그냥 PKCS#5라고 말합니다.) 이를 통해 다음이 가능해집니다.원하는 수의 바이트 암호화 및 해독운영 체제 및 파일 시스템에서 지원하는 입력 및 출력 "파일"에 적합한 데이터입니다. 암호화된 파일(패딩 추가)은 항상 사용된 암호 블록 크기의 정확한 배수입니다. 비밀번호 기반 솔트 암호화(기본값)의 경우 암호문은 일반 텍스트보다 최대 32바이트까지 길 수 있으므로 암호화할 때 이 점을 고려할 수 있습니다. 당신이 지정하는 경우-nopad(블록 암호/모드의 경우) 패딩이 비활성화되고 일반 텍스트는 암호 블록 크기의 정확한 배수여야 합니다. 그렇지 않은 경우 오류가 발생하고 출력이 불완전합니다. 일반적으로 비어 있지 않더라도 부주의한 사람이나 스크립트 등이 유효하지 않은데 유효하다고 생각하도록 속일 수 있습니다.

당신이 사용하는 경우스트림 암호(현재는 RC4만 해당)또는 스트리밍 모드블록 암호(CFB OFB CTR)는 패딩을 요구하거나 사용하지 않으며 일반 텍스트는 다음과 같습니다.임의의 바이트 수(파일에 맞습니다). 솔티드 PBE의 경우 암호문은 여전히 ​​16바이트 더 깁니다. (경고: 일부 버전에서는 CCM 및 GCM 모드가 지원되는 것으로 잘못 나열되어 있습니다 enc. 이를 사용하려고 하면 실제로 작동하지 않습니다.)

-bufsize데이터를 읽고 쓰는 데만 사용되는 크기입니다. 암호 블록 크기(있는 경우)와 관련될 필요는 없지만 기본적으로 중간 제곱인 2이고 지원되는 모든 블록 암호의 블록 크기는 2의 작은 제곱이므로 균등하게 분할됩니다. Cryptologic은 빅 데이터를 임의의 크기로 나누어진 스트림으로 처리합니다. 전체 길이만 중요합니다. 하지만 처리 효율이 낮습니다.위치C 라이브러리와 (일반적으로) 운영 체제를 더 많이 호출하므로 더 작은 청크입니다.

cat입력에 파이프를 연결하는 것은 괜찮지만 "파일"만 읽는 경우에는 openssl enc해당 파일을 (리디렉션된) 표준 입력 또는 인수로 사용하는 것보다 이점이 없습니다. 다시 말하지만, 단순히 데이터를 복사하는 경우 이를 사용해도 아무런 해로움이나 이점이 없습니다. EBCDIC 및/또는 고정 길이 레코드(일반적인 IBM 메인프레임 데이터) 변환과 같은 다른 기능을 사용하는 경우 이는 분명히 그렇습니다. 필요합니다. 만약 너라면openssl-indddd생각하다1234+0 records indd등에 대한 유사한 통계가 필요합니다 .

관련 정보