Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > pl.comp.programming > #31467 > unrolled thread

PKI a weryfikacja krótkiego podpisu (3 bajty)

Back to article view | Back to pl.comp.programming

Contents

  PKI a weryfikacja krótkiego podpisu (3 bajty) gof@somewhere.invalid (Adam Wysocki) - 2018-03-13 16:11 +0000
    Re: PKI a weryfikacja krótkiego podpisu (3 bajty) "M.M." <mmarszik@gmail.com> - 2018-03-13 11:39 -0700
      Re: PKI a weryfikacja krótkiego podpisu (3 bajty) Roman Tyczka <noemail@because.no> - 2018-03-13 19:50 +0100
        Re: PKI a weryfikacja krótkiego podpisu (3 bajty) "M.M." <mmarszik@gmail.com> - 2018-03-13 12:09 -0700
          Re: PKI a weryfikacja krótkiego podpisu (3 bajty) Roman Tyczka <noemail@because.no> - 2018-03-13 20:22 +0100
            Re: PKI a weryfikacja krótkiego podpisu (3 bajty) "M.M." <mmarszik@gmail.com> - 2018-03-14 04:19 -0700
              Re: PKI a weryfikacja krótkiego podpisu (3 bajty) gof@somewhere.invalid (Adam Wysocki) - 2018-03-14 12:03 +0000
      Re: PKI a weryfikacja krótkiego podpisu (3 bajty) gof@somewhere.invalid (Adam Wysocki) - 2018-03-14 08:40 +0000
        Re: PKI a weryfikacja krótkiego podpisu (3 bajty) "M.M." <mmarszik@gmail.com> - 2018-03-14 04:12 -0700
          Re: PKI a weryfikacja krótkiego podpisu (3 bajty) Roman Tyczka <noemail@because.no> - 2018-03-14 12:29 +0100
            Re: PKI a weryfikacja krótkiego podpisu (3 bajty) gof@somewhere.invalid (Adam Wysocki) - 2018-03-14 12:07 +0000
            Re: PKI a weryfikacja krótkiego podpisu (3 bajty) "M.M." <mmarszik@gmail.com> - 2018-03-14 06:47 -0700
              Re: PKI a weryfikacja krótkiego podpisu (3 bajty) gof@somewhere.invalid (Adam Wysocki) - 2018-03-14 20:07 +0000
                Re: PKI a weryfikacja krótkiego podpisu (3 bajty) "M.M." <mmarszik@gmail.com> - 2018-03-14 14:27 -0700
            Re: PKI a weryfikacja krótkiego podpisu (3 bajty) Adam M <amorawski@magna-power.com> - 2018-03-14 06:53 -0700
          Re: PKI a weryfikacja krótkiego podpisu (3 bajty) gof@somewhere.invalid (Adam Wysocki) - 2018-03-14 11:38 +0000
    Re: PKI a weryfikacja krótkiego podpisu (3 bajty) Roman Tyczka <noemail@because.no> - 2018-03-14 10:52 +0100
      Re: PKI a weryfikacja krótkiego podpisu (3 bajty) gof@somewhere.invalid (Adam Wysocki) - 2018-03-14 11:45 +0000

#31467 — PKI a weryfikacja krótkiego podpisu (3 bajty)

Cześć,

Może Wy mnie naprowadzicie.

Potrzebuję w określonej sytuacji wygenerować użytkownikowi 8-cyfrowy kod 
(ostatecznie cyfr może być więcej, ale raczej nie więcej niż 10), który 
zostanie zweryfikowany przez urządzenie i zostanie wykonana określona 
akcja. Ten kod musi być przeznaczony tylko dla tego urządzenia i ważny 
tylko przez określony czas (założyłem, że dwa dni wystarczą; użytkownik 
nie ma możliwości manipulacji datą na urządzeniu).

Wymyśliłem, żeby podczas generacji złożyć do kupy nr seryjny urządzenia, 
aktualną datę, dorzucić do tego sekretny klucz, zrobić skrót SHA-256, 
wziąć pierwsze cztery bajty, zamienić je do postaci dziesiętnej i 
ewentualnie obciąć lub dopełnić zerami. Urządzenie podczas weryfikacji 
zrobiłoby to samo (a jak weryfikacja się nie uda, to dla daty dnia 
poprzedniego).

Problem jest tylko taki, że sekretny klucz musi być również na urządzeniu, 
czyli potencjalnie do wyciągnięcia z urządzenia lub np. z plików update'u 
(zaszycie go gdzieś mi się nie podoba, bo on nadal tam będzie). Chciałbym, 
żeby go nie było.

Pierwsze, o czym pomyślałem, to użycie kryptografii asymetrycznej i 
wrzucanie na urządzenia kluczy publicznych, a do generacji używanie klucza 
prywatnego. Wtedy podpisywałbym wspomniane dane tym kluczem (wtedy już bez 
sekretnego klucza symetrycznego), a urządzenie mogłoby sobie ten podpis 
zweryfikować.

Tylko czy jest jakiś sposób, żeby przesłać sygnaturę w postaci niecałych 
czterech bajtów (8 cyfr 0-9), ewentualnie całych (jak zwiększę liczbę cyfr 
do 10)? Przecież urządzenie jej nie wygeneruje i nie obetnie sobie, żeby 
ręcznie porównać zgodność, tak jak w przypadku wspomnianego wcześniej 
skrótu.

