Работа с HAMLOG.ONLINE

[UA1ATD]

Эта подпись позволяет однозначно идентифицировать отправителя. Она не говорит ни о содержимом документа, ни о его адресате.

Основная задача подписи - позволить верифицировать документ с помощью открытого ключа, который хранится на сервере.

[ER1CS]

не дает возможности исправить что то в документе, что нам и нужно.

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

- - - Добавлено - - -

Основная задача подписи - позволить верифицировать документ с помощью открытого ключа, который хранится на сервере.

Спасибо. Я более чем в курсе как работает алгоритм. Даже математику процесса знаю и ещё в вузе программы с таким функционалом писал. Подпись - это ведь всё равно асимметричное шифрование.

[UA1ATD]

Подпись это те же пары закрытый(личный)/открытый(публичный) ключей. Они неизменны. Если вам нужно отдавать кому либо личный ключ для того, чтобы он проверил и зачёл вам QSO на диплом - о какой секретности или надёжности может идти речь?

Петр, закрытый ключ никому не передают, а открытый передавать смысла нет т.к. данные и ключ будут из одного источника. Обычно идут по пути "доверенного источника" считая все его данные достоверными.

[ER1CS]

Обычно

Обычно идёт обмен между двумя лицами. В таком случае всё верно. Но у нас то предъявлять данные нужно третьему лицу, тут принцип доверенного источника как бы не очень подходит. Но может я и ошибаюсь, если например инвертировать процесс, чтобы кодировать личным ключом - дабы все смогли раскодировать публичным, это однозначно определит авторство отправителя. Но это нужно поднимать всю связанную математику и смотреть как там с надёжностью по генерации второй пары ключа из открытого, если приспичит реализовывать.
Соглашусь - вариант возможен.

[UA1ATD]

. Но у нас то предъявлять данные нужно третьему лицу, тут принцип доверенного источника как бы не очень подходит.

IMHO при загрузке на сервер радиолюбитель закрытым ключем подписывает целиком ADIF файл, а не каждую строку QSO в отдельности. Третье лицо передает на сервер список связей для сравнения, а в ответ получает этот же список, но только совпадающие связи.

[RJ6N]

Политика всех нормальных держателей логов такова,что вносить изменения,закачивать логи,синхронизировать может только хозяин позывного. Программа только сравнивает данные связи и ставит CFM при совпадении. Завязано с кучей требований юридического характера и прочих прибамбасов. Как уже говорили-нормальными сервисами являются LOTW и HAMLOG... Все остальные-от лукавого.

Только изменять данные QSO в Lotw не получиться никак, а вот в HamLog без проблем.

[RQ3P]

Только изменять данные QSO в Lotw не получиться никак, а вот в HamLog без проблем.

Вы можете изменит только свои данные.И в LOTW тоже. Загрузите еще раз журнал с измененными данными и готово. Изменить в HAMLOGе данные на основе неподтвержденных? Попробуйте. Нажмите на QSL-там нет данных по времени. Они появятся только при подтверждении.

[ER1CS]

при загрузке на сервер

Тут разговор не об этом варианте. А о предложении хранить некую гарантированно защищённую eqsl у себя и отправлять её проверяющему без заливки куда либо со стороны отправителя.

[RA3QH]

Только изменять данные QSO в Lotw не получиться никак, а вот в HamLog без проблем.

а зачем менять? подгонять под время? нет уж..."умерло-значит умерло...." а все "подгонки" это как то нехорошо пахнет....

[UA1ATD]

Тут разговор не об этом варианте. А о предложении хранить некую гарантированно защищённую eqsl у себя и отправлять её проверяющему без заливки куда либо со стороны отправителя.

Самодостаточной такая подписанная EQSL не будет. Проверяющему необходим открытый ключ подписи. Как вариант - использовать логику удостоверяющего центра, который подписывает каждое QSO своим закрытым ключем и предоставляет онлайн сервис по верификации.

[RW3RQ]

Вы можете изменит только свои данные.И в LOTW тоже. Загрузите еще раз журнал с измененными данными и готово.

Ну измени свои данные о вот этой связи так, чтобы подтверждение слетело:

Details 	RW3RQ 	RW3PF 	2007-02-10 18:24:00 	80M 	RTTY 		EUROPEAN RUSSIA

Все тебе спасибо скажут, и UA4WHX в лотв вернётся.

[RQ3P]

Ну измени свои данные о вот этой связи так, чтобы подтверждение слетело:

Подтверждение не слетит. Но если изначально было неправильное время или другие данные QSO,то можно набить его раз и еще раз залить. И оно подтвердиться...
У вас какие-то проблемы с пониманием прочитанного...

[RW3RQ]

У вас какие-то проблемы с пониманием прочитанного...

У кого с пониманием, у кого с написанием.

Подтверждение не слетит. можно набить его раз и еще раз залить.

Это называется не "изменить", а "добавить ещё одно qso с исправленными данными". Поток сознания надо регулировать.

[UA9CTT]

Добрый день Всем!

На сайте не работает выгрузка лога в формате ADIF, подскажите это у всех такая проблема? или только у меня и в чем может быть причина.

[UA1ACQ]

Коллеги как вылечить хамлог вход по паролю
1 Я использую хамлог с двумя позывными личным и коллективным
2 Оба зарегистрированы, есть пароли
3 Долго работал только с коллективным позывным. Личный кабинет на коллективный позывной Намлога открывался автоматически или по паролю.
4 При попытке открыть кабинет на свой позывной пишет пароль неверный. Меняю пароль через запрос - пароль принят, вход с новым паролем опять неверный пароль!
До этого была подобная ситуация, но обратная - перейти с коллективного позывного на личный. Тогда обратился за помощью в чат намлога к модератору. Он поколдовал и я смог работать с кабинетом коллективки.
Сейчас зайти в чат намлога не могу. Тупик. Как поступить?