id: Гость   вход   регистрация
текущее время 22:26 28/03/2024
Владелец: Alex_B редакция от 29/12/2007 20:51 (автор: serzh) Печать
Категории: инфобезопасность, политика, разное
создать
просмотр
редакции
ссылки

Это старая редакция страницы Черновики / Статьи / Сервисметоквремени / Принципработы за 29/12/2007 20:51.


Принцип работы


Оглавление документа:


Принцип функционирования сервиса находится на стадии разработки. Комментарии, предложения, поправки крайне приветствуются.

Получение метки времени


Для получения метки времени, клиент1:


  1. Посредством web-интерфейса или программы, отправляет сервису данные, подлежащие заверению.

  1. Сервис формирует «метку времени»2, содержащую данные согласно формату.

Ref-Hash-X = Hash-X (предыдущая метка времени)

  1. Сервис публикует созданную «метку времени».

  1. Сервис отправляет клиенту «метку времени» (возможен произвольный формат), подписанную прозрачной подписью.

Вопрос:

  1. Как клиент узнает открытый ключ сервиса?
    • на странице сервиса — Serzh
    • Откуда у пользователя уверенность, что ему не посунули подделку? Нужно как-то протащить ключ в сеть доверия, что бы каждый мог проверить. — Alex_B
    • Оператор подписывает ключ службы своим персональным ключом, который связывается с сетью доверия всеми обычными способами. ?ли, если сайт службы работает по SSL, положиться на защищённость канала. А ещё лучше объединить оба способа. В общем, я здесь не вижу существенной проблемы. — SATtva
  2. Почему следует использовать SHA512?
    • используется несколько независимых хэш-функций — Serzh
    • вообще-то это не ответ на поставленный вопрос. ;-) на мой взгляд, использование RIPEMD-160 при наличии SHA-512 избыточно. можете привести хоть одну причину в её необходимости? — SATtva
    • Это требуется для долговременных меток (на несколько лет). Спустя несколько лет мы получим такую ситуацию: SHA512 – взломан, RIPEMD-160 – нет (или наоборот). Если мы использовали только адну хэш-функцию (взломаную), то доказать авторство на основе данной метки уже невозможно. Если одна функция ещё держится – то возможно. Поэтому необходимо добавлять все возможные принятые криптографическим сообществом хэш-функции. — Serzh
    • Да нет, это я прекрасно понимаю. Только сама по себе длина выхода SHA-512 такова, что даже при успешных атаках, снижающих теоретическую стойкость алгоритма, практически, на мой взгляд, он едва ли когда-нибудь станет уязвим. Учитывая скорость SHA-512, я бы предложил для сверхконсервативного дизайна объединить RIMEMD-160 и SHA-256. Либо оставить одну SHA-512 (использовать этот алгоритм на пару с другом — тяжёлый перебор). — SATtva
    • Возможно открытие атаки, при которой длина выхода значения иметь не будет. Время подсчёта хэш-значения (для любых хэш-функций) при маленьких объёмах информации минимально. На случай большого количества запросов в секунду (в чём я сомневаюсь), можно будет изменить набор функций, т.е. оставить только одну. — Serzh
  3. Что непосредственно представляет из себя заверяемая информация?
    • произвольная информация, которая (если изначально это не файл) компонуется в файл — Serzh
    • Мне кажется это должен быть произвольный файл. А как быть если пользователь захочет заверить уже готовый хеш – он записывает этот хеш в текстовый файл и заверяет уже этот файл?
    • да, а если клиенту заверенные данные ещё нужно отпарсить? зачем заставлять его делать лишние телодвижения при том, что необходимости в этом никакой нет? считаю, что в ascii armor паковаться должны только двоичные файлы. — SATtva

Получение метки времени по URL


?дея: Клиент передает url страницы сайта, что бы иметь возможность в последствии доказать что было размещено на данной странице.


Разработка данной возможности пока заморожена (по край ней мере для меня)



1Клиент — лицо или система, требующие точного заверенного времени для последующего аудита.


2Формат «метки времени» описан в соответствующем разделе.