Macie jakiś pomysł, jak to inaczej zrealizować, żeby klucz, który może 
zostać użyty do generacji nowych kodów, nie znajdował się na urządzeniu?

To nie jest bardzo krytyczne i jeśli nie uda się znaleźć rozwiązania, to 
zostanę przy tym pierwszym. Po prostu chciałbym to zrobić dobrze i zgodnie 
ze sztuką.

Pozdr.

-- 
[ Email: a@b a=grp b=chmurka.net ]
[ Web:   http://www.chmurka.net/ ]

[toc] | [next] | [standalone]

#31468

On Tuesday, March 13, 2018 at 5:11:54 PM UTC+1, Adam Wysocki wrote:
> Cześć,
> 
> Może Wy mnie naprowadzicie.
> 
> Potrzebuję w określonej sytuacji wygenerować użytkownikowi 8-cyfrowy kod 
> (ostatecznie cyfr może być więcej, ale raczej nie więcej niż 10), który 
> zostanie zweryfikowany przez urządzenie i zostanie wykonana określona 
> akcja. Ten kod musi być przeznaczony tylko dla tego urządzenia i ważny 
> tylko przez określony czas (założyłem, że dwa dni wystarczą; użytkownik 
> nie ma możliwości manipulacji datą na urządzeniu).
> 
> Wymyśliłem, żeby podczas generacji złożyć do kupy nr seryjny urządzenia, 
> aktualną datę, dorzucić do tego sekretny klucz, zrobić skrót SHA-256, 
> wziąć pierwsze cztery bajty, zamienić je do postaci dziesiętnej i 
> ewentualnie obciąć lub dopełnić zerami. Urządzenie podczas weryfikacji 
> zrobiłoby to samo (a jak weryfikacja się nie uda, to dla daty dnia 
> poprzedniego).
> 
> Problem jest tylko taki, że sekretny klucz musi być również na urządzeniu, 
> czyli potencjalnie do wyciągnięcia z urządzenia lub np. z plików update'u 
> (zaszycie go gdzieś mi się nie podoba, bo on nadal tam będzie). Chciałbym, 
> żeby go nie było.
> 
> Pierwsze, o czym pomyślałem, to użycie kryptografii asymetrycznej i 
> wrzucanie na urządzenia kluczy publicznych, a do generacji używanie klucza 
> prywatnego. Wtedy podpisywałbym wspomniane dane tym kluczem (wtedy już bez 
> sekretnego klucza symetrycznego), a urządzenie mogłoby sobie ten podpis 
> zweryfikować.
> 
> Tylko czy jest jakiś sposób, żeby przesłać sygnaturę w postaci niecałych 
> czterech bajtów (8 cyfr 0-9), ewentualnie całych (jak zwiększę liczbę cyfr 
> do 10)? Przecież urządzenie jej nie wygeneruje i nie obetnie sobie, żeby 
> ręcznie porównać zgodność, tak jak w przypadku wspomnianego wcześniej 
> skrótu.
> 
> Macie jakiś pomysł, jak to inaczej zrealizować, żeby klucz, który może 
> zostać użyty do generacji nowych kodów, nie znajdował się na urządzeniu?
> 
> To nie jest bardzo krytyczne i jeśli nie uda się znaleźć rozwiązania, to 
> zostanę przy tym pierwszym. Po prostu chciałbym to zrobić dobrze i zgodnie 
> ze sztuką.

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?

Pozdrawiam

[toc] | [prev] | [next] | [standalone]

#31469

On Tue, 13 Mar 2018 11:39:22 -0700 (PDT), M.M. wrote:

>> Macie jakiś pomysł, jak to inaczej zrealizować, żeby klucz, który może 
>> zostać użyty do generacji nowych kodów, nie znajdował się na urządzeniu?
>> 
>> To nie jest bardzo krytyczne i jeśli nie uda się znaleźć rozwiązania, to 
>> zostanę przy tym pierwszym. Po prostu chciałbym to zrobić dobrze i zgodnie 
>> ze sztuką.
> 
> 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 ta informacja ma być składnikiem danych do funkcji skrótu.

-- 
pozdrawiam
Roman Tyczka

[toc] | [prev] | [next] | [standalone]

#31471

On Tuesday, March 13, 2018 at 7:50:28 PM UTC+1, Roman Tyczka wrote:
> On Tue, 13 Mar 2018 11:39:22 -0700 (PDT), M.M. wrote:
> 
> >> Macie jakiś pomysł, jak to inaczej zrealizować, żeby klucz, który może 
> >> zostać użyty do generacji nowych kodów, nie znajdował się na urządzeniu?
> >> 
> >> To nie jest bardzo krytyczne i jeśli nie uda się znaleźć rozwiązania, to 
> >> zostanę przy tym pierwszym. Po prostu chciałbym to zrobić dobrze i zgodnie 
> >> ze sztuką.
> > 
> > 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 ta informacja ma być składnikiem danych do funkcji skrótu.

Generalnie pytam, dlaczego nie można zastosować standardowych rozwiązań?

Do szyfrowania haseł w trakcie autoryzacji używamy - funkcji skrótu. Do
transmisji - protokołu szyfrowanego. Dane przechowujemy - zaszyfrowane.

Pozdrawiam

[toc] | [prev] | [next] | [standalone]

#31472

On Tue, 13 Mar 2018 12:09:35 -0700 (PDT), M.M. wrote:

> On Tuesday, March 13, 2018 at 7:50:28 PM UTC+1, Roman Tyczka wrote:
>> On Tue, 13 Mar 2018 11:39:22 -0700 (PDT), M.M. wrote:
>> 
>>>> Macie jakiś pomysł, jak to inaczej zrealizować, żeby klucz, który może 
>>>> zostać użyty do generacji nowych kodów, nie znajdował się na urządzeniu?
>>>> 
>>>> To nie jest bardzo krytyczne i jeśli nie uda się znaleźć rozwiązania, to 
>>>> zostanę przy tym pierwszym. Po prostu chciałbym to zrobić dobrze i zgodnie 
>>>> ze sztuką.
>>> 
>>> 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 ta informacja ma być składnikiem danych do funkcji skrótu.
> 
> Generalnie pytam, dlaczego nie można zastosować standardowych rozwiązań?
> 
> Do szyfrowania haseł w trakcie autoryzacji używamy - funkcji skrótu. Do
> transmisji - protokołu szyfrowanego. Dane przechowujemy - zaszyfrowane.

Nie wczytałeś się w opis problemu.
Adam ma dwa, niezależne "komputery". Nie ma między nimi łączności. I teraz
pierwszy musi w tych okolicznościach wygenerować jakiś klucz, a drugi musi
umieć go zweryfikować. Do tego dochodzi czas życia klucza.
Wymyślił, że na pierwszym "komputerze" doda do kupy datę, identyfikator
drugiego "kompa" i sól (sekretny klucz), potem obliczy z tego hasza, a na
drugim w czasie weryfikacji zrobi to samo i porówna wynik.

-- 
pozdrawiam
Roman Tyczka

[toc] | [prev] | [next] | [standalone]

#31476

On Tuesday, March 13, 2018 at 8:22:29 PM UTC+1, Roman Tyczka wrote:
> On Tue, 13 Mar 2018 12:09:35 -0700 (PDT), M.M. wrote:
> 
> > On Tuesday, March 13, 2018 at 7:50:28 PM UTC+1, Roman Tyczka wrote:
> >> On Tue, 13 Mar 2018 11:39:22 -0700 (PDT), M.M. wrote:
> >> 
> >>>> Macie jakiś pomysł, jak to inaczej zrealizować, żeby klucz, który może 
> >>>> zostać użyty do generacji nowych kodów, nie znajdował się na urządzeniu?
> >>>> 
> >>>> To nie jest bardzo krytyczne i jeśli nie uda się znaleźć rozwiązania, to 
> >>>> zostanę przy tym pierwszym. Po prostu chciałbym to zrobić dobrze i zgodnie 
> >>>> ze sztuką.
> >>> 
> >>> 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 ta informacja ma być składnikiem danych do funkcji skrótu.
> > 
> > Generalnie pytam, dlaczego nie można zastosować standardowych rozwiązań?
> > 
> > Do szyfrowania haseł w trakcie autoryzacji używamy - funkcji skrótu. Do
> > transmisji - protokołu szyfrowanego. Dane przechowujemy - zaszyfrowane.
> 
> Nie wczytałeś się w opis problemu.
> Adam ma dwa, niezależne "komputery". Nie ma między nimi łączności. 
Tego opisu nie da się zrozumieć. Jak ma zweryfikować, jeśli nie ma 
łączności? Jeśli przenosisz na dyskietce to przecież to też jest
bardzo typowy rodzaj łączności/transmisji - i jak najbardziej 
standardowego szyfrowania można użyć do przenoszenia danych na
dyskietce.


> I teraz
> pierwszy musi w tych okolicznościach wygenerować jakiś klucz, a drugi musi
> umieć go zweryfikować. 
Proszę bardzo, na pierwszym komputerze program wygenerowało liczbę jeden, 
na drugim sprawdza czy to faktycznie jest jedynka. Oczywiście transmisja
musi być aby to zweryfikować, a jak ktoś sobie życzy, to i może być
transmisja szyfrowana.


> Do tego dochodzi czas życia klucza.
> Wymyślił, że na pierwszym "komputerze" doda do kupy datę, identyfikator
> drugiego "kompa" i sól (sekretny klucz), potem obliczy z tego hasza, a na
> drugim w czasie weryfikacji zrobi to samo i porówna wynik.
No ale po co, czy pytając grzecznie, w jakim celu?


Pozdrawiam.

[toc] | [prev] | [next] | [standalone]

#31480

M.M. <mmarszik@gmail.com> wrote:

>> Nie wczytałeś się w opis problemu.
>> Adam ma dwa, niezależne "komputery". Nie ma między nimi łączności. 
> Tego opisu nie da się zrozumieć. Jak ma zweryfikować, jeśli nie ma 
> łączności?

Tak samo jak np. PGP weryfikuje otrzymany podpis. Tu jedyną łącznością 
będzie wpisanie na klawiaturze numerycznej otrzymanego telefonicznie kodu.

> Jeśli przenosisz na dyskietce to przecież to też jest
> bardzo typowy rodzaj łączności/transmisji - i jak najbardziej 
> standardowego szyfrowania można użyć do przenoszenia danych na
> dyskietce.

Tak, tylko na dyskietce przechowasz cały podpis.

Normalny scenariusz podpisu to:

1. Generuję skrót z jakichś danych
2. Szyfruję go kluczem prywatnym
3. Przesyłam go do urządzenia
4. Urządzenie deszyfruje go kluczem publicznym
5. Urządzenie generuje skrót z tych samych danych (które zna)
6. Urządzenie porównuje wygenerowany skrót i zdeszyfrowany

W punkcie 3 muszę przesłać cały zaszyfrowany blok (nawet jak nie 
zaszyfruję całego skrótu, a jedynie kilka jego bajtów, to i tak dostanę 
cały blok). Nie mogę przesłać tylko części bloku, bo nie uda się go 
zdeszyfrować.

Algorytmy szyfrujące, które znam, a które operują na łańcuchach a nie 
blokach, są jedynie symetryczne, a to nie różni się niczym od tego, co 
już wymyśliłem...

> Proszę bardzo, na pierwszym komputerze program wygenerowało liczbę jeden, 
> na drugim sprawdza czy to faktycznie jest jedynka. Oczywiście transmisja
> musi być aby to zweryfikować, a jak ktoś sobie życzy, to i może być
> transmisja szyfrowana.

Program wygenerował liczbę 1, ale użytkownik też może sobie ją wydedukować 
i potem wygenerować. Ja nie potrzebuję przesłać tej jedynki, bo urządzenie 
zna dane, które będą podpisane. Potrzebuję przesłać sam podpis, żeby 
urządzenie wiedziało, że został złożony przez właściwą podpisywaczkę.

>> Wymyślił, że na pierwszym "komputerze" doda do kupy datę, identyfikator 
>> drugiego "kompa" i sól (sekretny klucz), potem obliczy z tego hasza, a 
>> na drugim w czasie weryfikacji zrobi to samo i porówna wynik.
> No ale po co, czy pytając grzecznie, w jakim celu?

Po to, żeby:

1. Użytkownik nie mógł wykorzystać tego klucza na innym urządzeniu niż to, 
które należy do niego (może mieć dostęp do innych, które nie należą do 
niego, i móc wykonywać na nich funkcje, do których hasło nie jest 
potrzebne)

2. Użytkownik posługiwał się swoim własnym hasłem, które sobie ustawi, 
a nie kluczem, który zostanie mu wygenerowany raz na wieki

-- 
[ Email: a@b a=grp b=chmurka.net ]
[ Web:   http://www.chmurka.net/ ]

[toc] | [prev] | [next] | [standalone]

#31473

M.M. <mmarszik@gmail.com> 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. Chcę żeby były generowane w oparciu o datę i SN, 
bo nie chcę, żeby ten klucz działał w nieskończoność i na każdym 
urządzeniu.

-- 
[ Email: a@b a=grp b=chmurka.net ]
[ Web:   http://www.chmurka.net/ ]

[toc] | [prev] | [next] | [standalone]

#31475

On Wednesday, March 14, 2018 at 9:40:47 AM UTC+1, Adam Wysocki wrote:
> M.M. <mmarszik@gmail.com> 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.

Pozdrawiam

[toc] | [prev] | [next] | [standalone]

#31477

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

[toc] | [prev] | [next] | [standalone]

#31481

Roman Tyczka <noemail@because.no> wrote:

> 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.

Dokładnie tak. Do tego mamy wiele parkingów w okolicy, ale chcemy, żeby 
użytkownicy znający kod mogli zaparkować dzisiaj i jutro na konkretnym z 
nich, a nie na dowolnym (a pojutrze na żadnym).

-- 
[ Email: a@b a=grp b=chmurka.net ]
[ Web:   http://www.chmurka.net/ ]

[toc] | [prev] | [next] | [standalone]

#31482

On Wednesday, March 14, 2018 at 12:29:59 PM UTC+1, Roman Tyczka wrote:
> 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?
Czyli problemem jest wprowadzanie setek haseł z 
uprawnieniami, ważnością, itd? 

> 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.

Jeśli to ma być bezpieczne, to nie widzę innej możliwości, jak potraktowanie
tego (o czym wyżej już pisałem z dwa razy) jako transmisję danych. W
danych które użytkownik wprowadza powinny być uprawnienia, data ważności,
nazwa użytkownika i wszystko, co tam jeszcze potrzeba. Dane powinny być
zaszyfrowane i i podpisane. W systemie powinien być klucz prywatny systemu.
Dane powinny być zaszyfrowane kluczem publicznym systemu. W systemie 
powinny być wszystkie klucze publiczne użytkowników, czyli i tak i tak
do bezpiecznego(!) systemu trzeba trochę się na pierniczyć i wprowadzić
dane. Jeśli publicznych kluczy użytkowników nie będzie w systemie, to 
nie będzie pewności czy użytkownik jest tym, za kogo się podaje.

Przychodzi mi do głowy pewne rozwiązanie, ale nie ręczę za jego jakość.
Można w danych zawrzeć informację o nazwie użytkownika, zaszyfrować je
kluczem prywatnym użytkownika, a potem klucza prywatnego nie udostępniać
użytkownikowi. Wydaje mi się, że użytkownik bez klucza prywatnego nie
jest w stanie spreparować danych w celu podszycia się pod kogoś. Reszta
jak powyżej, klucz publiczny w systemie. Zamiast doklejania uprawnień i
ważności do hasła, po prostu zawieramy to wszystko w danych i do przekazywania
używamy bezpiecznego szyfrowania. 

Ale na kilku bitach tego nie zrobisz... Jeśli masz 100 użytkowników, to 
teoretycznie wystarczą Ci dwie cyfry na hasło, ale wtedy są dwie 
oczywiste wady:
 - nawet pomyłka przy wprowadzaniu hasła oznacza podszycie się pod innego
   użytkownika - nie trzeba się włamywać nawet.
 - i tak dane musisz wprowadzać do systemu.

Może wbij dane w jakieś tokeny zbliżeniowe i roześlij użytkownikom 
zwykłą pocztą?

Pozdrawiam 




od biedy, można 
wszystkich użytkowników potraktować 

[toc] | [prev] | [next] | [standalone]

#31484

M.M. <mmarszik@gmail.com> wrote:

>> > 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?
> Czyli problemem jest wprowadzanie setek haseł z 
> uprawnieniami, ważnością, itd? 

W pewnym sensie tak. To ma być awaryjny mechanizm odzyskania hasła, który 
w większości urządzeń nigdy nie będzie wykorzystany, bo:

a) służy jedynie do zarządzania -- o ile się tego explicte nie włączy, to 
do normalnej obsługi urządzenia nie jest potrzebne żadne hasło

b) ustawienie hasła na menu zarządzania nie jest obowiązkowe, użytkownik 
ma po prostu taką możliwość, żeby jego pracownicy mu nie grzebali

Zdarzają się pojedyncze sytuacje, w których użytkownik ustawi hasło, a 
potem albo zapomni, albo w ogóle nie ogarnia, że jakieś hasło ustawiał. 
Wtedy dzwoni i trzeba mu jakoś pomóc, niekoniecznie od razu wymieniając 
urządzenie na nowe.

Te sytuacje są na tyle rzadkie i wyjątkowe, że nie jest uzasadnione 
wprowadzanie setek haseł, wydawanie tokenów itd., ale jednak się zdarzają 
i musi być na to procedura (inna niż całkowita wymiana urządzenia).

> Jeśli to ma być bezpieczne,

Ma być tak bezpieczne, jak to możliwe w logistycznych realiach. Tzn. są 
pewne realia logistyczne (jak np. to, że nie będziemy dystrybuować po 
użytkownikach tokenów), w których rozwiązanie techniczne musi się zamknąć. 
Sam problem wyciągnięcia klucza z urządzenia też jest raczej teoretyczny, 
po prostu nie podoba mi się sam fakt, że ten klucz tam będzie i chcę to 
zrobić na tyle zgodnie ze sztuką, na ile to możliwe, nie zmieniając 
logistyki rozwiązania.

> to nie widzę innej możliwości, jak potraktowanie tego (o czym wyżej 
> już pisałem z dwa razy) jako transmisję danych. W danych które 
> użytkownik wprowadza powinny być uprawnienia, data ważności, nazwa 
> użytkownika i wszystko, co tam jeszcze potrzeba.

Tu nie ma szczególnej nazwy użytkownika.

Jest jeden superuser (właściciel urządzenia, który może mieć swoich 
pracowników), który dodaje poszczególnych użytkowników (swoich 
pracowników; oni mają swoje identyfikatory). Ten superuser ma możliwość 
zresetowania hasła użytkownika. Rozwiązanie, którego szukam, ma z kolei 
umożliwić reset hasła tego superusera.

> Dane powinny być zaszyfrowane i i podpisane. W systemie powinien być 
> klucz prywatny systemu. Dane powinny być zaszyfrowane kluczem publicznym 
> systemu. W systemie powinny być wszystkie klucze publiczne użytkowników, 
> czyli i tak i tak do bezpiecznego(!) systemu trzeba trochę się na 
> pierniczyć i wprowadzić dane. Jeśli publicznych kluczy użytkowników nie 
> będzie w systemie, to nie będzie pewności czy użytkownik jest tym, za 
> kogo się podaje.

Jest jedna ważna rzecz, o której chyba nie napisałem. Użytkownik 
(superuser) jest lokalny dla urządzenia. On nie istnieje poza nim, jego 
dane nie są nigdzie przesyłane. On odpowiada tylko za swoje urządzenie, a 
hasło ma zapewnić, że tylko on będzie miał dostęp do wszystkich pozycji 
menu.

> Przychodzi mi do głowy pewne rozwiązanie, ale nie ręczę za jego jakość.
> Można w danych zawrzeć informację o nazwie użytkownika, zaszyfrować je
> kluczem prywatnym użytkownika, a potem klucza prywatnego nie udostępniać
> użytkownikowi. Wydaje mi się, że użytkownik bez klucza prywatnego nie
> jest w stanie spreparować danych w celu podszycia się pod kogoś. Reszta
> jak powyżej, klucz publiczny w systemie.

Tu użytkownik też nie będzie miał żadnego klucza. Chodzi mi o teoretyczną 
sytuację, w której ktoś dobierze się do urządzenia lub do plików update'u 
(które nie są normalnie dystrybuowane, ale nie są też specjalnie tajne) i 
wyciągnie sobie klucz. Nie zna oczywiście algorytmu, który generuje hasło 
na podstawie tego klucza, ale security by obscurity nie biorę pod uwagę i 
zakładam, że algorytm jest znany (lub może być łatwo poznany).

> Ale na kilku bitach tego nie zrobisz...

No właśnie... wyobrażasz sobie przepisywanie 40-cyfrowego hasła przez 
telefon? Klient po 15 cyfrze powie, że ma to w gdzieś, nic nie będzie 
przepisywał i chce, żeby przyjechał technik i mu to zrobił lub wymienił 
urządzenie... i w sumie nie ma co mu się dziwić.

> Jeśli masz 100 użytkowników, to teoretycznie wystarczą Ci dwie cyfry na 
> hasło, ale wtedy są dwie oczywiste wady:
>  - nawet pomyłka przy wprowadzaniu hasła oznacza podszycie się pod innego
>    użytkownika - nie trzeba się włamywać nawet.

Tak jak wyżej -- użytkownik nie istnieje poza urządzeniem. Jak sobie 
zmieni hasło lub w ogóle je zdejmie, jak tak woli, to ta informacja nie 
jest nigdzie przesyłana. Wystarczy, że urządzenie o tym wie.

-- 
[ Email: a@b a=grp b=chmurka.net ]
[ Web:   http://www.chmurka.net/ ]

[toc] | [prev] | [next] | [standalone]

#31485

On Wednesday, March 14, 2018 at 9:07:45 PM UTC+1, Adam Wysocki wrote:
> M.M. <mmarszik@gmail.com> wrote:
> 
> >> > 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?
> > Czyli problemem jest wprowadzanie setek haseł z 
> > uprawnieniami, ważnością, itd? 
> 
> W pewnym sensie tak. To ma być awaryjny mechanizm odzyskania hasła, który 
> w większości urządzeń nigdy nie będzie wykorzystany, bo:

Możliwość odzyskiwania hasła stoi w sprzeczności z bezpieczeństwem
systemu. W bankach wysyłają hasło smsem, ale to jest dodatkowe 
hasło.

> 
> a) służy jedynie do zarządzania -- o ile się tego explicte nie włączy, to 
> do normalnej obsługi urządzenia nie jest potrzebne żadne hasło
> 
> b) ustawienie hasła na menu zarządzania nie jest obowiązkowe, użytkownik 
> ma po prostu taką możliwość, żeby jego pracownicy mu nie grzebali

Obawiam się, że powyżej opisujesz za bardzo szczegółowe cechy swojego
systemu, obawiam się, że nikomu nie będzie chciało się tego rozwiązać
za Ciebie. Sformułuj ogólnie problem, jak właśnie odzyskiwanie hasła,
albo jak uniknąć wklepywania danych - to możę ktoś postara Ci się
pomóc.


> Zdarzają się pojedyncze sytuacje, w których użytkownik ustawi hasło, a 
> potem albo zapomni, albo w ogóle nie ogarnia, że jakieś hasło ustawiał. 
> Wtedy dzwoni i trzeba mu jakoś pomóc, niekoniecznie od razu wymieniając 
> urządzenie na nowe.
Jest milion sposobów na odzyskanie hasła. Można sobie zapisać na kartce,
w komórce, na e-mailu swoim, w dedykowanym web-systemie producenta,
może być guzik na urządzeniu zamkniętym na kłódkę - ale co zrobić gdy
klucz do kłódki się zgubi? :) Wszystkie sposoby odzyskiwania hasła 
stoją w sprzecznosći z bezpieczeństwem.


