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

А вообще с почином!

С ходу заметил, что ключи службы отображают десятеричные ID, один имеет даже отрицательное значение.

Исправил.

Просмотр "нотариального журнала", как я понял, тоже пока не реализован.

Да.. Так и не придумал как лучше это реализовать. Делать такое же представление как и ключи не подходит — что бы проверить цепочку не по одной же метке загружать.

Как вы себе представляете выдачу цепочки меток времени?

А вообще с почином!

Спасибо!

Исправил.

Для порядку стоит ещё '0x' перед номером добавить.

Как вы себе представляете выдачу цепочки меток времени?

Самое простое — предоставить пользователю возможность ввести номера или даты двух меток, с которой и по которую нужно показать промежуточные звенья (формат выдачи: минимум — простой текст, но лучше — возможность выбора между простым текстом и набором индивидуальных файлов в zip-архиве). При этом пользователь должен иметь возможность ввести только один номер/дату — тогда ему выдаются все звенья с указанного и до самого последнего. В идеале система могла бы формировать для выданных звеньев простой скрипт, который пользователь может выполнить локально для автоматического сличения подписей со всех звеньев и проверки их связности по хэшам.

Сервис неплох. Но для реального использования надо дать возможность подписывать файлы. Из последнего: наша компания передает дела по управленческому учету (аутсорс) другому предприятию, пакеум в архив, заливаем на ваш сервис, он прикрепляет дату и подписывает своим ключом. Все это остается на сервисе. Мы уже не можем изменить файл, т.к. слетит время и хэш. Если потом возникают вопросы/претензии "кто-где накосячил по учету", то есть арбитр (ваш сервис), с подписанным архивом, где видны дата и подпись.

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

При обработке файлов наргрузка на сервис будет неоправдано большой.
P. S. Вы всегда раздаёте свою отчётность направо и налево? =)

Каспер, возьмите свой архив и обсчитайте его контрольную сумму любой удобоваримой хэш-функцией (например, при помощи GnuPG: gpg --print-md SHA512). Полученное хэш-значение передайте timeMarker'у на подпись. Результат будет идентичный.

Понимаю, но без этого сервис для нас бессмысленный. Бизнесу маленькие _сообщения_ не нужны. Нужны _файлы_, и большие.

PS у нас закончился договор обслуживания, и мы ее передаем эти документы другой фирме для ведения учета. вопрос стоит в том, что есть уверенность, что всех будущих "собак" повесят на нас. доверия между нами нет. есть задача зафиксировать базу данных, подписать ее и отдать арбитру (незаинтересованной стороне). для хранения у арбитра базу можно и зашифровать. ничего военного.

для хранения у арбитра базу можно и зашифровать

Он дата-центр или банковская ячейка что-ли? Нафиг ему хранить ваши файлы? Арбитр предоставляет криптографически стойкий механизм привязки метки времени к конкретным данным. Сохранность самих данных его волновать не должна, это ваши проблемы (Вас и контрагента): вы держите у себя копии данных, а в случае разногласий обращаетесь к свидетельству арбитра: у кого подпись сверяется корректно, тот и прав.

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

Поздравляю с началом работы сервиса!
очень полезную вещь вы затеяли!

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

http://www.itconsult.co.uk/stamper/stampinf.htm
http://signedtimestamp.org/

P. S. Да, проверил, на первом точно получал журнал подпсей – просто архив с детачед подписями на определенную дату.

Самое простое — предоставить пользователю возможность ввести номера или даты двух меток, с которой и по которую нужно показать промежуточные звенья (формат выдачи: минимум — простой текст, но лучше — возможность выбора между простым текстом и набором индивидуальных файлов в zip-архиве). При этом пользователь должен иметь возможность ввести только один номер/дату — тогда ему выдаются все звенья с указанного и до самого последнего.

