28. Транспортное кодирование
В некоторых системах передачи информации требуется, чтобы поток содержал только определенные символы ASCII кодировки. Однако, выходной поток криптоалгоритма имеет очень высокую рандомизацию и в нем встречаются с равной вероятностью все 256 символов. Для преодоления этой проблемы используется транспортное кодирование.
Поскольку системы шифрования данных часто используются для кодирования текстовой информации : переписки, счетов, платежей электронной коммерции, и при этом криптосистема должна быть абсолютно прозрачной для пользователя, то над выходным потоком криптосистемы часто производится транспортное кодирование, то есть дополнительное кодирование (не шифрование !) информации исключительно для обеспечения совместимости с протоколами передачи данных.
Все дело в том, что на выходе криптосистемы байт может принимать все 256 возможных значений, независимо от того был ли входной поток текстовой информацией или нет. А при передаче почтовых сообщений многие системы ориентированы на то, что допустимые значения байтов текста лежат в более узком диапазоне : все цифры, знаки препинания, алфавит латиницы плюс, возможно, национального языка. Первые 32 символа набора ASCII служат для специальных целей. Для того, чтобы они и некоторые другие служебные символы никогда не появились в выходном потоке используется транспортное кодирование.
Наиболее простой метод состоит в записи каждого байта двумя шестнадцатиричными цифрами-символами. Так байт 252 будет записан двумя символами 'FC'; байт с кодом 26, попадающий на специальный символ CTRL-Z, будет записан двумя допустимыми символами '1A'. Но эта схема очень избыточна : в одном байте передается только 4 бита информации.
На самом деле практически в любой системе коммуникации без проблем можно передавать около 68 символов (латинский алфавит строчный и прописной, цифры и знаки препинания). Из этого следует, что вполне реально создать систему с передачей 6 бит в одном байте (26<68), то есть кодировать 3 байта произвольного содержания 4-мя байтами из исключительно разрешенных (так называемых печатных) символов. Подобная система была разработана и стандартизирована на уровне протоколов сети Интернет – это система Base64 (стандарт RFC1251).
Процесс кодирования преобразует 4 входных символа в виде 24-битной группы, обрабатывая их слева направо. Эти группы затем рассматриваются как 4 соединенные 6-битные группы, каждая из которых транслируется в одиночную цифру алфавита base64. При кодировании base64 входной поток байтов должен быть упорядочен старшими битами вперед.
Каждая 6-битная группа используется как индекс для массива 64-х печатных символов. Символ, на который указывает значение индекса, помещается в выходную строку. Эти символы выбраны так, чтобы быть универсально представимыми и исключают символы, имеющие специальное значение (".", CR, LF).
Выходной поток (закодированные байты) должен иметь длину строк не более 76 символов. Все признаки перевода строки и другие символы, отсутствующие в таблице 1, должны быть проигнорированы декодером base64. Среди данных в Base64 символы, не перечисленные в табл. 1, переводы строки и т.п. должны говорить об ошибке передачи данных, и, соответственно, программа-декодер должна оповестить пользователя о ней.
Если в хвосте потока кодируемых данных осталось меньше, чем 24 бита, справа добавляются нулевые биты до образования целого числа 6-битных групп. А до конца 24-битной группы может оставаться только от 0 до 3-х недостающих 6-битных групп, вместо каждой из которых ставится символ-заполнитель "=". Поскольку весь входной поток представляет собой целое число 8-битных групп (т.е., просто байтных значений), то возможны лишь следующие случаи:
Входной поток оканчивается ровно 24-битной группой (длина файла кратна 3). В таком случае выходной поток будет оканчиваться четырьмя символами Base64 без каких либо дополнительных символов.
"Хвост" входного потока имеет длину 8 бит. Тогда в конце выходного кода будут два символа Base64, с добавлением двух символов "=".
"Хвост" входного потока имеет длину 16 бит. Тогда в конце выходного будут стоять три символа Base64 и один символ "=".
Так как символ "=" является хвостовым заполнителем, его появление в теле письма может означать только то, что конец данных достигнут. Но опираться на поиск символа "=" для обнаружения конца файла неверно, так как, если число переданных битов кратно 24, то в выходном файле не появится ни одного символа "="
- 1. Понятие информационной безопасности
- 2. Важность и сложность проблемы информационной безопасности
- 3. Основные составляющие информационной безопасности
- 4. Категории информационной безопасности
- 5. Требования к политике безопасности в рамках iso
- 6. Общие сведения о стандартах серии iso 27000
- Разработчики международных стандартов
- Русские переводы международных стандартов
- 7. Iso 15408 - Общие критерии оценки безопасности информационных технологий
- 8. Iso 18028 - Международные стандарты сетевой безопасности серии
- Iso/iec 18028-1:2006 Информационные технологии. Методы обеспечения безопасности. Сетевая ит безопасность. Управление сетевой безопасностью.
- Iso/iec 18028-5:2006 Информационные технологии. Методы обеспечения безопасности. Защита сетевых взаимодействий при помощи Виртуальных Частных Сетей
- 9. Российские стандарты гост
- 10. Модель сетевого взаимодействия
- 11. Модель безопасности информационной системы
- 12. Классификация криптоалгоритмов
- 13. Алгоритмы симметричного шифрования
- 14. Криптоанализ
- Дифференциальный и линейный криптоанализ
- 15. Используемые критерии при разработке алгоритмов
- 16. Сеть Фейштеля
- 17. Алгоритм des Принципы разработки
- Проблемы des
- 18. Алгоритм idea
- Принципы разработки
- Криптографическая стойкость
- 21. Создание случайных чисел
- 22. Требования к случайным числам
- Случайность
- Непредсказуемость
- Источники случайных чисел
- Генераторы псевдослучайных чисел
- Криптографически созданные случайные числа
- Циклическое шифрование
- Режим Output Feedback des
- Генератор псевдослучайных чисел ansi x9.17
- 23. Разработка Advanced Encryption Standard (aes) Обзор процесса разработки aes
- Обзор финалистов
- Критерий оценки
- Запасной алгоритм
- Общая безопасность
- 25. Основные способы использования алгоритмов с открытым ключом
- Алгоритм rsa
- 27. Алгоритм обмена ключа Диффи-Хеллмана
- 28. Транспортное кодирование
- 29. Архивация
- Требования к хэш-функциям
- 31. Цифровая подпись Требования к цифровой подписи
- Прямая и арбитражная цифровые подписи
- 32. Симметричное шифрование, арбитр видит сообщение:
- 33. Симметричное шифрование, арбитр не видит сообщение:
- 34. Шифрование открытым ключом, арбитр не видит сообщение:
- 35. Стандарт цифровой подписи dss
- Подход dss
- 36. Отечественный стандарт цифровой подписи гост 3410
- 37. Алгоритмы распределения ключей с использованием третьей доверенной стороны Понятие мастер-ключа
- 38. Протоколы аутентификации
- Взаимная аутентификация
- 39. Элементы проектирования защиты сетевого периметра.
- 40. Брандмауэр и маршрутизатор.
- 41. Брандмауэр и виртуальная частная сеть.
- 42. Многоуровневые брандмауэры.
- 43. Прокси-брандмауэры.
- 44.Типы прокси.
- 46.Недостатки прокси-брандмауэров.
- 48. Виртуальные локальные сети.
- 49. Границы виртуальных локальных сетей.
- 50. Частные виртуальные локальные сети.
- 51. Виртуальные частные сети.
- 52. Основы построения виртуальной частной сети.
- 53. Основы методологии виртуальных частных сетей.
- 54. Туннелирование.
- 55. Защита хоста.
- 56. Компьютерные вирусы
- Структура и классификация компьютерных вирусов
- 2.3.3. Механизмы вирусной атаки
- 58. Протокол ррр рар
- 59. Протокол ррр chap
- 60. Протокол ррр еар
- 68. Виртуального удаленного доступа
- 69. Сервис Директории и Служб Имен
- 70. По и информационная безопасность
- 71. Комплексная система безопасности. Классификация информационных объектов