키 무결성 검사가 없는 파일 암호화 유틸리티(대칭 키)

키 무결성 검사가 없는 파일 암호화 유틸리티(대칭 키)

대칭 키를 사용하여 파일을 암호화할 때 가장 일반적인 유틸리티(예: gpg, mcrypt 등)는 암호 해독 중에 키의 무결성을 확인하는 데 사용할 수 있는 정보를 암호화된 메시지에 저장합니다. 예를 들어, 복호화 중에 잘못된 키를 입력하면 gpg는 다음을 반환합니다.

gpg: 암호 해독 실패: 잘못된 키

임의의 문자열이 포함된 파일을 암호화한다고 가정해 보겠습니다. 그런 다음 표준 유틸리티에서 사용되는 주요 무결성 검사로 인해 취약점이 추가됩니다.

키/메시지 무결성을 확인하기 위해 정보나 중복성을 저장하지 않는 일반 유틸리티가 있습니까(따라서 확인을 위해 암호화된 파일을 "해독"함)어느키 제공)?

답변1

내 교체로다른 답변, 다른 것을 제안하고 싶습니다. 뭔가 아름다운데... DM-crypt.

일반 dm-crypt(LUKS 없음)는 키에 대한 정보를 저장하지 않습니다. 대신 cryptsetup일반 장치를 열고 사용하기 위해 비밀번호를 사용하는 것이 좋습니다. 예를 들어 보겠습니다.

[root:tmp]# fallocate -l 16M cryptfile
[root:tmp]# cryptsetup --key-file - open --type plain cryptfile cfile-open <<<"pa55w0rd"

참고: cryptfile크기는 512바이트 이상이어야 합니다. 최소 섹터 크기 시행으로 인해 생각됩니다 cryptsetup.

이 시점에서는 모든 임의의 데이터를 /dev/mapper/cfile-open. Obscurity는 보안을 추가하고 사용자가 쓰는 데이터의 양을 정확하게 기록합니다. (이것은 기본 청크가 이미 반 무작위인 경우에만 실제로 작동합니다. 즉, 파일을 완전히 채우려는 것이 아니라면 대신 에 openssl rand또는 를 사용하여 생성해야 합니다.) ... Somewhere를 사용하여 장치에서 쓰기를 시작할 수도 있습니다. 중간에.dd if=/dev/urandomfallocatedd

이제 좀 더 간단한 일을 해보겠습니다.

[root:tmp]# cryptsetup status cfile-open
/dev/mapper/cfile-open is active.
  type:    PLAIN
  cipher:  aes-cbc-essiv:sha256
  keysize: 256 bits
  device:  /dev/loop0
  loop:    /tmp/cryptfile
  offset:  0 sectors
  size:    32768 sectors
  mode:    read/write
[root:tmp]# b $((32768*512))
B         KiB      MiB    GiB  TiB  PiB  EiB
16777216  16384.0  16.00  .01  0    0    0
[root:tmp]# ll cryptfile
-rw-r--r--. 1 root root 16777216 Feb 21 00:28 cryptfile
[root:tmp]# openssl rand -out /dev/mapper/cfile-open $((32768*512))
[root:tmp]# hexdump -n 16 -C /dev/mapper/cfile-open
00000000  00 1d 2d 11 ac 38 c4 d3  cc 81 4f 32 de 64 01 ca  |..-..8....O2.d..|
00000010
[root:tmp]# cryptsetup close cfile-open

이 시점에서 암호화된 파일을 16MiB의 임의 데이터로 채웠습니다. 잘못된 비밀번호로 다시 열면 어떤 일이 일어나는지 확인하세요. 정확한 비밀번호로 다시 열면 원본 데이터가 그대로 유지되는 것을 볼 수 있습니다.