> Te sytuacje są na tyle rzadkie i wyjątkowe, że nie jest uzasadnione 
> wprowadzanie setek haseł, wydawanie tokenów itd., ale jednak się zdarzają 
> i musi być na to procedura (inna niż całkowita wymiana urządzenia).

Jeśli to ma być bezpieczne, to nie umiem nic doradzić. Jedno przeczy drugiemu.


> 
> > Jeśli to ma być bezpieczne,
> 
> Ma być tak bezpieczne, jak to możliwe w logistycznych realiach. Tzn. są 
> pewne realia logistyczne (jak np. to, że nie będziemy dystrybuować po 
> użytkownikach tokenów), w których rozwiązanie techniczne musi się zamknąć. 
> Sam problem wyciągnięcia klucza z urządzenia też jest raczej teoretyczny, 
> po prostu nie podoba mi się sam fakt, że ten klucz tam będzie i chcę to 
> zrobić na tyle zgodnie ze sztuką, na ile to możliwe, nie zmieniając 
> logistyki rozwiązania.

Analizę zacznij od tego, na ile możesz narazić bezpieczeństwo systemu.


> 
> > to nie widzę innej możliwości, jak potraktowanie tego (o czym wyżej 
> > już pisałem z dwa razy) jako transmisję danych. W danych które 
> > użytkownik wprowadza powinny być uprawnienia, data ważności, nazwa 
> > użytkownika i wszystko, co tam jeszcze potrzeba.
> 
> Tu nie ma szczególnej nazwy użytkownika.
No ja to na początku zupełnie inaczej zrozumiałem.

