id: Гость   вход   регистрация
текущее время 19:33 28/03/2024
Владелец: Alex_B редакция от 08/01/2008 23:51 (автор: Alex_B) Печать
Категории: инфобезопасность, политика, разное
создать
просмотр
редакции
ссылки

Это старая редакция страницы Черновики / Статьи / Сервисметоквремени / Принципработы за 08/01/2008 23:51.


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


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


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

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


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


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

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

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

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

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

Вопрос:

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

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


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


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


Проверка метки времени


Для доказательства факта обладания информацией в определенное время пользователь передает третьей стороне полученную от сервиса метку времени.


есть ли еще какие-нибудь задачи, которые мог бы решать данный сервис?


Для проверки подлинности представленной метки времени, заинтересованная сторона:

  1. проверяет ЭЦП сервиса
  2. запрашивает от сервиса цепочку меток времени, выданных ранее проверяемой до ближайшей «контрольной» метки.

Каждое заинтересованное лицо может сделать несколько «контрольных» меток времени и запомнить их. Потом достаточно проверить цепочку до такой сохраненной метки, а также совпадение сохраненной метки с меткой представленной сервисом.


Как человек не делавший «контрольных» меток сможет проверить подлинность, предоставленной ему метки времени?
-Иметь свою контрольную метку необязательно, т.к. другие люди, делая их (метки) будут тем самым контролировать сервис. — Serzh
-Первая метка — это название сервиса, и все об этом знают. Проверяющая сторона делает свою метку времени, которая естественно получается более поздней, чем проверяемая.
Затем нужно проследить цепочку от только что созданной метки до самой первой. Если цепочка цела – то проверяемая метка не подложная.Alex_B


Для ускорения проверки отдельной метки времени


В конце недели стампер должен ставить свою метку (+ получать метки от других аналогичных сервисов) и публиковать файл в котором находятся:

  1. хэши всех меток за неделю
  2. хэш аналогичного файла за предыдущую неделю

Если выданных подписей за неделю больше 100, то дополнительно создаём промежуточный файл (неделя-хх-1.txt, неделя-хх-2.txt, ...).


В конце года стампер должен ставить свою метку (+ получать метки от других аналогичных сервисов) и публиковать файл в котором находятся:

  1. хэши всех недельных файлов за год
  2. хэш аналогичного файла за предыдущий год

Для проверки нужной метки проходим (проверяем хэши) от последней выданной метки до первого "недельника", далее с шагом в неделю идём до первого "годовика" доходим до нужного года и начинаем сбавлять шаг сначала до недели, а потом и до отдельных меток.
идея Serzh



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


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