До недавнего времени я и не подозревал, что пользуюсь электронной подписью, когда оплачиваю сотовую связь через интернет-банк, пока не увидел «Простая электронная подпись Ким Н.Г. от 31.12.9999» в платёжном поручении. Здесь код подтверждения в SMS является частью реализации облачной ЭП, о которой говорится в статье. Это удобно и, доверяя своему банку, я этим пользуюсь.
Тем не менее, смарт-карту, даже полную закладок, я хотя бы могу взять в руки и таким образом контролировать физическое местонахождение ключей, а организовав воздушный зазор — полагать, что они случайно не попадут в чужие руки во время использования.
На рабочем мониторе предпочитаю тёмную расцветку, меньше устают глаза, а со светлой слезятся через какое-то время. Дома же — наоборот, легче работать со светлой. Всегда работаю с внешним освещением, то есть не в темноте.
Полагаю, надо как-то правильно настроить монитор, тогда выбор цветовой темы останется только лишь делом вкуса и личных предпочтений. Как вы считаете?
Вероятно, изложенный в статье материал для многих читателей является очевидным, но мне, напрямую не связанному с вёрсткой и дизайном, теперь понятно, чем отличается резиновый макет от отзывчивого. Очень наглядно, спасибо!
Возможно, в будущем появится возможность встраивать метки в более удобные места (пальцы, например) или появятся активные импланты со встроенным источником питания, что позволит увеличить дальность считывания. Вроде бы карты с батарейкой уже есть, правда?
Да, идея идея очень заманчивая, но смущает что стандарт на этот алгоритм пока что черновой и что-то (не знаю что) может поменяться. Вам случайно не известны «большие» его применения, реализованные уже сейчас?
К сожалению, нет. У меня даже нет лицензии на разработку, производство и распространение криптографических средств :)
Можно считать, что это исключительно из академического интереса.
В описании метода TransformBlock из MSDN ничего не сказано про обработку неполных блоков. Можно предположить, что этот метод предназначен исключительно для преобразования полных блоков, тем более, что с неполными работает TransformFinalBlock:
TransformFinalBlock is a special function for transforming the last block or a partial block in the stream. It returns a new array that contains the remaining transformed bytes. A new array is returned, because the amount of information returned at the end might be larger than a single block when padding is added.
В данной реализации последний блок теперь может быть неполным, это мы исправили в прошлый раз. Как я понимаю, под «partial block» имеется в виду последний неполный блок, а не любой неполный блок в исходном сообщении. Итого получается, что TransformBlock должен работать с полными блоками, а TransformFinalBlock — с полным или неполным.
Выходит, можно ограничиться проверкой размера блока в TransformBlock, чтобы формально соблюсти интерфейс ICryptoTransform.
Этот класс предполагается использовать в CryptoStream. К сожалению, я не знаю, как он работает внутри с ICryptoTransform, но полагаю, что он принимает во внимание свойства InputBlockSize и OutputBlockSize, определённые в интерфейсе.
Да, мне не пришло в голову, что можно TransformBlock можно попытаться использовать для неполного блока.
В случае с полными работает верно, не так ли?
Как по вашему мнению, стоит ли следить за количеством обработанных байт и проворачивать гамму только после отработки целого блока, или же просто запретить (плохо звучит, но всё же) обрабатывать TransformBlock неполные блоки?
Действительно, в реализации я упустил этот момент, и зачем-то сделал проверку на длину исходного сообщения. На самом деле ограничение на размер блока актуально только для синхропосылки, которая шифруется в режиме простой замены, а для неполного последнего блока исходных данных просто используется не вся гамма целиком, а только необходимая часть. Спасибо за ценное замечание, поправил.
Да, тоже возникли сомнения по этому поводу. Если не изменяет память, в какой-то Express версии были отключены некоторые возможности по рефакторингу, ради того чтобы «облегчить» работу пользователям: если вам не нужна Professional, то и это вам не нужно.
Ограничивающим фактором для клавиатуры является не закон фитса, а сложность или даже невозможность нажатия некоторых комбинаций
Вспоминается плагин XML Tools для Notepad++ и его горячая клавиша Ctrl+Alt+Shift+B… но да, это всё же быстрее, чем Меню → Плагины → XML Tools → Pretty Print.
Тем не менее, смарт-карту, даже полную закладок, я хотя бы могу взять в руки и таким образом контролировать физическое местонахождение ключей, а организовав воздушный зазор — полагать, что они случайно не попадут в чужие руки во время использования.
платье синеесветлая.Полагаю, надо как-то правильно настроить монитор, тогда выбор цветовой темы останется только лишь делом вкуса и личных предпочтений. Как вы считаете?
Можно считать, что это исключительно из академического интереса.
В данной реализации последний блок теперь может быть неполным, это мы исправили в прошлый раз. Как я понимаю, под «partial block» имеется в виду последний неполный блок, а не любой неполный блок в исходном сообщении. Итого получается, что TransformBlock должен работать с полными блоками, а TransformFinalBlock — с полным или неполным.
Выходит, можно ограничиться проверкой размера блока в TransformBlock, чтобы формально соблюсти интерфейс ICryptoTransform.
Этот класс предполагается использовать в CryptoStream. К сожалению, я не знаю, как он работает внутри с ICryptoTransform, но полагаю, что он принимает во внимание свойства InputBlockSize и OutputBlockSize, определённые в интерфейсе.
В случае с полными работает верно, не так ли?
Как по вашему мнению, стоит ли следить за количеством обработанных байт и проворачивать гамму только после отработки целого блока, или же просто запретить (плохо звучит, но всё же) обрабатывать TransformBlock неполные блоки?
Правда, говорить в присутствии телевизора по-прежнему не стоит…