> 
> Jest jeden superuser (właściciel urządzenia, który może mieć swoich 
> pracowników), który dodaje poszczególnych użytkowników (swoich 
> pracowników; oni mają swoje identyfikatory). Ten superuser ma możliwość 
> zresetowania hasła użytkownika. Rozwiązanie, którego szukam, ma z kolei 
> umożliwić reset hasła tego superusera.

Jest masa rozwiazań. Możesz dać hasło admina który ma prawo zresetować 
hasło superusera. Możesz mieć bazę haseł, do każdego urządzenia inne
hasło. Ale co gdy baza danych wycieknie? Albo co gdy o odzyskanie 
hasła poprosi osoba niepowołana do tego celu? Albo co gdy baza danych
się skasuje, albo uszkodzi w wyniku błędu w oprogramowaniu? 


> 
> > Dane powinny być zaszyfrowane i i podpisane. W systemie powinien być 
> > klucz prywatny systemu. Dane powinny być zaszyfrowane kluczem publicznym 
> > systemu. W systemie powinny być wszystkie klucze publiczne użytkowników, 
> > czyli i tak i tak do bezpiecznego(!) systemu trzeba trochę się na 
> > pierniczyć i wprowadzić dane. Jeśli publicznych kluczy użytkowników nie 
> > będzie w systemie, to nie będzie pewności czy użytkownik jest tym, za 
> > kogo się podaje.
> 
> Jest jedna ważna rzecz, o której chyba nie napisałem. Użytkownik 
> (superuser) jest lokalny dla urządzenia. On nie istnieje poza nim, jego 
> dane nie są nigdzie przesyłane. On odpowiada tylko za swoje urządzenie, a 
> hasło ma zapewnić, że tylko on będzie miał dostęp do wszystkich pozycji 
> menu.
Rozumiem, to chyba nie zwiększa szans na bezpieczne odzyskanie hasła.