Все метаданные меток и их подписи хранятся в БД. Когда нужно сформировать документ представляющий ту или иную метку (например, при выдаче новой метки необходимо сформировать предыдущую) из этой же БД берется шаблон формата, ассоциированный с данной меткой. Далее шаблон заполняется метаданным, потом формируется документ openPGP (ЭЦП вычислена заранее при создании метки).

Не составляет ни какого труда найти метки по времени, по номеру, найти ключ на котом они были выданы и т.п. Но формирование множества файлов (документов меток времени) на основе данных из БД и выдача их клиенту может вызвать затруднения. Что если пользователь запросит цепочку длинной в 1000 меток – не создавать же всю эту тысячу в виртуальной памяти. К-тому же архив может быть большим, а связь клиента плохой — тогда как он выкачает все эти файлы. Ведь докачки не получится, после каждого обрыва связи все по новой.

Можно хранить архивы по 10/20 меток на сервере и при запросе давать пользователю ссылки на те, которые ему нужны, но тогда это будет явно избыточно хранить метки и в БД и в виде файлов в архиве...
Хостинг предоставлен бесплатно одной хорошей (я думаю, что на первом/втором месте в России) хостинг компанией, и такими темпами быстро исчерпает свой лимит.

timeMarker разрабатывался с оглядкой на опыт Stamper'а. К сожалению, к настоящему времени он технически устарел — по-прежнему работает на базе второй версии PGP ключом v3 (с хэш-функцией MD5). А SignedTimestamp.org у меня большого доверия не вызывает именно из-за отсутствия средств аудита.

Alex_B, если пользователь запрашивает слишком длинную цепочку, её можно разбить на множество менее длинных (допустим, по 100 звеньев) и выдавать по отдельности. Для реализации в пользовательском интерфейсе могут быть разные варианты, например, вывести на страницу список ссылок, каждая из которых позволит скачать соответствующий сегмент от полной цепочки (т.е. изначальный запрос пользователя просто разбивается на ряд более мелких, которые будут исполняться по мере перехода пользователя по соответствующим ссылкам).

Ещё следует вспомнить, что мы обсуждали при разработке. Помимо индивидуальных метаданных на каждую метку система должна подбивать и сохранять аудиторские отчёты (содержащие минимум информации, возможно только покрытый подписью список порядковых номеров и хэшей меток) за каждый день, неделю, месяц (или, например, на каждые 100 и 10000 выданных меток), что при запросе пользователя позволит сильно сократить объём выдаваемой информации.

Вот ещё вариант, возможно спорный. Когда в системе накапливается очень большое число меток (пусть "большим" в данной дискуссии будет 10000, тогда как "очень большое" — это "большое * 1.5", но вообще эти цифры просто взяты с потолка, их можно и следует выбрать более взвешенно), она извлекает из базы 10000 наиболее старых, подбивает их в один архив, заверяет его подписью и сохраняет на диске, одновременно удаляя из БД. Теперь мы имеем 10000 старых меток, лежащих в архиве на диске, и ещё 5000 более новых в БД.

Теперь, если пользователю нужна цепочка меток в пределах 5000 новых, они выдаются ему обычным способом, как я описал в предыдущем сообщении. Если же цепочка получается настолько длинной, что затрагивает заархивированные старые метки, система выдаёт ему новые, как обычно, а также предлагает скачать старый архив по предложенной ссылке. Поскольку архив формируется однократно и размещается на диске сервера как обычный файл, его можно скачивать и докачивать, не создавая избыточную нагрузку на сервер. (А достать из архива нужные метки становится уже исключительно заботой пользователя.)

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

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

но сам аудиторский след сохраняется до сотворения мира.

Т.е. сервер был запущен кем-то ещё в момент сотворения мира и его до сих пор тестируют? :-)

гдето видел аналогичный сервис. там загружалась маленькая Java/ActiveX точно непомню программка которая сама считала хеши MD5, SHA-1, SHA-512 с любого файла. Тоесть появлялось стандартное окошко "выбрать файл". стоит сделать чтото аналогичное так как не очень удобно самому хеши считать!

Attention. Service work in test mode.!! Правильно WORKS!