On Wed, 14 Mar 2018 04:12:01 -0700 (PDT), M.M. wrote:

>>> Jeśli jest ryzyko że ktoś wyciągnie dane dające się zdekodować z
>>> urządzenia, to w urządzeniu powinny być przechowywane tylko funkcje
>>> skrótu - tak jest np. w logowaniu do linuxa. Dlaczego nie możesz
>>> zastosować takiego rozwiązania?
>>
>> Bo te dane nie są stałe.
> Ja już tego nie rozumiem. Co ma stałość lub nie stałość danych wspólnego z
> szyfrowanym protokołem którym są przesyłane?
>
>> Chcę żeby były generowane w oparciu o datę i SN,
> Ja myślałem, że chcesz bezpieczeństwa.
>
>> bo nie chcę, żeby ten klucz działał w nieskończoność i na
>> każdym urządzeniu.
> W ramach podstawowego standardu bezpieczeństwa jest zmiana
> hasła i inne hasło do każdego urządzenia.

I co dwa dni zmieniać i dystrybuować nowe hasło?

Nie wiem czemu robię to za Adama, ale jeszcze raz:

Wyobraź sobie parking, przed wjazdem szlaban na kod. Jutro zaczynamy
konferencję dwudniową, na parkingu zaroi się od gości z całego kraju. Ale
żeby mogli zaparkować muszą wpisać na czytniku 8 znakowy kod. Trzeba im
więc go wygenerować i wysłać dzisiaj mailem. Ale kod nie może być stały, bo
za 5 dni jest inny zjazd i inna grupa przyjedzie, im też trzeba będzie dać
kody ważne dwa dni.
Zatem potrzebny jest sposob by zarówno generowanie kodu do maila, jak i
dekodowanie w czytniku przy szlabanie było zgodne i wiedziało, że ten kod
jest ważny dziś i wczoraj.

--
pozdrawiam
Roman Tyczka