CRC проверката е излишна при използване на криптиране?

Използвам AES за криптиране и CRC за проверка на целостта на данните и имам впечатлението, че проверката на CRC е излишна в моя случай. Правя следното:

Шифроване:

  1. Вземете данните за полезния товар и изчислете CRC от тях
  2. Шифроване на полезни данни плюс CRC

Дешифриране:

  1. Декриптиране на данни
  2. Изчислете нов CRC на данни за полезен товар и го сравнете със стария CRC

Исках да провокирам неуспешна проверка на CRC в моя модулен тест, но когато манипулирам данните за полезния товар, дешифрирането винаги хвърля BadPaddingException.

Въпросът ми е: Ако декриптирането винаги хвърля това изключение, когато данните са повредени или манипулирани (ще стане ли?), не е ли CRC проверката излишна по начина, по който я използвам?


java encryption crc
person mithrandir    schedule 11.01.2013    source източник
comment
Какво шифровате в стъпка 2 от шифроването? Полезен товар + CRC или само полезен товар?   -  person Timmos    schedule 11.01.2013
comment
Покажете ни вашия код на методите за криптиране/декриптиране, които използвате.   -  person Andremoniy    schedule 11.01.2013
comment
@Timmos Аз криптирам полезен товар + CRC (вижте по-горе)   -  person mithrandir    schedule 11.01.2013
comment
@Andremoniy въпросът ми е теоретичен - кодът няма да помогне много imho   -  person mithrandir    schedule 11.01.2013

Отговори (1)


arrow_upward
2
arrow_downward

Ако приемем, че неправилно декриптираните данни са равномерно разпределени, те ще изглеждат правилно PKCS5/PKCS7 подплатени около 1 път за всеки 255 неправилни пароли. Това означава, че все още има 1/255 шанс да настъпи правилна промяна и елементът да се дешифрира в боклук. Следователно вашият чек не е загуба.

Ако наистина искате поведението, което очаквате, можете да използвате "AES/CTR/NoPadding", което няма да изисква точен размер на блока и винаги ще връща дешифриран байт [], независимо дали ключовете съвпадат или не.

Въпреки това, ако нападателят може многократно да променя шифрования текст и да ви накара да го дешифрирате (пример може да са криптирани данни, съхранени в бисквитка) и ако може да разграничи вашето поведение, когато декриптираните данни хвърлят изключение за лошо подпълване и кога е просто боклук, тогава те могат да определят обикновения текст чрез "атака на оракула за подплънки".

Може също да помислите дали по-стабилен пръстов отпечатък от CRC може да е подходящ като SHA -256 за гарантиране на целостта на съобщението.

Много от това се повтаря от: AES BadPaddingException

person Wolfwyrd    schedule 11.01.2013
comment
Благодаря - точно това исках да знам! - person mithrandir; 11.01.2013