id: Гость   вход   регистрация
текущее время 01:26 29/03/2024
Владелец: Alex_B (создано 15/04/2008 08:02), редакция от 11/05/2008 03:50 (автор: serzh) Печать
Категории: софт, gnupg, openpgp, инфобезопасность, право, политика, безопасная разработка, стандарты, разное
https://www.pgpru.com/Новости/2008/ЗапущенСервисМетокВремениTimeMARKERorg
создать
просмотр
редакции
ссылки

15.04 // Запущен «Сервис меток времени» timeMARKER.org


«Сервис меток времени» является, по сути, электронным нотариусом. Клиент передает сервису информацию, сервис проставляет свой штамп времени и заверяет полученный результат с помощью ЭЦП.


Более подробную информацию о «Сервисе меток времени» можно получить здесь.


Адрес проекта: http://timeMarker.org/
Русская версия: http://timeMarker.org/ru.aspx


30.04.2008 – начало эксплуатации сервиса.


Очень надеюсь на помощь участников «openPGP в России» в тестировании.
Буду благодарен любым замечаниям и предложениям, как по функционированию, так и по дизайну, удобству использования.


Больше спасибо всем участникам за помощь, без Вас данный сервис (как и мой диплом) не мог бы быть реализован.


p.s. О том кто разработал формат «меток времени» и всю теоретическую часть (т.е. о всех Вас/нас) на timeMARKER.org будет оговорено отдельно.


Источник: http://timeMarker.org/


 
На страницу: 1, 2, 3, 4, 5, 6, 7 След.
Комментарии [скрыть комментарии/форму]
— Гость (21/04/2008 21:07)   <#>
Этот кто-то аннулирует задним числом ключ, на котором была выдана ЭЦП. Всё – доказать аутентичность подписи невозможно.

Не верно. Будет видно, что данные были подписаны ключом, который впоследствии отозвали по каким-либо причинам – не более того.
— SATtva (21/04/2008 21:26)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Этот кто-то аннулирует задним числом ключ, на котором была выдана ЭЦП. Всё – доказать аутентичность подписи невозможно.

Не верно. Будет видно, что данные были подписаны ключом, который впоследствии отозвали по каким-либо причинам – не более того.

Видите разницу между подчёркнутыми фрагментами?

Предположим, что 1 апреля Вы высказали какую-нибудь глупость и заверили её своим ключом. Желая впоследствии отказаться от своих слов, Вы переводите часы на 25 марта, аннулируете свой ключ и заявляете, что сообщение от 1 апреля было опубликовано злоумышленником, желающим дискредитировать Вас. Как здесь установить истину?

Свойство "неотречения" цифровых подписей — это миф. (Есть исключения, но обеспечиваемые в обычном гражданско-правовом процессе.)
— Гость (21/04/2008 22:52)   <#>
Свойство "неотречения" цифровых подписей — это миф.

Хм.. оригинально :) Не перестаю открывать для себя новое в казалось бы простейшей схеме асимметрики. В общем-то, я бы переформулировал вашу мысль так: да, я могу сотворить сертификат отзыва своего ключа задним числом и сослаться на то, что "подпись от 1го апреля сделана злоумышленником укравшим мой ключ", только вот.. а поверят ли? :) А то могут сказать что "в попытках освободиться от ответственности за своё высказывание отозвал ключ задним числом". Во всяком случае, "неопределённость". Если же рассуждать более общо, то можно сказать, что "ключ был украден в первые 5 минут после его генерации", и "я им сам никогда ничего не подписывал" (то был злоумышленник или троян на моём компе и т.п.). Как уже выше заметил Гость, на этот случай есь меры другого характера: логи самого компьютера, логи [вырезано цензурой], и логи ещё много чего.
— SATtva (21/04/2008 23:14)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Главная мера противодействия заложена в OpenPGP — это Сеть доверия. По крайней мере если Вы постоянно собираете на сертификате ключа чужие подписи, то откатить его слишком далеко назад становится значительно труднее, доверие к ключу укрепляется. А если подписей никаких на ключе нет, то и к особому доверию (ни к позитивному, ни к негативному) он не располагает.
— Гость (21/04/2008 23:30)   <#>
Главная мера противодействия заложена в OpenPGP — это Сеть доверия.

