У кого-то еще есть проблемы с шифрованием iOS 5?

Question

Есть (довольно сложное) приложение, которое отлично работает на iOS 4, но не работает на iOS 5 с проблемой расшифровки.Он дешифрует страницу БД SQLite, и последние 16 байтов, по-видимому, не дешифруются должным образом.

Звучит ли это кому-нибудь?

Обновление

У меня естьопределил, что, когда CCCryptorUpdate задан размер буфера 1008 (1024-16), он дешифрует только 992 байта (как указано в параметре dataOutMoved).Это будет нормально, если CCCryptorFinal вернет оставшиеся байты, но сообщит, что было перемещено ноль байтов.Однако CCCryptorFinal сообщает о коде возврата -4304 (который является бесполезным kCCDecodeError).

Обновление 2

Я довольно сильно прибил его как полную ошибку.Я сравнил побайтный вывод шифрования и ввод с дешифрованием и сравнил ключи.Идентичный.Но если длина буфера равна 1008, то дешифрование всегда завершается неудачей, даже когда расшифровщику дается больший выходной буфер (в этом случае требуется 1024).Я предполагаю, что он работает нормально для 1024, хотя я не смог пройти мимо первого буфера размером со странный шарик, чтобы сказать.

И т.д.

Ну, похоже, ничего не расшифровывается.При этом используется интерфейс CCCrypt () «все в одном», который исключает любую вероятность ошибки с помощью последовательности CCCryptorCreate / Update / Final.Интересно, это проблема с AES128?

Любопытно, что когда шифруется 1-я страница БД, шифрование всегда сообщает о перемещении на 16 байт больше, чем то, что я говорю, - если я говорю 1008сообщает 1024, если я говорю 1024, он сообщает 1040. Ни одна другая страница не делает этого, и я не вижу, как CCCrypt мог знать, какую страницу он обрабатывает.Как я уже сказал, любопытно.

Нашел (я думаю)

Старый код указывал kCCOptionPKCS7Padding, который, как я понимаю, должен использоваться только для шифрования там, где длина буферане кратна длине блока (и где предоставляется дополнительное пространство выходного буфера).Это привело к сбою практически всех операций дешифрования с -4304.Но в iOS 4 операции все равно будут перемещать данные, которые они расшифровали (а это было практически все), в то время как iOS 5 изменилась так, что все перемещения данных были подавлены, если операция не удалась (а последний блок почти всегда завершился неудачей).

Отключение параметра padding приводит к тому, что код работает без ошибок.

Answer 1

Как описано выше, произошло изменение с iOS 4 на iOS 5, когда данные больше не копируются в целевой буфер при возникновении ошибки.Таким образом, в iOS 4 можно игнорировать ошибки и при этом получать хорошие результаты, в то время как в iOS 5 это не работает (я не писал оригинальный код - я бы никогда не проигнорировал ошибки).

Ошибки были вызваны указанием kCCOptionPKCS7Padding при выполнении операций с несколькими блоками фиксированной длины.(Не совсем уверен, как распределить буферы при заполнении, но это не то, что мне нужно делать.) Удаление этой опции делает операции безошибочными.

Answer 2

При удалении kCCOptionPKCS7Padding на kCCDecrypt и если исходные данные до kCCEncrypt не кратны длине блока, длина выходных данных после kCCDecrypt отличается от длины исходных данных до kCCEncrypt.

То есть ошибки нет, но результат неверный.