Статус: Новичок
Группы: Участники
Зарегистрирован: 26.11.2019(UTC) Сообщений: 7 
|
Добрый день! Пытаюсь расшифровать сообщение, полученное от партнера. За основу взял код из примера CMS_samples\CMSDecrypt.java Проблема возникает в долгой отработке метода decode() Код:
//разбор CMS-сообщения
Asn1BerDecodeBuffer dbuf = new Asn1BerDecodeBuffer(buffer);
final ContentInfo all = new ContentInfo();
all.decode(dbuf); // тормозит!
На файле размером 10Мб отработка ~10 секунд, 50Мб - около 4 минут! Но в итоге файл дешифруется корректно. С помощью cryptcp.exe этот же 50Мб файл расшифровывается за пару секунд. Причем, тестовые файлы, аналогичных размеров, шифрованные, а потом расшифрованные с помощью JCP такой проблемой не страдают. dumpasn1 на файлах от партнера показал, что блок данных разбит на OCTEC STRING по 1024 байта и таких блоков там огромное количество. (см. ниже) На тестовых файлах, зашифрованных JCP содержится только 1 блок данных нужной длинны. JCP 2.0.40450-A Что можно сделать в такой ситуации? Код:
390 NDEF: SEQUENCE {
392 9: OBJECT IDENTIFIER data (1 2 840 113549 1 7 1)
: (PKCS #7)
403 29: SEQUENCE {
405 6: OBJECT IDENTIFIER gostCipher (1 2 643 2 2 21)
: (GOST 28147-89 (symmetric key block cipher))
413 19: SEQUENCE {
415 8: OCTET STRING 8A BA 75 0D B3 85 27 EA
425 7: OBJECT IDENTIFIER cryptoProCipherA (1 2 643 2 2 31 1)
: (CryptoPro params A for GOST 28147-89)
: }
: }
434 NDEF: [0] {
436 1024: OCTET STRING
: F2 1A 4F 7B 92 15 41 51 B2 A5 60 57 3E C8 64 85
: 34 4B 05 14 65 30 38 CD 5C 74 AB C1 52 25 84 EA
: B7 44 4D 0A 75 0E 1B 0C EB 9A C8 E6 81 43 08 DD
: 48 8F 16 23 37 8D B5 70 22 3A B4 61 8F 15 2B 71
: 4A 1C F7 4A C1 CA 7A CE DF CF 43 13 2C F9 69 A8
: 7A 84 AE 87 71 42 F6 66 9A 9E E5 B5 C6 3C 1B EA
: FC F2 7F D7 34 9B 0C 96 6D 79 26 85 6D 54 D5 3F
: F8 C4 C1 ED 0D E4 E7 B4 BA F0 6C FA 6C B6 49 C1
: [ Another 896 bytes skipped ]
1464 1024: OCTET STRING
: 47 37 C3 49 29 5E 1D 3A 80 AF 42 D1 92 01 FF C2
: 64 64 98 95 0D 42 A5 AB 0A A4 CC 0C 21 D2 51 A3
: DD D9 15 4A D0 5C 78 40 D3 57 D7 D7 A3 3D 08 63
: 46 71 8D 26 4D C2 EE A9 8B 0F 6F B9 F6 83 50 29
: 1A C2 AE 8A F7 8E BD D5 6A 90 EE 05 00 12 43 DC
: 42 45 A4 42 4F 04 68 7D 61 A2 D1 E7 AA D4 FA 2F
: 9A C7 E8 7C CD 0F 8A 28 B3 DA 0C 20 D7 A9 7B A4
: AE 06 2F C2 41 AF 81 93 5B 7B 5B 3B E4 40 4F A5
: [ Another 896 bytes skipped ]
и т.д...
|
|
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 26.07.2011(UTC) Сообщений: 13,504  Сказал «Спасибо»: 554 раз
Поблагодарили: 2250 раз в 1756 постах
|
Здравствуйте. Цитата:
Что можно сделать в такой ситуации?
Предложить тому, кто генерирует такие файлы - изменить программный код? Сам отправитель не замеряет быстродействие (не выполняет расшифрование для проверки)? |
|
|
|
|
|
|
Статус: Эксперт
Группы: Участники
Зарегистрирован: 05.03.2015(UTC) Сообщений: 1,602 Откуда: Иркутская область Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 395 раз в 366 постах
|
А не может быть проблема в том что кодировка BER вместо DER? Может быть в тестовых файлах DER? Вот что нашел: http://book.itep.ru/4/44/asn44132.htm
Цитата:Строки октетов
Тип OCTET STRING служит для представления произвольных последовательностей октетов. Значение OCTET STRING может иметь любую длину, включая нуль. OCTET STRING используется для представления сообщений, включая зашифрованные, а также для типа PBEParameter. Нотация типа OCTET STRING имеет формат.
OCTET STRING [SIZE ({size | size1..size2})]
где size, size1 и size2 опционные ограничения размера. В форме OCTET STRING SIZE(size) строка октетов должна иметь октеты size. В формате OCTET STRING SIZE(size1 .. size2) строка должна содержать число октетов между size1 и size2. Например, тип PBEParameter имеет компоненту типа OCTET STRING:
PBEParameter ::= SEQUENCE {
salt OCTET STRING SIZE (8),
iterationCount INTEGER }
Здесь размер компоненты salt всегда равен 8 октетам. BER-кодирование типа OCTET STRING может быть примитивным или конструктивным. При примитивном кодировании октеты содержимого несут в себе октеты строки с первого по последний. При конструктивном кодировании содержимое октетов представляет собой последовательное объединение субстрок значения OCTET STRING. Например, BER-код значения OCTET STRING 01 23 45 67 89 AB CD EF может иметь один из следующих видов, в зависимости от формата октетов длины и вида кодирования (примитивное/конструктивное). Код:04 08 01 23 45 67 89 AB CD EF DER-кодирование
04 81 08 01 23 45 67 89 AB CD EF Длинный формат октетов длины
24 0С Конструктивное кодирование “01 23 45 67” + “89 AB CD EF”
04 04 01 23 45 67
04 04 89 AB CD EF
То есть вариант где "все вместе" это BER примитивное кодирование, а вариант с делением на блоки по 1024 байта это BER конструктивное кодирование. DER выбирает примитивное кодирование где возможно. Если разница 4 минуты, то наверно проще потратить время на предварительное объединение блоков. Отредактировано пользователем 26 ноября 2019 г. 10:45:40(UTC)
| Причина: Не указана
|
|
|
|
|
|
Статус: Новичок
Группы: Участники
Зарегистрирован: 26.11.2019(UTC) Сообщений: 7
|
В библиотеке com.objsys.asn1j Asn1BerDecodeBuffer и Asn1DerDecodeBuffer похоже синонимы. Замена одного другим не меняет результат.
|
|
|
|
|
|
Статус: Новичок
Группы: Участники
Зарегистрирован: 26.11.2019(UTC) Сообщений: 7
|
Цитата:
Предложить тому, кто генерирует такие файлы - изменить программный код?
Сам отправитель не замеряет быстродействие (не выполняет расшифрование для проверки)?
Как делают шифрование на той стороне сейчас выясняем. Но, как я уже писал, с помощью cryptcp.exe расшифровка 50Мб файла происходит почти мгновенно. Т.е. реализация под windows как-то умеет быстро справляться с этими блоками.
|
|
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 06.12.2008(UTC) Сообщений: 4,006 Откуда: Крипто-Про Сказал(а) «Спасибо»: 21 раз
Поблагодарили: 715 раз в 675 постах
|
Добрый день.
Попробуйте использовать функционал Cades api, в нем работа осуществляется с потоком данных. |
|
|
|
|
|
|
Статус: Новичок
Группы: Участники
Зарегистрирован: 26.11.2019(UTC) Сообщений: 7
|
Воспроизведение проблемы: Берем последние версии cryptcp под windows [4.0.1127.0] и JCP [2.0.40450-A] Тестовый файл 50мб. Шифруем cryptcp.win32.exe –encr "recipient.cer" file50mb.txt file50mb.txt.enc Получаем CMS, в котором данные разбиты на блоки по 1024 байта. Распаковываем из base64. Расшифровываем с помощью JCP из примера CMS_samples\CMSDecrypt.java Получаем торможение около 3-4 минут и 100% загрузку cpu на разборе CMS all.decode(dbuf); Через Cades проблема не возникает. Отредактировано пользователем 9 декабря 2019 г. 10:35:05(UTC)
| Причина: Не указана
|
|
|
|
|
|
Быстрый переход
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.
Important Information:
The Форум КриптоПро uses cookies. By continuing to browse this site, you are agreeing to our use of cookies.
More Details
Close