> 
> > Przychodzi mi do głowy pewne rozwiązanie, ale nie ręczę za jego jakość.
> > Można w danych zawrzeć informację o nazwie użytkownika, zaszyfrować je
> > kluczem prywatnym użytkownika, a potem klucza prywatnego nie udostępniać
> > użytkownikowi. Wydaje mi się, że użytkownik bez klucza prywatnego nie
> > jest w stanie spreparować danych w celu podszycia się pod kogoś. Reszta
> > jak powyżej, klucz publiczny w systemie.
> 
> Tu użytkownik też nie będzie miał żadnego klucza. Chodzi mi o teoretyczną 
> sytuację, w której ktoś dobierze się do urządzenia lub do plików update'u 
> (które nie są normalnie dystrybuowane, ale nie są też specjalnie tajne) i 
> wyciągnie sobie klucz. 
Hasło admina, który mógłby zresetować hasło superusera, też się przechowuje
jako (najlepiej) dwukrotnie osoloną funkcję skrótu - więc z analizy kodu
tak łatwo nie wyciągnie nic. Ryzyko jest inne, że ktoś niepowołany 
podszyje się pod superusera i ktoś mu udostępni hasło admina.


> Nie zna oczywiście algorytmu, który generuje hasło 
> na podstawie tego klucza, ale security by obscurity nie biorę pod uwagę i 
> zakładam, że algorytm jest znany (lub może być łatwo poznany).
Odwrotnie. Jeśli seciruty by obscurity nie bierzesz pod uwagę, to używasz
znanego algorytmu. Oczywiście nieznany algorytm jest lepszy, a najłatwiej
zastosować nieznany algorytm poprzez podwójne solenie. Jedną sól spróbuj
ukryć w kodzie - do póki nie wycieknie, to algorytm jest nieznany.



> > Ale na kilku bitach tego nie zrobisz...
> 
> No właśnie... wyobrażasz sobie przepisywanie 40-cyfrowego hasła przez 
> telefon? 
Jeśli to ma być tylko do resetu, jeśli to będzie zdarzało się rzadko, 
to daj długość lekko ponad normalną, rzędu 15-20 znaków.

> Klient po 15 cyfrze powie, że ma to w gdzieś, nic nie będzie 
> przepisywał i chce, żeby przyjechał technik i mu to zrobił lub wymienił 
> urządzenie... i w sumie nie ma co mu się dziwić.
Przyjazd płatny i tyle.


> > Jeśli masz 100 użytkowników, to teoretycznie wystarczą Ci dwie cyfry na 
> > hasło, ale wtedy są dwie oczywiste wady:
> >  - nawet pomyłka przy wprowadzaniu hasła oznacza podszycie się pod innego
> >    użytkownika - nie trzeba się włamywać nawet.
> 
> Tak jak wyżej -- użytkownik nie istnieje poza urządzeniem. Jak sobie 
> zmieni hasło lub w ogóle je zdejmie, jak tak woli, to ta informacja nie 
> jest nigdzie przesyłana. Wystarczy, że urządzenie o tym wie.
Teraz rozumiem. Wcześniej myślałem, że chcesz w jednym urządzeniu 
zarejestrować np. 200 użytkowników, nadać im hasła, nadać im różne
przywileje, różny czas ważności hasła - i to wszystko bez modyfikacji
w urządzeniu. Wtedy po prostu byś musiał rozdać użytkownikom podpisane
dane, aby to oni wprowadzili za Ciebie dane.

