Шифрование iPhone 3DES возвращает неправильные результаты?

У меня серьезные проблемы с функцией CommonCrypto. Существует два существующих приложения для BlackBerry и Windows Mobile, оба используют шифрование Triple-DES с режимом ECB для обмена данными. На любом зашифрованные результаты одинаковы.

Теперь я хочу внедрить шифрование 3DES в наше приложение для iPhone, поэтому я сразу перешел к CommonCrypto: http://www.opensource.apple.com/source/CommonCrypto/CommonCrypto-32207/CommonCrypto/CommonCryptor.h

Я получаю некоторые результаты, если использую режим CBC, но они не соответствуют результатам Java или C#. В любом случае, я хочу использовать режим ECB, но у меня это вообще не работает - появляется ошибка параметра...

Это мой призыв к режиму ECB... Я его немного убрал:

const void *vplainText;

plainTextBufferSize = [@"Hello World!" length];
bufferPtrSize = (plainTextBufferSize + kCCBlockSize3DES) & ~(kCCBlockSize3DES - 1);

plainText = (const void *) [@"Hello World!" UTF8String];
NSString *key = @"abcdeabcdeabcdeabcdeabcd";

ccStatus = CCCrypt(kCCEncrypt,
     kCCAlgorithm3DES,
     kCCOptionECBMode,
     key,
     kCCKeySize3DES,
     nil, // iv, not used with ECB
     plainText,
     plainTextBufferSize,
     (void *)bufferPtr, // output
     bufferPtrSize,
     &movedBytes);

Это более или менее код отсюда: http://discussions.apple.com/thread.jspa?messageID=9017515 Но, как уже упоминалось, Я получаю ошибку параметра каждый раз...

Когда я использую kCCOptionPKCS7Padding вместо kCCOptionECBMode и устанавливаю один и тот же вектор инициализации в C# и коде iPhone, iPhone дает разные результаты. Есть ли ошибка при получении моего вывода из bufferPtr? В настоящее время я получаю зашифрованные данные таким образом:

NSData *myData = [NSData dataWithBytes:(const void *)bufferPtr length:(NSUInteger)movedBytes];
result = [[NSString alloc] initWithData:myData encoding:NSISOLatin1StringEncoding];

Кажется, я почти дважды пробовал каждую настройку, разные кодировки и так далее... где моя ошибка?


iphone objective-c encryption 3des
person Jan Gressmann    schedule 07.09.2009    source источник

Ответы (3)


arrow_upward
1
arrow_downward

Можете ли вы опубликовать сообщение об ошибке?

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

То, что вы здесь делаете, вероятно, не лучший способ проверить вывод:

NSData *myData = [NSData dataWithBytes:(const void *)bufferPtr length:(NSUInteger)movedBytes];
result = [[NSString alloc] initWithData:myData encoding:NSISOLatin1StringEncoding];

Откуда вы знаете, что зашифрованные двоичные данные можно интерпретировать с помощью кодировки NSISOLatin1StringEncoding?

Вместо этого сравните байты напрямую (через [myData description] или т.п.) или переведите вывод в шестнадцатеричном формате или кодировка base64.

person Alex Reynolds    schedule 07.09.2009
comment
Спасибо за совет, мне удалось запустить его с помощью kCCOptionPKCS7Padding (читай: режим CBC). Кажется, проблема заключалась в кодировке вывода. Я буду использовать это вместо режима ECB, но мне все еще любопытно, почему я получаю ошибку — функция просто возвращает kCCParamError, если используется kCCOptionECBMode. - person Jan Gressmann; 08.09.2009

arrow_upward
1
arrow_downward

Я считаю, что проблема в том, что одного kCCOptionECBMode недостаточно. Вам также нужно дополнение (поскольку это блочный шифр). Если вы передадите оба (т.е. kCCOptionPKCS7Padding | kCCOptionECBMode ), это сработает.

person honus    schedule 14.03.2010

arrow_upward
0
arrow_downward

Я понимаю, что это старый вопрос, но для справки: я думаю, что ваш ключ не следует передавать как NSString. Вместо этого ключ следует преобразовать из шестнадцатеричного в массив байтов. Это расширение hexToBytes NSString должно предоставить то, что вам нужно, выполнив следующие действия:

[[key hexToBytes] bytes]

Ключ также должен быть в два раза длиннее заданного (48 шестнадцатеричных символов, т. е. 24 байта).

person Luke Rogers    schedule 28.05.2012