openPGP в России / черноВики / Статьи / Сервис меток времени / Принцип работы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

!!(grey)есть ли еще какие-нибудь ((https://www.pgpru.com/chernowiki/statji/servismetokvremeni задачи)), которые мог бы решать данный сервис?!!

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

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

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

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

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

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

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

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

++((#2))Формат «метки времени» описан в соответствующем ((ФорматМеткиВремени разделе)).++

>>>{{Authors license="CC-BY-SA" cluster=0}}>>>

Ваше имя:
	Запомнить псевдоним (сохранить в cookie)
	OpenPGP-подписанный текст в кодировке Помощь
	Сохранить параметры OpenPGP в cookie

Для корректной работы разрешите в своем браузере показ изображений.

Пожалуйста, напишите, кого/что вы видите
на изображенной слева картинке. Если
там несколько персонажей/предметов,
перечислите их в именительном падеже
через пробел (одинаковых приводите во
множественном числе).

(осталось попыток на решение теста: 3)

Поддержка BBCode включена