AES / CBC 및 AES / ECB 암호화 후 데이터 크기

AES / CBC 및 AES / ECB 암호화 후 데이터 크기

---

주로 크기를 알기 위해 AES 이후 데이터 (디스크 또는 메모리)를 버퍼링하지 않도록 AES 암호화 후 데이터 크기를 알고 싶습니다.

나는 128 비트 AES 및 사용 javax.crypto.Cipher등을 javax.crypto.CipherInputStream암호화.

다양한 입력 크기로 수행 된 몇 가지 테스트에서 아래와 같이 계산 된 사후 암호화 크기가 정확함을 보여줍니다.

long size = input_Size_In_Bytes; 
long post_AES_Size = size + (16 - (size % 16));

그러나 위의 공식이 가능한 모든 입력 크기에 적용 가능한지 확실하지 않습니다.

AES 암호화를 적용한 후 데이터 크기를 계산할 수있는 방법이 있습니까? 암호화 된 데이터 (디스크 또는 메모리에있는)를 미리 버퍼링하지 않고도 암호화 후 크기를 알 수 있습니까?

---

AES는 키 크기에 관계없이 16 바이트의 고정 블록 크기를 갖습니다. PKCS 5/7 패딩을 사용한다고 가정하고 다음 공식을 사용하십시오.

 cipherLen = (clearLen/16 + 1) * 16;

일반 텍스트가 블록 크기의 배수 인 경우 패딩을 위해 완전히 새로운 블록이 필요합니다. 일반 텍스트가 16 바이트라고 가정합니다. 암호문은 32 바이트를 차지합니다.

암호 텍스트와 함께 IV (초기 벡터)를 저장할 수 있습니다. 이 경우 IV에 대해 16 바이트를 더 추가해야합니다.

---

AES는 블록 암호로서 크기를 변경하지 않습니다. 입력 크기는 항상 출력 크기입니다.

그러나 AES는 블록 암호이기 때문에 입력이 블록 크기의 배수 (16 바이트) 여야합니다. 이를 위해 인기있는 PKCS5 와 같이 패딩 체계 가 사용됩니다 . 따라서 대답은 암호화 된 데이터의 크기가 사용 된 패딩 체계에 따라 달라진다는 것입니다. 그러나 동시에 알려진 모든 패딩 체계는 다음 모듈 16 크기로 반올림됩니다 (크기 AES는 16 바이트 블록 크기를 가짐).

---

AES를 사용하는 모드에 따라 다릅니다. 가지고있는 것은 ECB 및 CBC와 같은 대부분의 블록 지향 모드에 대해 정확합니다. OTOH, CFB 모드 (예 : 예)에서는 기본적으로 AES를 사용하여 바이트 스트림을 생성하고 입력 바이트로 XOR합니다. 이 경우 출력의 크기는 위에서 지정한대로 다음 블록 크기로 반올림되지 않고 입력의 크기로 유지 될 수 있습니다.

---

일반적으로 블록 암호 암호화의 경우 :

CipherText = PlainText + Block-(PlainText MOD 블록)

암호문 크기는 다음 블록으로 확장 된 일반 텍스트의 크기로 계산됩니다. 패딩이 사용되고 일반 텍스트의 크기가 블록 크기의 정확한 배수 인 경우 패딩 정보를 포함하는 하나의 추가 블록이 추가됩니다.

AES는 16 바이트의 블록 크기를 사용하여 다음을 생성합니다.

CipherText = PlainText + 16-(PlainText MOD 16)

출처 : http://www.obviex.com/articles/CiphertextSize.pdf

노트 :

1. CipherText 및 PlainText는 암호 텍스트의 크기와 그에 따른 일반 텍스트의 크기를 나타냅니다.

---

AES 암호는 항상 16 바이트 (128 비트) 블록에서 작동합니다. 입력 바이트 수가 정확히 16의 배수가 아니면 패딩됩니다. 이것이 16이 계산에서 "마법의 숫자"로 나타나는 이유입니다. 모든 입력 크기에 대해 작동해야합니다.

---

AES는 128 비트 (16 바이트) 블록에서 작동하며 일반 텍스트 블록을 동일한 길이의 암호문 블록으로 변환합니다. 16 바이트보다 짧은 경우 마지막 블록을 채우므로 수식이 올바로 보입니다.

---

입력 길이가 int의 최대 크기보다 작 으면 Cipher.getOutputSize (int)를 사용할 수 있습니다.

---

데이터 크기가 최소한 블록 크기와 같을 경우 패딩이 필요하지 않도록 암호화 된 정보를 저장하는 방법이 있습니다. 한 가지 약간의 어려움은 데이터 크기가 블록 크기보다 작게 허용되고 데이터의 정확한 크기를 재구성 할 수 있어야한다면 작은 블록의 경우에도 출력이 최소 1 비트 더 커야한다는 것입니다. 입력, [i] 데이터 크기에 관계없이 [/ i].

문제를 이해하려면 N 바이트 길이의 가능한 파일이 256 ^ N 개 있고 길이가 N 바이트보다 길지 않은 가능한 파일 수는 256 ^ N에 N보다 길지 않은 가능한 파일 수를 더한 것입니다. -1 바이트 길이 (길이가 0 바이트 인 파일 하나와 길이가 1 바이트 이하인 파일 257 개가 있음).

블록 크기가 16 바이트 인 경우 256 ^ 16 + 256 ^ 14 + 256 ^ 13 등 16 바이트 이하의 가능한 입력 파일이 있지만 16 바이트 이하의 가능한 출력 파일은 256 ^ 16 개만 가능합니다. 바이트 길이 (출력 파일은 16 바이트보다 짧을 수 없기 때문). 따라서 가능한 16 바이트 입력 파일 중 일부는 커야합니다. 17 바이트가된다고 가정합니다. 256 ^ 17 개의 가능한 17 바이트 출력 파일이 있습니다. 이들 중 하나가 16 바이트 이하의 입력을 처리하는 데 사용되는 경우 가능한 모든 17 바이트 입력 파일을 처리 할 수있는 용량이 충분하지 않습니다. 입력이 아무리 커도 해당 크기 이상의 일부 파일은 커야합니다.

참고 URL : https://stackoverflow.com/questions/3283787/size-of-data-after-aes-cbc-and-aes-ecb-encryption