eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programmingPKI a weryfikacja krótkiego podpisu (3 bajty) › Re: PKI a weryfikacja krótkiego podpisu (3 bajty)
  • Path: news-archive.icm.edu.pl!news.icm.edu.pl!news.nask.pl!news.nask.org.pl!news.unit
    0.net!border1.nntp.ams1.giganews.com!nntp.giganews.com!peer01.ams1!peer.ams1.xl
    ned.com!news.xlned.com!peer02.am4!peer.am4.highwinds-media.com!peer01.fr7!futte
    r-mich.highwinds-media.com!news.highwinds-media.com!newsfeed.neostrada.pl!unt-e
    xc-01.news.neostrada.pl!unt-spo-a-01.news.neostrada.pl!news.neostrada.pl.POSTED
    !not-for-mail
    From: Roman Tyczka <n...@b...no>
    Subject: Re: PKI a weryfikacja krótkiego podpisu (3 bajty)
    Newsgroups: pl.comp.programming
    User-Agent: 40tude_Dialog/2.0.15.84
    MIME-Version: 1.0
    Content-Type: text/plain; charset="utf-8"
    Content-Transfer-Encoding: 8bit
    Sender: r...@t...no.found
    References: <p88t87$34n$1$gof@news.chmurka.net>
    <4...@g...com>
    <j...@t...com>
    <e...@g...com>
    Date: Tue, 13 Mar 2018 20:22:25 +0100
    Message-ID: <1...@t...com>
    Lines: 34
    Organization: Telekomunikacja Polska
    NNTP-Posting-Host: 94.75.90.137
    X-Trace: 1520968947 unt-rea-a-01.news.neostrada.pl 677 94.75.90.137:6107
    X-Complaints-To: a...@n...neostrada.pl
    X-Received-Bytes: 2697
    X-Received-Body-CRC: 2070594543
    Xref: news-archive.icm.edu.pl pl.comp.programming:212302
    [ ukryj nagłówki ]

    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

Podziel się

Poleć ten post znajomemu poleć

Wydrukuj ten post drukuj


Następne wpisy z tego wątku

Najnowsze wątki z tej grupy


Najnowsze wątki

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: