Dnia czwartek, 29 maja 2014 13:14:58 Marek Zibrow pisze:
W dniu 29 maja 2014 10:47 użytkownik Paweł Zegartowski
pzegar@gmail.com napisał:
Fizyczne tokeny utrudniają też łatwe zwiększenie liczby kluczy. No i oczywiscie podnoszą koszta.
Problem z wirtualnymi jest niestety podobny (plus parę innych związanych z ich tworzeniem). Niestety każde zgłoszenie utraty tokenu to powtórna generacja wszystkiego dla wszystkich. Oczywiście softtoken jest tani, można nawet stwierdzić, że bezpłatny, tylko co z tego, kiedy ponowne losowanie wszystkich tokenów (z utopijnym założeniem, że nikt nie rejestruje pobrania softtokena ze storage'u) jest niemal równie niepraktyczne jak ponowne losowanie fizycznych smartcard. Dodatkowo powtórzę jeszcze raz moją tezę, że system taki jest kompletnie nieodporny na złośliwe zgłoszenia utraty. Naprawdę nie mam ochoty nikogo onieśmielać bo jak wiadomo należy atakować problemy i szukać nowych rozwiązań ale wydaje mi się, że to było już parę razy przerabiane a sam rynek udowadnia dlaczego to nie działa... Stąd oprócz zapotrzebowania rysia postawiłbym pytanie:
Jak zrealizować to za pomocą typowego center-of-trust tak, żeby wilk był syty i owca cała?
Zgniły kompromis? Pewnie tak. Ale to jak z dzieleniem przez 0. Czy dyskusję można poprowadzić także w tym kierunku? Rysiu?
Pojadę "teorią" dlaczego uważam sprawę za z góry przegraną i mam nadzieję, że ktoś to zrozumie i przestaniemy przynajmniej powtarzać podstawowe błędy (matko jak ja nie lubię być malkontentem, ale muszę): Wszystkie znane mi systemy set-of-trust działają w przestrzeni zaufania gdzie każdy element setu jest znany wszystkim pozostałym i w każdej chwili wywoływalny. Set-of-trust w przestrzeni niezaufanej nie sprawdza się. Nie dlatego, że nie da się tego stworzyć. Tylko dlatego, że każde usunięcie elementu, brak dostępu do elementu, dodanie elementu, powoduje że set-of-trust staję się nietrust.
A czy możesz zalinkować do jakichś materiałów dotyczących set-of-trust? Bo ja chciałbym móc poznać ten temat głębiej, na przykład.