Re: PKI a weryfikacja krótkiego podpisu (3 bajty) - Grupy dyskusyjne w eGospodarka.pl

eGospodarka.pl › Grupy › pl.comp.programming › PKI a weryfikacja krótkiego podpisu (3 bajty) › Re: PKI a weryfikacja krótkiego podpisu (3 bajty)

X-Received: by 10.31.153.208 with SMTP id b199mr541616vke.13.1521026369755; Wed, 14
Mar 2018 04:19:29 -0700 (PDT)
X-Received: by 10.31.153.208 with SMTP id b199mr541616vke.13.1521026369755; Wed, 14
Mar 2018 04:19:29 -0700 (PDT)
Path: news-archive.icm.edu.pl!news.icm.edu.pl!news.nask.pl!news.nask.org.pl!news.unit
0.net!weretis.net!feeder6.news.weretis.net!feeder.usenetexpress.com!feeder-in1.
iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!r16no13
3152qtn.1!news-out.google.com!c39ni371qta.0!nntp.google.com!t24no134259qtn.0!po
stnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
Newsgroups: pl.comp.programming
Date: Wed, 14 Mar 2018 04:19:29 -0700 (PDT)
In-Reply-To: <1...@t...com>
Complaints-To: g...@g...com
Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=178.36.206.142;
posting-account=xjvq9QoAAAATMPC2X3btlHd_LkaJo_rj
NNTP-Posting-Host: 178.36.206.142
References: <p88t87$34n$1$gof@news.chmurka.net>
<4...@g...com>
<j...@t...com>
<e...@g...com>
<1...@t...com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <f...@g...com>
Subject: Re: PKI a weryfikacja krótkiego podpisu (3 bajty)
From: "M.M." <m...@g...com>
Injection-Date: Wed, 14 Mar 2018 11:19:30 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Lines: 72
Xref: news-archive.icm.edu.pl pl.comp.programming:212307
[ ukryj nagłówki ]

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.