Pozdrawiam

[toc] | [prev] | [next] | [standalone]

#31483

On Wednesday, March 14, 2018 at 7:29:59 AM UTC-4, Roman Tyczka wrote:
> 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

Sugeruje zapoznac sie z technologia uzywana przez zamki elektroniczne w hotelach (szczegolnie te modele ktore nie sa centralnie polaczone). Generalnie zamek zna data i czas (ale nawet to nie jest wymaganie). Uzycie nowego klucza z wygenerownym kodem powoduje ze zamek akceptuje ten klucz. Klucz posiada informacje jak dlugo jest wazny. Uzycie nowego klucza powoduje nadpisanie informacji z poprzedniego klucza. Prosta i skuteczna technika. Szyfrowanie informacji na kluczu jest zazwyczaj asymetryczne.

[toc] | [prev] | [next] | [standalone]

#31478

M.M. <mmarszik@gmail.com> 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?

Protokół nie musi być szyfrowany, ważne jest, żeby urządzenie prawidłowo 
rozpoznało podpis.

>> Chcę żeby były generowane w oparciu o datę i SN, 
> Ja myślałem, że chcesz bezpieczeństwa.

Widzisz inny sposób na podanie użytkownikowi awaryjnego hasła, które 
umożliwi mu awaryjne wykonanie funkcji, jak zapomni swojego hasła? 
Jakimś pomysłem jest challenge / response, tylko nie widzę przewagi 
challenge / response nad tym rozwiązaniem... Ty widzisz? (nie pytam 
złośliwie, może czegoś nie dostrzegam)

