Статус: Новичок
  Группы: Участники
 Зарегистрирован: 15.02.2021(UTC) Сообщений: 5   
	 
	
     | 
    
        
            
		      
                Пришла беда откуда не ждали - ФСС вводит спецификацию 2.0.  Результат - алгоритмы отработанные для спецификации 1 не работают для спецификации 2. Открываю спецификацию 2, ищу отличия от вер. 1.  Цитата из спецификации: "CALG_DH_GR3410_12_256_EPHEM - идентификатор алгоритма обмена ключей по Диффи-Хеллману на базе закрытого ключа эфемерной пары." Где я должен указать этот идентификатор, нужно ли мне его указывать?  Цитата из спецификации: "Возможные параметры шифратора GostJCE/CBC/ISO10126Padding". Сразу пугает слово "ВОЗМОЖНЫЕ". Смотрю в отладчике параметры шифратора на работающем алгоритме для спецификации 1. Mode = CFB; Padding = None; Аналога для GostJCE не нахожу. Это провайдер? Где же мне его найти в КриптоПро CSP? меняю параметры шифратора на: Mode = CBC; Padding = ISO10126Padding; Ответ сервиса: "Не удалось расшифровать сообщение." Кто виноват, мне понятно. Что делать? 
            
	  
         
     | 
    | 
         
             
     | 
    
         
            
         
     | 
    | 
        
	
     | 
        
        
        
            
        
            
            
    
        
	Статус: Эксперт
  Группы: Участники
 Зарегистрирован: 05.03.2015(UTC) Сообщений: 1,602  Откуда: Иркутская область Сказал(а) «Спасибо»: 110 раз Поблагодарили: 397 раз в 367 постах
  
	 
	
     | 
    
        
            
		      
                Добрый день. Спецификация похоже для как обычно Джавы, на которой пишут свою сторону разработчики спецификации. Для дотнета (и других средств подписания/шифрования) эти "GostJCE" все "абракадабра" для которой надо подобрать адекватные названия уже из дотнета. Снова придется методом тыка и сравнения с программой самого ФСС.
  На уровне предположений (пока не читал спецификацию 2.0): что алгоритм это вот все то, что раньше делали вручную по схеме обмена ключей - теперь это запихано на стороне ФСС в штатную функцию. "CALG_" это обычно самый нижний уровень функций. И ключевая пара теперь эфемерная (создается на короткое время; опять же предположу, что отправителю теперь не нужен долговременный ключ и сертификат - тогда вместо сертификата требуется указать открытый ключ эфемерной пары). То есть либо тоже запихиваем в стандарт (по идее для этого уже должен быть провайдер) либо опять же подбираем параметры при которых это может работать с прошлой версией (с долговременными ключами - какая-то вырезка открытого ключа из сертификата, может быть). 
            
	  
         
     | 
    | 
         
             
     | 
    
         
            
         
     | 
    | 
        
	
     | 
        
        
        
    
        
            
            
    
        
	Статус: Сотрудник
  Группы: Участники
 Зарегистрирован: 06.12.2008(UTC) Сообщений: 4,064  Откуда: Крипто-Про Сказал(а) «Спасибо»: 21 раз Поблагодарили: 740 раз в 698 постах
  
	 
	
     | 
    
        
            
		      
                Здравствуйте. Автор: zzz17   CALG_DH_GR3410_12_256_EPHEM - идентификатор алгоритма обмена ключей по Диффи-Хеллману на базе закрытого ключа эфемерной пары." Где я должен указать этот идентификатор, нужно ли мне его указывать? "Возможные параметры шифратора GostJCE/CBC/ISO10126Padding". Аналога для GostJCE не нахожу.
 
  CALG_DH_GR3410_12_256_EPHEM - идентификатор алгоритма выработки ключа обмена, должен быть в WinCryptEx.h. Вероятно, указывается при создании эфемерного ключа с участием открытого ключа другой стороны для экспорта ключа шифрования (для вставки в сообщение в адрес получателя) или с участием закрытого ключа для импорта блоба ключа шифрования (на стороне получателя). Из JCPxml (java-библиотека в составе JCP провайдера) GostJCE - это GOST28147. Алгоритм зарегистрирован, например, в jcp.xml в составе JCPxml.jar. Соответственно, алгоритм шифрования данных - GOST28147/CBC/ISO10126Padding Отредактировано пользователем 15 февраля 2021 г. 13:40:47(UTC)
 | Причина: Не указана    | 
 | 
            
	 
        
    
    | 
         
             
     | 
    
         
            
         
     | 
    | 
        
	
     | 
        
        
        
            
        
            
            
    
        
	Статус: Новичок
  Группы: Участники
 Зарегистрирован: 25.10.2019(UTC) Сообщений: 4  Сказал(а) «Спасибо»: 1 раз
  
	 
	
     | 
    
        
            
		      
                Добрый день. zzz17, получилось у Вас отправить в ФСС зашифрованный запрос по спецификации 2.0? На .net тоже не работает вариант для спецификации 1.1. Ошибка от ФСС: "не удалось расшифровать запрос". 
  Может работники КриптоПро будут столь любезны и поделятся рабочим примером как используя КриптоПро.Net SDK зашифровать данные для ФСС по спецификации 2.0? Из известных мне ранее разработчиков, писавших софт для 1.1, еще ни у кого не получилось отправить запрос по спецификации 2.0 (сервис страхователя для получения ЭЛН 2.0).
  Готов купить пример (где и с кем обсудить?). С другой стороны, фирме Крипто Про должно быть выгодно поделиться этим примером бесплатно, чтобы те, кто строит инфраструктуру выбрали в качестве провайдера КриптоПро CSP и КриптоПро.Net в качестве средства доступа к КриптоПро CSP.
  Мы вот купили КриптоПро.Net для каждого АРМ, с которого обращаются в ФСС. Даже по спецификации ФСС 1.1 не получилось реализовать все силами только КриптоПро.Net SDK для ключа ГОСТ-2012. Пришлось добавлять в проект opensource GostCryptograhy (MIT) для того, чтобы было возможным дешифровать ответ.  
  Причем темы на этом форуме появляются относительно ЭЛН ФСС, однако ответы только в стиле - "сто раз обсуждалось, ищите". А решения находились не на этом форуме, что странно, а на cyberforum, github и в переписке с коллегами.  Наверное, так быть не должно? 
            
	  
         
     | 
    | 
         
             
     | 
    
         
            
         
     | 
    | 
        
	
     | 
        
        
        
    
        
            
            
    
        
	Статус: Новичок
  Группы: Участники
 Зарегистрирован: 15.02.2021(UTC) Сообщений: 5   
	 
	
     | 
    
        
            
		      
                Добрый день, Alex AD! Нет, пока спецификацию 2.0 победить не удалось. 
            
	  
         
     | 
    | 
         
             
     | 
    
         
            
         
     | 
    | 
        
	
     | 
        
        
        
            
        
            
            
    
        
	Статус: Участник
  Группы: Участники
 Зарегистрирован: 25.01.2019(UTC) Сообщений: 27   Сказал «Спасибо»: 3 раз Поблагодарили: 9 раз в 3 постах
  
	 
	
     | 
    
        
            
		      
                У кого-нибудь получилось отправить шифрованный запрос на ФСС по 2.0? 
            
	  
         
     | 
    | 
         
             
     | 
    
         
            
         
     | 
    | 
        
	
     | 
        
        
        
    
        
            
            
    
        
	Статус: Участник
  Группы: Участники
 Зарегистрирован: 25.01.2019(UTC) Сообщений: 27   Сказал «Спасибо»: 3 раз Поблагодарили: 9 раз в 3 постах
  
	 
	
     | 
    
        
     | 
    | 
         
             
     | 
    
         
            
         
     | 
    | 
        
	
     | 
        
        
        
            
        
            
            
    
        
	Статус: Новичок
  Группы: Участники
 Зарегистрирован: 15.02.2021(UTC) Сообщений: 5   
	 
	
     | 
    
        
            
		      
                Добрый день, Alexcrool!
  Я посмотрел пример по указанной вами ссылке. Есть дата - 2019 г. Это спецификация 1. Номер спецификации подтверждается и фрагментом заготовки xml-файла: <EncryptedData  Type="http://www.w3.org/2001/04/xmlenc#Element" Для спецификации 2: <EncryptedData  Type="http://www.w3.org/2001/04/xmlenc#Content".
  Что мы имеем? В форуме КриптоПро большое количество ссылок на примеры построения приложений для спецификации 1 с  использованием:  - высокоуровневых функций Крипто API на языках С#(КриптоПро NET), java (КриптоПро Java CSP). Здесь нет эфемерной пары(явно). Параметры шифратора CFB/None.  - низкоуровневых функций Крипто API на языках С, Delphi. Здесь идет игра с эфемерной парой, с согласованием ключа  на алгоритме Диффи-Хеллмана. Параметры шифратора GostJCE/CBC/ISO10126Padding.
  Становится понятна фраза из спецификации 2: "Возможные параметры шифратора GostJCE/CBC/ISO10126Padding". Действительно, возможны эти параметры, возможны другие.
  Выводы: 1. Спецификация 2 (как документ) ничем не отличается от спецификации 1.  Новые параграфы спецификации 2 в разделе "шифрование" описывают частный случай реализации шифрования и не содержат  полезной информации. 2. В спецификация 2 нет данных об изменениях сделанных в алгоритме/параметрах шифрования, поэтому на основе спецификации 2 невозможно сделать работающее приложение.
  Какой то чудак решил, что с сервисами ФСС могут работать только "правильные" компании? Как бы дело не закончилось большим скандалом.  
            
	  
         
     | 
    | 
         
             
     | 
    
         
            
         
     | 
    | 
        
	
     | 
        
        
        
    
        
            
            
    
        
	Статус: Участник
  Группы: Участники
 Зарегистрирован: 25.01.2019(UTC) Сообщений: 27   Сказал «Спасибо»: 3 раз Поблагодарили: 9 раз в 3 постах
  
	 
	
     | 
    
        
            
		      
                Я тоже в итоге пришел к такому выводу. И сделал запрос в 1С. Там раздел больничные листы в "зарплаты и кадры" реализован. Очень надеюсь на сотрудничество с ними!!!
  А все таки как думаете, играть нужно с параметрами шифрования? CFB,CBC,Padding... остальное вроде по API не убавить не прибавить 
            
	  
         
     | 
    | 
         
             
     | 
    
         
            
         
     | 
    | 
        
	
     | 
        
        
        
            
        
            
            
    
        
	Статус: Новичок
  Группы: Участники
 Зарегистрирован: 15.02.2021(UTC) Сообщений: 5   
	 
	
     | 
    
        
            
		      
                Играться можно. Но в IT-секторе есть устоявшиеся правила. Разработчик при изменении алгоритмов обязан доводить информацию до всех заинтересованных сторон. 
            
	  
         
     | 
    | 
         
             
     | 
    
         
            
         
     | 
    | 
        
	
     | 
        
        
        
    
	                           
	
    
        Быстрый переход
         
	
    
    Вы не можете создавать новые темы в этом форуме.
	
	Вы не можете отвечать в этом форуме.
	
	Вы не можете удалять Ваши сообщения в этом форуме.
	
	Вы не можете редактировать Ваши сообщения в этом форуме.
	
	Вы не можете создавать опросы в этом форуме.
	
	Вы не можете голосовать в этом форуме.
	
	
    
    
        Important Information:
        The Форум КриптоПро uses cookies. By continuing to browse this site, you are agreeing to our use of cookies.
        
        
More Details
        Close