Статус: Активный участник
Группы: Участники
Зарегистрирован: 12.07.2021(UTC) Сообщений: 39  Сказал(а) «Спасибо»: 10 раз
|
Как можно узнать размер подписи до самого подписания? Подпись помещяю в контейнер в файле, но контейнер нужно выделить зарание чтобы получить размеры подписываемых данных и далее их подписать, сейчас приходится выделять зарание больший объем.
c CadesBes все хорошо, 8172 байт хавтало за глаза. но вот с CadesXLongType1 дело обстоит куда хуже, требуется более 65536 байт. Но раздувать файл не хочется.
|
|
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 26.07.2011(UTC) Сообщений: 14,161   Сказал «Спасибо»: 618 раз Поблагодарили: 2389 раз в 1880 постах
|
Автор: Depish  Как можно узнать размер подписи до самого подписания? Подпись помещяю в контейнер в файле, но контейнер нужно выделить зарание чтобы получить размеры подписываемых данных и далее их подписать, сейчас приходится выделять зарание больший объем.
1) подписать произвольные данные (1 байт) - получить размер и подписывать уже реальные байты 2) выделять с запасом. Автор: Depish  c CadesBes все хорошо, 8172 байт хавтало за глаза. но вот с CadesXLongType1 дело обстоит куда хуже, требуется более 65536 байт. Но раздувать файл не хочется.
Таковы требования, обычно от 25 Кб. Размер зависит от УЦ и доступности OCSP. Если не хочется => не использовать XLongType1 |
|
|
|
|
|
|
Статус: Эксперт
Группы: Участники
Зарегистрирован: 05.03.2015(UTC) Сообщений: 1,602  Откуда: Иркутская область Сказал(а) «Спасибо»: 110 раз Поблагодарили: 397 раз в 367 постах
|
Добрый день. Можно посоветовать не записывать весь буфер для подписи (который выделили заведомо больше подписи), а посмотреть сколько байт из буфера занято после подписания и записать только их. Думаю, уже обсуждали вопрос про раздувание подписи. Вообще говоря если у Вас не идет речь о миллионах подписей (большой размер суммарно) или подписи очень маленьких файлов (когда размер открепленной подписи более чем сам файл и выходит низкий КПД хранения), то проще всего хранить "как есть" и не выдумывать. Так ни у кого не будет шанса придраться и сказать, что Ваше вмешательство ставит по сомнение достоверность подписи. Если же все равно хотите "оптимизировать"... В теории XLongType1 включает в себя (помимо самой подписи и метки доверенного времени на подпись) еще и доказательства подписи (короткий ответ OCSP про один сертификат или объемный список отзыва сертификатов - до нескольких мегабайт, но про все сертификаты от данного УЦ) и метку доверенного времени на доказательства. Если подписывать много документов в один день одним закрытым ключом (т.е. один и тот же сертификат в подписи), то доказательства будут в принципе те же самые для всех подписанных документов, немного отличается время и только. Если речь про список отзыва, то доказательства будут те же самые для всех действующих на конец дня сертификатов одного УЦ.
Судя по тому, что речь идет о каких-то контейнерах и т.д. вероятно Вы не храните подпись "как есть" отдельным файлом, а дополнительно ее как-то обрабатываете/обертываете. В принципе, Вы также можете временно отделить доказательства (что аналогично формату CadesBes) и вместо повторяющихся доказательств в каждой подписи хранить отдельно для каждого сертификата последние доказательства на какую-то дату, а когда извлекаете подпись из контейнера прикрепить подходящие (по УЦ и дате) доказательства обратно. При такой технике будет выглядеть как будто подписали CadesBes, получили на подпись метку времени (что-то вроде CadesT), а доказательства добавили (окончательно доусовершенствовали до XLongType1) в конце суток. Случай как бы нестандартный, но проходить проверку должен.
Если используются сертификаты одного УЦ с большим списком отзыва и без OCSP, то экономия места может быть весьма существенная. Однако манипуляции теоретически могут под сомнение достоверность подписи.
Суть конечно немного надуманная - составление подписи более сложного формата из по сути уже подписанных блоков технически все равно попадает как формирование подписи нового формата (с CadesBes и доказательств составляется XLongType1), что формально требует сертифицированного СКЗИ.
Отредактировано пользователем 8 февраля 2022 г. 8:08:48(UTC)
| Причина: Не указана
|
|
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 26.07.2011(UTC) Сообщений: 14,161   Сказал «Спасибо»: 618 раз Поблагодарили: 2389 раз в 1880 постах
|
Автор: two_oceans  Добрый день. Можно посоветовать не записывать весь буфер для подписи (который выделили заведомо больше подписи), а посмотреть сколько байт из буфера занято после подписания и записать только их. Думаю, уже обсуждали вопрос про раздувание подписи. Вообще говоря если у Вас не идет речь о миллионах подписей (большой размер суммарно) или подписи очень маленьких файлов (когда размер открепленной подписи более чем сам файл и выходит низкий КПД хранения), то проще всего хранить "как есть" и не выдумывать. Так ни у кого не будет шанса придраться и сказать, что Ваше вмешательство ставит по сомнение достоверность подписи. Если же все равно хотите "оптимизировать"... В теории XLongType1 включает в себя (помимо самой подписи и метки доверенного времени на подпись) еще и доказательства подписи (короткий ответ OCSP про один сертификат или объемный список отзыва сертификатов - до нескольких мегабайт, но про все сертификаты от данного УЦ) и метку доверенного времени на доказательства. Если подписывать много документов в один день одним закрытым ключом (т.е. один и тот же сертификат в подписи), то доказательства будут в принципе те же самые для всех подписанных документов, немного отличается время и только. Если речь про список отзыва, то доказательства будут те же самые для всех действующих на конец дня сертификатов одного УЦ.
Судя по тому, что речь идет о каких-то контейнерах и т.д. вероятно Вы не храните подпись "как есть" отдельным файлом, а дополнительно ее как-то обрабатываете/обертываете. В принципе, Вы также можете временно отделить доказательства (что аналогично формату CadesBes) и вместо повторяющихся доказательств в каждой подписи хранить отдельно для каждого сертификата последние доказательства на какую-то дату, а когда извлекаете подпись из контейнера прикрепить подходящие (по УЦ и дате) доказательства обратно. При такой технике будет выглядеть как будто подписали CadesBes, получили на подпись метку времени (что-то вроде CadesT), а доказательства добавили (окончательно доусовершенствовали до XLongType1) в конце суток. Случай как бы нестандартный, но проходить проверку должен.
Если используются сертификаты одного УЦ с большим списком отзыва и без OCSP, то экономия места может быть весьма существенная. Однако манипуляции теоретически могут под сомнение достоверность подписи.
Суть конечно немного надуманная - составление подписи более сложного формата из по сути уже подписанных блоков технически все равно попадает как формирование подписи нового формата (с CadesBes и доказательств составляется XLongType1), что формально требует сертифицированного СКЗИ.
у ТС, по описанию, PAdES. |
|
|
|
|
|
|
Быстрый переход
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.
Important Information:
The Форум КриптоПро uses cookies. By continuing to browse this site, you are agreeing to our use of cookies.
More Details
Close