Это старая редакция страницы Черновики / Статьи / Сервисметоквремени / Принципработы за 29/12/2007 12:50.
Принцип работы
Принцип функционирования сервиса находится на стадии разработки. Комментарии, предложения, поправки крайне приветствуются.
Получение метки времени
Для получения метки времени, клиент1:
- Посредством web-интерфейса или программы, отправляет сервису данные, подлежащие заверению.
- Сервис формирует «метку времени»2, содержащую данные согласно формату.
Ref-Hash-X = Hash-X (предыдущая метка времени)
- Сервис публикует созданную «метку времени».
- Сервис отправляет клиенту «метку времени» (возможен произвольный формат), подписанную прозрачной подписью.
Вопрос:
- Как клиент узнает открытый ключ сервиса?
- на странице сервиса — Serzh
- Откуда у пользователя уверенность, что ему не посунули подделку? Нужно как-то протащить ключ в сеть доверия, что бы каждый мог проверить. — Alex_B
- Оператор подписывает ключ службы своим персональным ключом, который связывается с сетью доверия всеми обычными способами. Или, если сайт службы работает по SSL, положиться на защищённость канала. А ещё лучше объединить оба способа. В общем, я здесь не вижу существенной проблемы. — SATtva
- Почему следует использовать SHA512?
- используется несколько независимых хэш-функций — Serzh
- вообще-то это не ответ на поставленный вопрос. ;-) на мой взгляд, использование RIPEMD-160 при наличии SHA-512 избыточно. можете привести хоть одну причину в её необходимости? — SATtva
- Это требуется для долговременных меток (на несколько лет). Спустя несколько лет мы получим такую ситуацию: SHA512 – взломан, RIPEMD-160 – нет (или наоборот). Если мы использовали только адну хэш-функцию (взломаную), то доказать авторство на основе данной метки уже невозможно. Если одна функция ещё держится – то возможно. Поэтому необходимо добавлять все возможные принятые криптографическим сообществом хэш-функции. — Serzh
- Да нет, это я прекрасно понимаю. Только сама по себе длина выхода SHA-512 такова, что даже при успешных атаках, снижающих теоретическую стойкость алгоритма, практически, на мой взгляд, он едва ли когда-нибудь станет уязвим. Учитывая скорость SHA-512, я бы предложил для сверхконсервативного дизайна объединить RIMEMD-160 и SHA-256. Либо оставить одну SHA-512 (использовать этот алгоритм на пару с другом — тяжёлый перебор). — SATtva
- Что непосредственно представляет из себя заверяемая информация?
- произвольная информация, которая (если изначально это не файл) компонуется в файл — Serzh
- Мне кажется это должен быть произвольный файл. А как быть если пользователь захочет заверить уже готовый хеш – он записывает этот хеш в текстовый файл и заверяет уже этот файл?
- да, а если клиенту заверенные данные ещё нужно отпарсить? зачем заставлять его делать лишние телодвижения при том, что необходимости в этом никакой нет? считаю, что в ascii armor паковаться должны только двоичные файлы. — SATtva
Получение метки времени по URL
Идея: Клиент передает url страницы сайта, что бы иметь возможность в последствии доказать что было размещено на данной странице.
Разработка данной возможности пока заморожена (по край ней мере для меня)
1Клиент — лицо или система, требующие точного заверенного времени для последующего аудита.
2Формат «метки времени» описан в соответствующем разделе.