To, że hasło będzie mogło być użyte wielokrotnie danego dnia, to nie 
problem. Użytkownik, który wejdzie w jego posiadanie (a wejdzie po 
telefonicznej weryfikacji), i tak będzie mógł zmienić hasło na urządzeniu 
na swoje.

>> 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.

Użytkownik będzie miał swoje hasło, które ustawi sobie sam. Ono będzie 
przechowywane w postaci posolonego skrótu, więc nie do wyciągnięcia bez 
brute-force. Problem pojawi się, gdy użytkownik zapomni hasła. Helpdesk 
będzie musiał wtedy jakoś mu pomóc.

-- 
[ Email: a@b a=grp b=chmurka.net ]
[ Web:   http://www.chmurka.net/ ]

[toc] | [prev] | [next] | [standalone]

#31474

On Tue, 13 Mar 2018 16:11:51 +0000 (UTC), Adam Wysocki wrote:

Ja tylko tego momentu nie rozumiem:

> Tylko czy jest jakiś sposób, żeby przesłać sygnaturę w postaci niecałych 
> czterech bajtów (8 cyfr 0-9), ewentualnie całych (jak zwiększę liczbę cyfr 
> do 10)? Przecież urządzenie jej nie wygeneruje i nie obetnie sobie, żeby 
> ręcznie porównać zgodność, tak jak w przypadku wspomnianego wcześniej 
> skrótu.

O jakiej sygnaturze mowa? Oraz dlaczego "urządzenie jej nie wygeneruje"
skoro może obliczać hasze i robić inne rzeczy?

-- 
pozdrawiam
Roman Tyczka

[toc] | [prev] | [next] | [standalone]

#31479

Roman Tyczka <noemail@because.no> wrote:

>> Tylko czy jest jakiś sposób, żeby przesłać sygnaturę w postaci niecałych 
>> czterech bajtów (8 cyfr 0-9), ewentualnie całych (jak zwiększę liczbę cyfr 
>> do 10)? Przecież urządzenie jej nie wygeneruje i nie obetnie sobie, żeby 
>> ręcznie porównać zgodność, tak jak w przypadku wspomnianego wcześniej 
>> skrótu.
> 
> O jakiej sygnaturze mowa? Oraz dlaczego "urządzenie jej nie wygeneruje"
> skoro może obliczać hasze i robić inne rzeczy?

Chodzi o to, jak bym to zrobił, gdybym mógł przesłać pełną sygnaturę. 
Wtedy klucz prywatny mamy w generatorze, publiczny w urządzeniu, 
przepisujemy sygnaturę (dane, które są podpisywane, urządzenie zna, bo to 
dzisiejsza data i nr seryjny) i urządzenie sobie ją weryfikuje, ale samo 
jej nie wygeneruje (bo nie ma klucza prywatnego), żeby móc ręcznie 
porównać np. trzy bajty, które dostanie w ramach hasła.

Gdyby dało się przesłać sygnaturę tylko na 3-4 bajtach i skutecznie ją 
zweryfikować bez posiadania klucza prywatnego, którym była wygenerowana, 
to byłoby to dokładnie to, czego potrzebuję...

-- 
[ Email: a@b a=grp b=chmurka.net ]
[ Web:   http://www.chmurka.net/ ]

[toc] | [prev] | [standalone]

Back to top | Article view | pl.comp.programming

csiph-web