Да, это хорошая штука, но она противоречит идее об анонимности.
— SATtva (21/04/2008 23:36)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
OpenPGP не имеет ничего общего с анонимностью, он решает задачи целостности и конфиденциальности. И вообще мы уходим в офф-топик.
— Alex_B (22/04/2008 10:38)   профиль/связь   <#>
комментариев: 143   документов: 31   редакций: 143
Не очень понятно, при чём тут сайты государственных органов. Кроме того, без привязки к URL не будет доказательства опубликованности.
Верно, исправил.
— SATtva (23/04/2008 18:46)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Хотелось бы прояснить один вопрос по цепочкам меток. Для примера возьмём метки №15 и №16. Поле Hash-RIPEMD160 у метки 15 имеет значение b5b940d16942aee034a13dc07601b2678b061f10. Если я ничего не путаю, то поле Ref-Hash-RIPEMD160 у метки 16 тоже должно быть b5b940d16942aee034a13dc07601b2678b061f10 (что и обеспечивает последовательное связывание), однако Ref-Hash-RIPEMD160 метки 16 равно a90afdad9d7ebdf09f7a05f2fa0f279c9dedee90. Откуда взялось такое значение? (Те же непонятки относятся и к полям SHA512.)
— Alex_B (24/04/2008 08:59, исправлен 24/04/2008 09:01)   профиль/связь   <#>
комментариев: 143   документов: 31   редакций: 143
Поле Hash-RIPEMD160 у метки 15 имеет значение b5b940d16942aee034a13dc07601b2678b061f10. Если я ничего не путаю, то поле Ref-Hash-RIPEMD160 у метки 16 тоже должно быть b5b940d16942aee034a13dc07601b2678b061f10

Не совсем так.

Поле Hash-RIPEMD160 (как и Hash-SHA512) служит для связывания пользовательских данных и данной метки — это поле содержит хеш введенных пользователем значений.

Поле Ref-Hash-RIPEMD160 служит для связи меток между собой, и вычисляется на основе предыдущей метки времени следующим образом:
нужно взять хеш значение от всех метаданных, всего что находится между



Насколько я понял, к такой схеме пришли при обсуждении формата.
— SATtva (24/04/2008 11:37)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Поле Ref-Hash-RIPEMD160 служит для связи меток между собой, и вычисляется на основе предыдущей метки времени следующим образом:
нужно взять хеш значение от всех метаданных, всего что находится между ...

Неверно. Поскольку в "нотариальном журнале" присутствуют только метаданные меток, но не пользовательские данные, исчезает возможность контроля правильности связки. Собственно, и самого связывания меток не происходит — без пользовательских данных каждой метки в цепочке невозможно определить правильность полей Ref-Hash.

Я выше глупость сказал, что Ref-Hash метки n должен быть равен полю Hash метки n-1. Нет: Ref-Hash метки n должен вычисляться на основе только метаданных метки n-1. В этом случае обеспечивается как связывание меток, так и свободный контроль за журналом. Здесь поле Hash привязывает метаданные к пользовательским данным, а Ref-Hash связывает метки между собой.
— Alex_B (24/04/2008 11:53)   профиль/связь   <#>
комментариев: 143   документов: 31   редакций: 143
Ref-Hash метки n должен вычисляться на основе только метаданных метки n-1...
десь поле Hash привязывает метаданные к пользовательским данным, а Ref-Hash связывает метки между собой.
Так ведь так и сделано.
— SATtva (24/04/2008 12:17)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Хм, тогда прошу извинить. Проблема в том, что у меня хэши, вычисленные с меток n-1, не совпадают со значениями в полях Ref-Hash меток n. Хотел бы тогда уточнить формат шаблона, с которого вычисляется хэш.
  1. Поля и значения в шаблоне разделяются пробелами или табами?
  2. Символы переноса строк в шаблоне — LF или CRLF?
  3. Ниже Hash-RIPEMD160 есть ещё одна пустая строка?
— Alex_B (24/04/2008 13:01, исправлен 24/04/2008 13:04)   профиль/связь   <#>
комментариев: 143   документов: 31   редакций: 143
Формат шаблона, с которого вычисляется хэш такойже как и у метки времени публикуемой на сервисе.

На сгрине все видно. Переносы в стиле виндоус.. Наверно в этом все дело..

Как же быть??
— SATtva (24/04/2008 13:22)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Ошибка найдена. Алекс, добавьте в контекст хэширования пустую строку после шаблона и уберите строку "Hash: SHA1", которая не является метаданными метки и не представляет ценности (она имеет место только для обратной совместимости с ранними реализациями OpenPGP). Хэшироваться для полей Ref-Hash данные должны в том виде, в каком они отображаются после сличения подписи, вот так:

— Alex_B (24/04/2008 16:08)   профиль/связь   <#>
комментариев: 143   документов: 31   редакций: 143
SATtva, изменил контекст хеширования. проверьте пожалуйста.

Стоит учесть что старые метки считались старым образом, придутся сделать парочку новых и посмотреть их.

Потом, когда наконец-то будет работать без нареканий базу данных почищу. Сервис работает в тестовом режиме, без указания url и на тестовых ключах — удаление не должно никому навредить.
На страницу: 1, 2, 3, 4, 5, 6, 7 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3