информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
За кого нас держат?Страшный баг в WindowsАтака на Internet
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Три миллиона электронных замков... 
 Doom на газонокосилках 
 Умер Никлаус Вирт 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / theory
Имя Пароль
ФОРУМ
все доски
FAQ
IRC
новые сообщения
site updates
guestbook
beginners
sysadmin
programming
operating systems
theory
web building
software
hardware
networking
law
hacking
gadgets
job
dnet
humor
miscellaneous
scrap
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Я ж не про ошибки на этапе компиляции. Ну пусть это не... 13.06.06 13:45  Число просмотров: 3179
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 13.06.06 13:48  Количество правок: 2
<"чистая" ссылка>
> > 2. buffer, указатель, указывающий на константу. При
> > ожидаемой модификации будет segmentation fault.
>
> Не факт. Принимаемое значение скорее всего (char *), а не
> (char[]) и не (const char *). Очень многие библиотечные

Я ж не про ошибки на этапе компиляции. Ну пусть это не константная строка, описание char * еще не признак того, что она меняется. Указатель на константу лишь будет говорить то, что она заведомо не меняется. Указатель не на константу вполне можно проинициализировать указателем на контстанту, как, впрочем, если сделать все наоборот - тоже. Компилятор не даст ничего изменить по адресу соответствующего указателя (на константу), что избавляет от ошибок программиста и RunTimeError при выполнении на определенных системах. Та же система выдаст предупреждение или сообщит об ошибке, если в параметрах функции char *, а передавать пытаешся указатель на константу. Замечал, что практически все компиляторы считают, что если параметр не постоянный, то в функции он будет менятся.

> функции для возвращаемого значения используют вот такую вот
> пару буфер/длина. То что на самом деле буфер - константа -
> это не проблема библиотеки, а проблема клиента этой
> библиотеки (вполне возможно где то в описалове это указано)

Это точно, как говорится - сам дурак. Если в качестве буфера для возврата передаешь константную строку.
Если функция работает со строкой, то либо она ее не изменяет (не использует для возврата результата), либо конвертирует ее в такую же по длине и функции преобразования кодировки тому пример. Все остальное будет резать глаз/слух.

> > 3. Шифровка будет соизмерима с длиной ключа, а не с
> > исходным текстом. Так что она просто не поместится в
> > buffer, если
> strlen(buffer)<sizeof(cryptContext->key)
> > (извиняюсь за корявое неравенство).
>
> Вот это 100%. Причем вполне возможно, что шифрование не
> происходит именно по этой причине. Просто переданный буфер
> меньше размера ключа и библиотека возвращается с ошибкой.

Это же не просто проблема, а проблема номер 1. А именно важно не просто передать килобитные данные, а что численно они были меньше N. Поэтому даже обменом массивами/структурами фиксированного размера пользоваться ндо очень осторожно.
Как все просто с симметричным блочным шифрованием. Полагаю библиотечная функция не должна возвращать ошибку, а дробить заданный текст на блоки подходящего размера, их шифровать и возвращать серию блоков.

> > 4. По хорошему функция шифрования должна возвращать
> > шифровку и (полагаю) должна быть описана примерно так:
> char
> > *cryptEncrypt( cryptContext, buffer, strlen(buffer) );
> > Возможно и другие варианты, например
> cryptContext->cifer
> > и будет указателем на зашифрованый текст.
>
> Как по мне возврат буфера - плохая идея, а вот возврат
> шифровки в контексте - вполне возможный вариант. Если так,
> то скорее всего должна быть еще и функция-getter для
> сокрытия внутренностей контекста.

По мне тоже плохая, так как где-то должно быть описаны правила очистки буфера. То есть скорее всего он будет выделяться обычным malloc'ом, а высвобождать после использования должен пользователь(программист) библиотеки.
Возможет вариант (как sprintf), когда программист передает и буфер для результата плюс его длина или он обязан передать буфер достаточного размера.

Короче даже (тем более) для собственного самообразования рекомендуется написать все это самостоятельно, а не пользоваться чужой библиотекой.
<theory> Поиск 






Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2024 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach