"Krzysztof Halasa" m...@i...localdomain

>> Czy PIN się szyfruje sam? Chyba można go uzupełnić numerem
>> karty, nazwiskiem, PESELem, numerem dowodu, kolorem włosów,
>> długością w zwisie...

> Nie ma to żadnego znaczenia - to nie są tajne dane.

Przykładowo pesel jest numerem, który warto znać, aby dostać się do Mille.

--
.`'.-. ._. .-.
.'O`-' ., ; o.' eneuel@@gmail.com '.O_'
`-:`-'.'. '`\.'`.' ~'~'~'~'~'~'~'~'~ o.`.,
o'\:/.d`|'.;. p \ ;'. . ;,,. ; . ,.. ; ;. . .;\|/....

do góry

W dniu czwartek, 15 listopada 2012 23:49:00 UTC+1 użytkownik Krzysztof Halasa
napisał:
> witek <w...@g...pl.invalid> writes:
>
>
>
> >> W jakis sposob musi miec mozliwosc porownac, ze PIN wprowadzony przez
>
> >> ciebie w bankomacie czy sklepie sie zgadza?
>
> >
>
> > do tego pin mu nie jest potrzebny.
>
>
>
> Potrzebne jest coś, co pozwoli na jego sprawdzenie. Nawet 6 cyfr to dla
>
> zwykłego komputerka czas grubo poniżej sekundy.
>
>
>
> Jakąś możliwością jest taka, w której sprawdzenie każdej kombinacji
>
> byłoby bardzo kosztowne obliczeniowo. Wtedy oczywiście atak na
>
> pojedynczą kartę wciąż byłby możliwy (i łatwy - komputery w banku nie
>
> mogą być nieograniczone), ale już atak na np. wszystkie karty byłby
>
> nieopłacalny. Tyle że to nie rozwiązuje żadnego praktycznego problemu.
>
>
>
> >> Rowniez, w wiekszosci przypadkow dla kart mozliwa liczba kombinacji to
>
> >> 10000 (dla 4-cyfrowego pinu); nawet, gdy bank przechowuje pin w postaci
>
> >> "zaszyfrowanej", znalezienie odpowiedniej kombinacji to kilka sekund dla
>
> >> wspolczesnego komputera. Dla 6 cyfrowego PINu - niewiele dluzej.
>
> >
>
> > jeszcze musisz wiedziec jak zaszyfrowanej.
>
> >
>
> > zapisz sie na jakis kurs kryptografii.
>
>
>
> Przecież ma rację, no może poza tym, że to aż tak długo nie trwa.
>
>
>
> Nie myślisz też chyba że łatwiej ukryć algorytm niż bazę PINów?
>
> BTW zawartość bazy wygeneruje (z dużym prawdopodobieństwem) w sposób
>
> sensowny bezduszny prosty program typu cat /dev/random. Zrób to samo
>
> z algorytmem, i nie zdziw się później, gdy okaże się trywialnie łamalny.
>
> BTW znakomita większość "autorskich" algorytmów szyfrujących jest
>
> trywialnie łamalna, nawet jeśli teoretyczne założenia umożliwiają
>
> napisanie dobrego algorytmu (tu tego nie mamy).
>
>
>
> W tej chwili praktycznie dowolne algorytmy tego typu operujące na
>
> powiedzmy 48-bitowych kluczach są łatwe do złamania nawet amatorskimi
>
> sposobami. 4-cyfrowy PIN to jest tylko (prawie) 14 bitów, w kontekście
>
> kryptografii to nawet nie jest śmieszne.
>
> --
>
> Krzysztof Halasa

A nie można przyjąć założenie że kluczem szyfrującym nie jest PIN tylko jakiś
wielobitowy klucz inny a pin jest częścią wiadomości szyfrującej?

do góry

Zibo wrote:
> A nie można przyjąć założenie że kluczem szyfrującym nie jest PIN tylko jakiś
wielobitowy klucz inny a pin jest częścią wiadomości szyfrującej?


są całe algorytmy do wymiany i uzgadniania kluczy.

do góry

Zibo <z...@g...com> writes:

> A nie można przyjąć założenie że kluczem szyfrującym nie jest PIN
> tylko jakiś wielobitowy klucz inny a pin jest częścią wiadomości
> szyfrującej?

Tzn. rozumiem że PIN ma być częścią wiadomości szyfrowanej. Oczywiście,
można tak zrobić, tyle że bank w dalszym ciągu będzie znał PINy -
zaszyfrowane, ale będzie je mógł (i musiał) sobie odszyfrowywać swoim
kluczem, który przecież musi znać.

Problem leży w wielkości przestrzeni PINów (kluczy). W tym przypadku
tylko PIN jest tajny i potencjalnie nieznany bankowi, a brutalny atak na
niego jest dziecinnie łatwy. Nie ma żadnej innej informacji, nieznanej
bankowi, która byłaby znana właścicielowi terminala (bankomatu), i która
mogłaby służyć jako część klucza.

Gdyby np. było tak, że na podstawie odcisków palców dałoby się
wygenerować część klucza, i gdyby te odciski palców były przynajmniej
tak tajne jak PIN, _oraz_gdyby_bank_ich_nie_znał_, oraz gdyby bankomaty
i inne terminale mogły ich używać (wraz z PINem) do obliczenia całego
klucza, to to miałoby teoretyczny sens. Oczywiście w praktyce tak by to
nie działało.


Istnieje metoda bezpiecznej dla obu stron weryfikacji zleceń bankowych,
i jest zresztą dość szeroko wykorzystywana - tyle, że nie w bankowości
detalicznej. Klient po prostu podpisuje zlecenie swoim asymetrycznym
kluczem prywatnym, bank to sprawdza i wystawia potwierdzenie (podpisane
kluczem banku). W takim układzie żadna ze stron nie zna klucza
prywatnego drugiej strony ani żadna ze stron nie może się wyprzeć
wystawienia zlecenia (ani jego treści, w tym np. czasu wystawienia).
Jednak takie rozwiązanie zastosowane dla "Kowalskiego" miałoby pewnie
zasadnicze wady, związane z niewielką świadomością i możliwościami
"Kowalskiego".
--
Krzysztof Halasa

do góry

On Thu, 22 Nov 2012 19:53:18 +0100, Krzysztof Halasa <k...@p...waw.pl>
wrote:

>kluczem banku). W takim układzie żadna ze stron nie zna klucza
>prywatnego drugiej strony ani żadna ze stron nie może się wyprzeć
>wystawienia zlecenia (ani jego treści, w tym np. czasu wystawienia).

pozostaje kwestia zaufania do urządzeń przechowujących klucze i
przeprowadzających operację wyliczania MAC i znakowania czasem...
--
pozdrawiam,
Jarek Andrzejewski
Super gadżet na Mikołaja lub gwiazdkę: zwijacz do krawata!
http://allegro.pl/show_item.php?item=2808394711

do góry

Jarek Andrzejewski <p...@g...com> writes:

>>kluczem banku). W takim układzie żadna ze stron nie zna klucza
>>prywatnego drugiej strony ani żadna ze stron nie może się wyprzeć
>>wystawienia zlecenia (ani jego treści, w tym np. czasu wystawienia).
>
> pozostaje kwestia zaufania do urządzeń przechowujących klucze i
> przeprowadzających operację wyliczania MAC i znakowania czasem...

Zakładamy że bank może ufać swoim urządzeniom.
Na drugim końcu (klienta) potencjalny problem jest zawsze mniejszy lub
równy temu, który mamy używając PINów, haseł itp.
--
Krzysztof Halasa

do góry