Autor: smarkacz (smarkacz_at_anathema.eu.org)
Data: Mon 09 Nov 1998 - 01:27:02 MET
on Sun, 08 Nov 1998 22:37:47 GMT, Jacek Popławski wrote:
> smarkacz wrote:
> >Jeśli będzie podany ident to rzeczywiście - przy czym żebym
> >rzeczywiście łatwo mógł skojarzyć że np. vGewgMb1x4FNA@*.tpnet.pl
> >to Jacek Popławski. Tylko podpisując post nazwiskiem zrobiłeś to
> >sam, z własnej woli, podobnie teraz każdy kto czyta newsy może
> >skojarzyć, że jpopl_at_kki.net.pl to właśnie Ty.
>
> błąd
> jpopl_at_kki.net.pl mogę zmienić w każdej chwili... :-)
Czy aby na pewno przeczytałeś to co napisałem? :)
> >Z kolei ustalenie imienia i nazwiska osoby której przyklejono
> >identa 3qn1CCZuRDaWq będzie co najmniej nietrywialne,
>
> wystarczy że ktokolwiek pozna to nazwisko
Tak jak teraz wystarczy, że ktokolwiek pozna jakiś zastrzeżony
numer telefonu, sam znam takich kilkanaście i jakoś nikt z tego
powodu nie płacze.
> >ponieważ on
> >po pierwsze, wcale nie musiał pisać na newsy pod własnym
> >nazwiskiem
>
> ale już nie będzie mógł napisać czegoś pod pseudonimem :-)
Będzie mógł, wystarczy że znajdzie serwer który nie poda dalej
identa a jedynie NNTP-Posting-Host. A jeśli takich serwerów nie
będzie... cóż, ja płakał nie będę :) chociaż jakoś wątpię, żeby
takiej możliwości nie było.
> poza tym argumentem darius jack'a był głównie udział w handlu internetowym,
> tzn. gdy ktoś złoży zamówienie na coś - musi podać dokładne dane - adres,
> nazwisko, etc...
I słusznie... ma przecież wybór, podać te dane i zostawić je
gdzieś skojarzone z identem, albo ich nie podawać; jest zresztą
jeszcze parę metod obejścia tego identa...
> >1. Że nie jest możliwe nieodwracalne (także przez brute force)
> >przypisanie identyfikatorów do numerów telefonów;
>
> możliwe jest zawsze (choćby losowo), ale brute force nie będzie
> potrzebna - wystarczy wyśledzić ;) tego kogoś choćby na newsach
Jak sam, z własnej woli się podpisał to nie widzę problemu.
> >2. Że znajomość pewnej części przypisań ident - telefon pozwoli
> >dojść reszty tychże przypisań.
>
> to już bez sensu... ale gdzie on tak twierdził? możesz podać message-id?
<3641BD8B.1098_at_usa.net>
-----
Przeciez pisalem, ze na szybszym serwerze to trzeba 7 min. na odwrocenie
idxxx = tel.
Element losowy nie ma znaczenia, jezeli dostep do znacznej czesci bazy
idxxx = imie, nazwisko , bedzie dostepny w logach serwerow www.
-----
> >* TPSA loguje cały transfer z numeru 0202122 (no, to jeszcze
> >możliwe...);
>
> kiedyś sam się nad tym zastanawiałem - i doszedłem do wniosku, że
> teoretycznie jest to możliwe - ale kosztowałoby majątek (gdzie to
> wszystko składować?)
Toteż napisałem że to jest "jeszcze możliwe" - tylko że IMHO
raczej nierealne...
> >* Wystarczy 100 przypisań plaintext - ciphertext żeby określić
> >klasę algorytmu kodowania (w zasadzie nawet więcej, chodziło o
> >przypisanie identyfikatorów które wcale nie musi być kodowaniem);
>
> mógłbyś to wytłumaczyć? jeżeli algorytm kodowania polega na losowaniu,
> to nic z powyższego zdania nie rozumiem...
Ja też nie rozumiem :-) ale:
<364177D9.5D19_at_usa.net>
-----
Na podstawie nawet 100 przykladkow mozna okreslic klase i typ algorytmu.
W Europie i w swiecie jest dopuszczonych i certyfikowanych do zastosowan
w telekomunikacji jedynie okreslona liczba algorytmow szyfrujacych i ich
certifikaty , wyniki testow sa dostepne wraz z tymi swiadectwami
certyfikujacymi.
Bedzie wiadomo czy to DES/RSA/crypt /...
-----
> >ps. Przepraszam wszystkich, którym właśnie wyskoczyłem z killfile
> >i obiecuję przez dłuższy czas nie zmieniać adresu.
>
> hmmm.... czyżby na polipie każdy był w czyimś killfile? ;-) muszę
> się zacząć przyzwyczajać... :-)
Nie wiem czy jestem w czyimś killfile na polipie i mnie to
średnio interesuje... Jak ktoś nie chce czytać mniej lub bardziej
natchnionych wypocin mojego skromnego autorstwa to jego sprawa;
ja w żadnym wypadku nie zamierzam uciekać z killfiles, dlatego
też to napisałem.
-- [Jacek P. Szymański]##[smarkacz_at_anathema.eu.org]##[IRC: smarkacz] [Network Admin]#######[ZmieńNa_Fanklub: http://hultaj.bti.pl/znf] ####[The definition of an Upgrade: old bugs out, new ones in]####
To archiwum zostało wygenerowane przez hypermail 2.1.7 : Wed 19 May 2004 - 16:17:32 MET DST