[root:tmp]# cryptsetup --key-file - open --type plain cryptfile cfile-open <<<"pass"
[root:tmp]# hexdump -n 16 -C /dev/mapper/cfile-open
00000000  89 97 91 26 b5 46 87 0c  67 87 d8 4a cf 78 e6 d8  |...&.F..g..J.x..|
00000010
[root:tmp]# cryptsetup close cfile-open
[root:tmp]# cryptsetup --key-file - open --type plain cryptfile cfile-open <<<"pa55w0rd"
[root:tmp]# hexdump -n 16 -C /dev/mapper/cfile-open
00000000  00 1d 2d 11 ac 38 c4 d3  cc 81 4f 32 de 64 01 ca  |..-..8....O2.d..|
00000010
[root:tmp]# 

즐기다.

답변2

GnuPG는 당신이 원하는 것을 할 수 없습니다. 그러나 OpenSSL을 사용하면 가능합니다. cfb 또는 ofb와 같은 스트리밍 모드에서는 이러한 암호(바람직하게는 AES) 중 하나를 사용해야 합니다. (바라보다:http://en.wikipedia.org/wiki/Block_cipher_mode_of_Operation)

일반적으로 openssl을 사용하여 데이터를 암호화할 때 다음과 같이 cbc(base64 인코딩() 포함 또는 제외)를 사용합니다 -a. 물론 비밀번호와 입력 데이터를 지정하는 다른 방법도 있습니다(참고자료 참조 man openssl).

[rsaw:~]$ openssl aes-256-cbc -e -a -pass pass:pa55w0rd <<<inputdata
U2FsdGVkX180a9K5gBgip7/lgdCGCLLlRflAjK8+YwY=
[rsaw:~]$ openssl aes-256-cbc -e -a -pass pass:pa55w0rd <<<inputdata
U2FsdGVkX1+4uSv4uCNj2J4g7441XDioDoAb6JNn2RU=
[rsaw:~]$ openssl aes-256-cbc -e -a -pass pass:pa55w0rd <<<inputdata |
> openssl aes-256-cbc -d -a -pass pass:pa55w0rd
inputdata

매번 다른 결과가 나온다는 사실은 귀하의 비밀번호가 솔트 처리되어 있음을 나타내며 이는 일반적으로 좋습니다. 이제 잘못된 키를 사용하면 어떤 일이 발생하는지 살펴보겠습니다.

[rsaw:~]$ openssl aes-256-cbc -e -a -pass pass:pa55w0rd <<<inputdata |
> openssl aes-256-cbc -d -a -pass pass:pa55w0r
bad decrypt
139867807664032:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:evp_enc.c:596:

간단히 말해서, 이 모드(cbc)는 파일을 암호화하는 데 널리 사용되지만 분명히 귀하가 요청한 요구 사항을 충족하지 않습니다. 다른 것을 시도해 봅시다.

[rsaw:~]$ openssl aes-256-cfb1 -e -a -pass pass:pa55w0rd <<<inputdata
U2FsdGVkX1+p64nx+/K6yCHdHw+Nmn6fSOg=
[rsaw:~]$ openssl aes-256-cfb1 -e -a -pass pass:pa55w0rd <<<inputdata |
> openssl aes-256-cfb1 -d -a -pass pass:pa55w0rd
inputdata
[rsaw:~]$ openssl aes-256-cfb1 -e -a -pass pass:pa55w0rd <<<inputdata |
> openssl aes-256-cfb1 -d -a -pass pass:pa55w0r
'G�疏s�v

위 내용이 귀하의 요구 사항을 충족하더라도 보장할 수는 없습니다. 저는 암호화 전문가가 아닙니다. 암호화는 큰 일입니다. 복잡해요. 나~ 할 것이다그렇게 말하고 요구 사항을 충족 aes*cfb*하면 aes*ofb... 건너뛰어야 합니다 aes*ecb.

2가지 흥미로운 정보를 더 제공하겠습니다.

  1. 나는 일반적으로 솔트되지 않은 키를 사용하는 것을 권장하지 않지만, 수행 중인 작업(임의의 데이터 암호화)의 경우... 데이터 정의 구조의 시작 부분에 더 명확성을 추가하므로 솔트를 건너뛸 수 있습니다. 예를 들어:

    [rsaw:~]$ openssl aes-256-cfb1 -e -a -pass pass:pa55w0rd <<<inputdata
    U2FsdGVkX18aMT3eK4IH+XWGhp4dOSG9UJQ=
    [rsaw:~]$ openssl aes-256-cfb1 -e -a -pass pass:pa55w0rd <<<inputdata
    U2FsdGVkX18uIlFFMbsZib11UgjuITY9rNw=
    [rsaw:~]$ openssl aes-256-cfb1 -e -a -pass pass:pa55w0rd <<<inputdata
    U2FsdGVkX1+G9lAIj7RjafT9YNfO9RQXDjU=
    [rsaw:~]$ openssl aes-256-cfb1 -e -nosalt -a -pass pass:pa55w0rd <<<inputdata
    X2zi09uo6ale8A==
    
  2. 암호화된 데이터를 포함하여 데이터를 저장할 때 무결성은 항상 가장 큰 관심사 중 하나입니다. 데이터가 손상된 경우 파일 전체를 버릴 수 있도록 알고 싶습니다. openssl과 같은 블록 암호 aes*cbc(또는 AFAIK는 이를 위해 GnuPG를 사용)를 사용하면 작은 비트 반전이 포착되어 암호 해독이 실패하게 됩니다. 반면, 올바르게 수행한다면 스트리밍 모드를 사용하면 최대한 많은 데이터를 복구할 수 있습니다. 즉, 스트림에 존재하는 부분에 대한 손상을 유지합니다. 확인하다:

    [rsaw:tmp]$ openssl aes-256-cfb1 -e -a -pass pass:pa55w0rd </etc/services >services.asc
    [rsaw:tmp]$ wc -l services.asc 
    13965 services.asc
    [rsaw:tmp]$ sed '6000q;d' services.asc
    e6AAnnXAF74c8p52q7+klGC+JHfK91QOx+oFonAzKFoJt0DSNg2WQkdBaxv4YLst
    [rsaw:tmp]$ sed -i '6000s/^e/f/' services.asc 
    [rsaw:tmp]$ sed '6000q;d' services.asc
    f6AAnnXAF74c8p52q7+klGC+JHfK91QOx+oFonAzKFoJt0DSNg2WQkdBaxv4YLst
    [rsaw:tmp]$ openssl aes-256-cfb1 -d -a -pass pass:pa55w0rd <services.asc | diff - /etc/services
    5029c5029,5030
    < veronica        2770/tcp           %���#��*����@jeronica        2770/udp                # Veronica
    ---
    > veronica        2770/tcp                # Veronica
    > veronica        2770/udp                # Veronica
    

즐기다.

gpg추신: openssl, , 또는 dm-crypt를 제외한 다른 것을 감히 사용하지 마십시오. 큰 것 3개를 붙입니다. 다른 사람은 없습니다.

답변3

이 도구는 키를 확인하기 위해 아무것도 저장하지 않습니다.

https://madebits.github.io/#r/cpp-aes-tool.md

답변4

@udkLpqc: 이에 대해 논평할 수 없습니다. 도구를 사용할지 여부는 귀하에게 달려 있지만 귀하가 작성한 내용은 어떤 면에서는 제가 보는 것과 다릅니다. 우분투에서 직접 컴파일했습니다.

$echo -e "uvwxyz\n\n\n\n\n\n\n\n\n\n" | wc -l
11
$echo -e "uvwxyz\n\n\n\n\n\n\n\n\n\n" | ./aes -p "t" | ./aes -d -p "t" | wc -l
11

이것은 나에게 같은 수의 줄처럼 보입니다(파일을 사용하여 동일한 결과를 얻었습니다). 이 도구는 오래되었으며 소스에 따르면 PKCS7이 아닌 PKCS5를 지원한다고 합니다. 암호를 에코하는 이유를 문서화하고 strnlen 대신 strlen을 사용합니다. 음, 이는 맥락에서 보아야 하며 도구는 사용자로부터 직접 입력을 기대하며 파일 이름과 암호에만 strlen을 사용합니다. 파일 이름과 비밀번호가 신뢰할 수 없는 소스에서 나오는 일부 자동화된 환경에서 사용할 계획이라면 동의합니다. 아마도 작동하지 않을 것입니다.

관련 정보