С другой стороны, книге не хватает хорошего редактора/корректора. Очень много мелочей для издания такого уровня. Начиная от постоянных отсылок к выделению синим цветом (хотя вся книга выпущена в чб) и заканчивая смысловыми опечатками в формулах. Перепутанные рисунки. Отсутствующий рисунок на который идет отсылка в тексте. Тире, которое не соответсвует правилам русской типографики.
Потому что это приводит все к тем же вопросам доверия центрам сертификации, что и https. Плюс у большинства отсутствуют сертификаты, подписанные доверенными центрами сертификации. Т.ч. S/MIME хорош, но только в корпоративной среде, где есть четкое понимание, кому IT выдает сертификаты и почему.
6lowpan работают поверх 802.15.4 и поверх BT. А главное, что это просто IPv6. Поэтому это универсальная прослойка между ,, странными'' сетками. Т.е. поверх других физических интерфейсов не обязательно прокидывать именно 6lowpan. Достаточно прокинуть просто IPv6.
В PKCS#12 имени ТК26 изменен алгоритм формирования ключа для подписи. Вместо специального алгоритма из PKCS#12 используются последние 32 байта из 96-байтного вывода PBKDF2. Hope this helps.
Плюс, там достаточно большое пространство для отклонений в записи приватных ключей. Если будет интересно, пишите в личку, можно попытаться пофиксить.
Текущие реализации ГОСТ 28147-89 по массиву {0xff, 0xfe, 0xfd, ..., 0xee, 0xff} строят ключевое расписание {0xfcfdfeff, 0xf8f9fafb, 0xf4f5f6f7, 0xf0f1f2f3, 0x33221100, 0x77665544, 0xbbaa9988, 0xffeeddcc}, а не {0xffeeddcc, 0xbbaa9988, 0x77665544, 0x33221100, 0xf0f1f2f3, 0xf4f5f6f7, 0xf8f9fafb, 0xfcfdfeff}, как записано в ГОСТ 34.12-2015.
Более того, такой («старый») способ построения ключевого расписания соответствует примеру из окончательной редакции проекта «Криптографические алгоритмы, сопутствующие
применению алгоритмов электронной цифровой подписи и функции хэширования»
Переформулирую вопрос: получается, что ключ считывается как единый вектор в формате Little endian от начала и до конца. В этом есть некая логика. По сути новый стандарт меняет порядок подключей в ключевом расписании по сравнению с традиционными способами применения ГОСТ 28147-89. Правильно ли я понимаю, что все предыдущие документы/стандарты, которые использовали ГОСТ 28147-89, например тот же ТК26CMS, оказываются несоответствующими ГОСТ Р 34.12-2015?
Переменные в другой секции лежат.
Можно engine использовать внешнюю.
С одной стороны, спасибо за книгу.
С другой стороны, книге не хватает хорошего редактора/корректора. Очень много мелочей для издания такого уровня. Начиная от постоянных отсылок к выделению синим цветом (хотя вся книга выпущена в чб) и заканчивая смысловыми опечатками в формулах. Перепутанные рисунки. Отсутствующий рисунок на который идет отсылка в тексте. Тире, которое не соответсвует правилам русской типографики.
https://github.com/lumag/emv-tools
А чем они принципиально отличаются от, например, DigiNotar, Comodo или StartCom/WoSign? Я делал доклад на смежную тему на CTCrypt'2014.
Потому что это приводит все к тем же вопросам доверия центрам сертификации, что и https. Плюс у большинства отсутствуют сертификаты, подписанные доверенными центрами сертификации. Т.ч. S/MIME хорош, но только в корпоративной среде, где есть четкое понимание, кому IT выдает сертификаты и почему.
git rebase — это плохо. Теряется контекст разработки, затрудняется работа git bisect и т. п.
Да, в таком случае обычные PAN решения плохо сработают.
6lowpan работают поверх 802.15.4 и поверх BT. А главное, что это просто IPv6. Поэтому это универсальная прослойка между ,, странными'' сетками. Т.е. поверх других физических интерфейсов не обязательно прокидывать именно 6lowpan. Достаточно прокинуть просто IPv6.
Координатор, чаще всего, является нодой с постоянным питанием и большими ресурсами. Проблема его разрядки, обычно, не возникает.
API в виде сокетов действительно удобнее. Когда мы писали 802.15.4, тоже пришли к сокетному API для приложений.
Кстати говоря, а почему вы выбрали WAN-решение?
Еще, у Вас в server_csr не проходит создание ключей -2012, только -2001:
В PKCS#12 имени ТК26 изменен алгоритм формирования ключа для подписи. Вместо специального алгоритма из PKCS#12 используются последние 32 байта из 96-байтного вывода PBKDF2. Hope this helps.
Плюс, там достаточно большое пространство для отклонений в записи приватных ключей. Если будет интересно, пишите в личку, можно попытаться пофиксить.
Текущие реализации ГОСТ 28147-89 по массиву {0xff, 0xfe, 0xfd, ..., 0xee, 0xff} строят ключевое расписание {0xfcfdfeff, 0xf8f9fafb, 0xf4f5f6f7, 0xf0f1f2f3, 0x33221100, 0x77665544, 0xbbaa9988, 0xffeeddcc}, а не {0xffeeddcc, 0xbbaa9988, 0x77665544, 0x33221100, 0xf0f1f2f3, 0xf4f5f6f7, 0xf8f9fafb, 0xfcfdfeff}, как записано в ГОСТ 34.12-2015.
Более того, такой («старый») способ построения ключевого расписания соответствует примеру из окончательной редакции проекта «Криптографические алгоритмы, сопутствующие
применению алгоритмов электронной цифровой подписи и функции хэширования»
Переформулирую вопрос: получается, что ключ считывается как единый вектор в формате Little endian от начала и до конца. В этом есть некая логика. По сути новый стандарт меняет порядок подключей в ключевом расписании по сравнению с традиционными способами применения ГОСТ 28147-89. Правильно ли я понимаю, что все предыдущие документы/стандарты, которые использовали ГОСТ 28147-89, например тот же ТК26CMS, оказываются несоответствующими ГОСТ Р 34.12-2015?