RC5 - a cóż to za ustrojstwo, gdzie się urodziło i dlaczego tylu ludzi się z tym męczy?

RC5 to algorytm szyfrowania wynaleziony przez RSA Data Security, Inc. Jest to algorytm symetryczny, co oznacza, że tego samego klucza używa się do zaszyfrowania i odszyfrowania wiadomości (odmiennie od kluczy publicznych i algorytmów asymetrycznych, które używają różnych kluczy do tych operacji).

Klucz jest łańcuchem liczb binarnych, które użyte wraz z fragmentem tekstu szyfrują, bądź rozszyfrowują go. Algorytmy symetryczne zazwyczaj są klasyfikowane poprzez rozmiar ich kluczy, lub tzw. długość klucza. Jeden z wczesnych algorytmów, nazwany DES (Data Encryption Standard - Standard Szyfrowania Danych), używa kluczy 56 bitowych, podobnie jak jeden z wcześniejszych wariantów RC5, jednak ten drugi uznawany jest za znacznie silniejszy.

Obecnie RSA prowadzi konkurs mający na celu odnalezienie właściwego klucza, aby rozszyfrować zakodowaną wiadomość. Jedyne co wiadomo o niej, to że jej początek powinien po odkodowaniu odpowiednim kluczem brzmieć: 'The unknown message is:'. Ideą konkursu jest wykazanie siły szyfrowania algorytmu. Obecny projekt (uruchomiony 3 grudnia 2002 - RC5-72) skupia ludzi próbujących rozkodować tekst zaszyfrowany RC5 o długości 72 bitów, czyli z grubsza mówiąc do sprawdzenia jest 2^72, co daje 4,722,366,482,869,645,213,696 możliwych kluczy.

Najszybszym dostępnym obecnie komputerom znalezienie odpowiedniego klucza zajęłoby setki tysięcy lat. Właśnie dlatego narodziła się idea stworzenia najpotężniejszego komputera na świecie złożonego z mniejszych, połączonych w całość. W tym właśnie miejscu pojawia się Distributed.Net, która doprowadziła do takiego stanu rzeczy. Organizacja ta stworzyła odpowiednie serwery dystrybuujące bloki kluczy komputerom na których uruchomiony jest program kliencki, również rozwijany przez Distributed. 'Zużyte' klucze odsyłane są do centralnego komputera, który oznacza je jako wypróbowane i wysyła klientom kolejne do analizy.

Ogólnie na pojedynczy projekt przeznaczone jest 10,000$, z czego następuje podział:

- 6,000$ dla distributed.net
- 1,000$ dla osoby, która jako pierwsza znalazła klucz
- 1,000$ dla teamu zwycięzcy
- 2,000$ dla Free Software Foundation
Jeśli osoba, która jako pierwsza znalazła klucz, nie należała do żadnego teamu, otrzymuje 2,000$.

Co przyciąga ludzi do uczestnictwa w projekcie? Na pewno jest to współzawodnictwo. Użytkownicy tworzą grupy (teamy), do których przynależność dodatkowo mobilizuje. Inni liczą, ponieważ lubią statystyki, tabelki i podobne temu rzeczy, których w RC5 jest cała masa. Jeszcze inni robią to po prostu dla zabawy.

Gdzie kupić części, czyli co nam będzie potrzebne?

• klient RC5 (do ściągnięcia tutaj) w wersji odpowiedniej dla typu procesora jaki posiadamy;
• system AmigaOS w wersji co najmniej 2.04, a jeśli planujemy używać klienta w wersji pod PowerPC, co najmniej AOS 3.0;
• dostęp do internetu;
• dla klienta 68k - procesor od 68000 wzwyż;
• dla klienta PPC (WarpOS) - procesor PPC 603e lub lepszy. Ponadto system WarpUp w wersji co najmniej 4.0, powerpc.library co najmniej 15.0;
• dla klienta PPC (PowerUp) - procesor PPC 603e lub lepszy, ppc.library autorstwa Ralpha Schmidta w wersji co najmniej 46.30 (dostępna pod tym adresem), rozmiar stosu minimum 200000 bajtów (można ustawić w ikonce programu);
• użytkownicy MorphOSa powinni używać specjalnej wersji napisanej dla tego systemu operacyjnego (chociaż działa też wersja PowerUp, ale o wiele wolniej), do ściągnięcia stąd.

Jak smarować, żeby jechało - konfiguracja klienta.

Przy pierwszym uruchomieniu klienta na naszej Amidze ujrzymy okno preferencji. Poniżej postaram się opisać która opcja do czego służy (aby wybrać to co nas interesuje, wpisujemy numer opcji i naciskamy 'enter').

Poniżej prezentuję konfigurację bardzo szczegółowo (przykładowe wartości pól zaczerpnąłem z własnej). Niecierpliwych, albo tych którzy nie lubią się bawić w ustawianie wszystkiego, odsyłam na koniec tego punktu, gdzie znajdą przykład gotowej konfiguracji (jako wypisanie zawartości pliku .ini).

1. General client options - tutaj znajdują się niezbędne ustawienia do poprawnej pracy klienta.

1. Your email address (distributed.net ID) ==> ajus79@box43.pl
   Adres e-mail, który będzie identyfikował przeliczone przez Ciebie bloki. Musi to być adres istniejący, gdyż na niego otrzymasz hasło dostępu do swojego konta na distributed.net.
2. Complete this many packets, then exit ==> 0 (no limit)
   Klient po przeliczeniu podanej tutaj liczby bloków samoczynnie zakończy działanie.
3. Run for this long, then exit ==> 0:00 (no limit)
   Podobnie jak powyżej, tyle że limit jest czasowy.
4. Pause flagfile Path/Name ==>
   Jeżeli program wykryje w swoim katalogu istnienie pliku o podanej tutaj nazwie, automatycznie zatrzyma operację przeliczania bloków. Praca nie zostanie wznowiona dopóki plik będzie istniał.
5. Exit flagfile Path/Name ==> exitrc5.now
   Jeżeli program wykryje w swoim katalogu istnienie pliku o podanej tutaj nazwie, natychmiast zakończy pracę i nie uruchomi się dopóty, dopóki plik ten będzie istniał.
6. Enable restart on .ini file change? ==> no
   Ustawienie tej opcji na "yes" spowoduje, że w razie wykrycia zmiany daty/czasu modyfikacji pliku .ini (plik konfiguracyjny), klient się zrestartuje.
7. "Pause if running" ==>
   Klient automatycznie się zatrzyma, jeżeli wykryje nazwę zadania, którą podasz w tym polu (może to być np. Quake, mpega etc.).
8. Pause if running on battery power? ==> yes
   Ta opcja w przypadku AmigaOS nie ma zastosowania i jest ignorowana.
9. Run detached/disable all screen output? (quiet mode) ==> no
   Czy program ma działać w trybie utajonym (tzn. bez informowania o tym, co się aktualnie dzieje).
10. Crunch-o-meter (progress indicator) style ==> 2
    Rodzaj wyświetlania informacji o postępie w przeliczaniu danego bloku. Mamy do wyboru:
    0 - bez wyświetlania informacji,
    1 - wyświetla obecną pozycję w przeliczanym pakiecie za a pomocą cyfr,
    2 - wyświetla postęp procentowo (nie zalecane dla projektu OGR),
    3 - pokazuje tempo przeliczania kluczy, np: "[...] RC5: rate 761,468 kkeys/sec".
    -1 - autowykrywanie.
11. Return to main menu
    Tego chyba opisywać nie trzeba. :-)

2. Buffer and Buffer Update Options - opcje dotyczące buforów (czyli przechowywanych na dysku lub w pamięci przeliczanych bloków) oraz ich uaktualniania.

1. Buffer in memory only? (no disk I/O) ==> no
   Czy bufor ma być przechowywany wyłącznie w pamięci? (nie ma aktywności dysku). Opcja jest przydatna w przypadku gdy mamy stałe łącze internetowe, jednak komputer nie posiada własnego dysku. UWAGA: Zakończenie pracy klienta bez uprzedniego wysłania przeliczonych bloków na serwer, spowoduje utratę wykonanej pracy.
2. In-Buffer Filename Prefix ==> buff-in
   Nazwa pliku, który będzie identyfikowany jako zawierający nowe bloki do przeliczenia (automatycznie zostanie dodane do tej nazwy rozszerzenie ".r72"). Plik znajdować się będzie w tym samym katalogu co klient.
3. Out-Buffer Filename Prefix ==> buff-out
   To samo co powyżej, tylko że plik służy do przechowywania już przeliczonych bloków.
4. Checkpoint Filename ==> chkpoint.r72
   Określa nazwę pliku, w którym klient co jakiś czas zapisuje postępy swoich prac. Pozwala to np. na przerwanie liczenia w 3/4 bloku, a następnie kontynuowanie od tego samego miejsca przy kolejnym uruchomieniu.
5. Disable buffer updates from/to a keyserver ==> yes
   Ustawienie tej opcji na "yes" spowoduje, że nie zaistnieje automatyczne wysłanie już przeliczonych bloków na serwer i pobranie nowych. Gdy damy "no", wtedy w momencie gdy klientowi zabraknie nowych bloków do przeliczania, sam nawiąże połączenie z odpowiednim serwerem i pobierze kolejne bloki, wysyłając jednocześnie już przerobione (zalecane jest posiadanie stałego łącza przy tej opcji).
6. Disable buffer updates from/to remote buffers ==> no
   Ustawienie tej opcji na "no" spowoduje, że klient będzie korzystał z osobnych plików zawierających bloki do przeliczenia (chodzi tu o pliki z nazwami 'buff-in' i 'buff-out'). Należy użyć "no", jeżeli w poprzednim punkcie ustawiliśmy wartość parametru "yes", tzn. nie pozwalamy na automatyczne pobieranie bloków przez internet.
7. Remote buffer directory ==>
   Tutaj podajemy ścieżkę dostępu do katalogu z plikami 'buff-in i 'buff-out', jeżeli przechowywane są one w odrębnym katalogu, a nie dysponujemy połączeniem z internetem w celu zaktualizowania pakietów.
8. Load-work precedence ==> RC5-72,OGR=0
   Określa ważność projektu wg kolejności występowania. Kolejne projekty, oddzielone przecinkami, obrazują porządek w jakim pobierane i przeliczane są odpowiednie bloki. Możemy też np. nie chcieć brać udziału w jakimś konkursie, więc wpisujemy wtedy "=0" (tak jak w przypadku OGR w przykładowej konfiguracji).
   (poniższe opcje pojawią się dopiero po ustawieniu pola 2.5) na "no":
9. Fetch work threshold ==> OGR=0,RC5-72=0
   Wpisanie tutaj wartości na przykład: RC5-72=4 spowoduje, że przy nawiązaniu połączenia z serwerem, będą pobierane po 4 bloki do przeliczenia (odpowiednik co najmniej 6 godzin pracy na procesorze PPC 603e/210 MHz). Jeżeli pozostawimy tutaj "0", wtedy zmieniamy poniższą zmienną;
10. Fetch time threshold (in hours) ==> RC5-72=0
    Określa co jaki czas (w godzinach) klient ma się łączyć z serwerem i wysyłać stare/pobierać nowe bloki do przeliczenia.

3. Performance related options - opcje związane z wydajnością klienta.

1. Core selection ==> RC5-72=8
   Wybór rdzenia, czyli algorytmu używanego do przeliczania kluczy. Wartość tego parametru powinno się ustawić na "-1", gdyż wtedy automatycznie zostaje wybrany najlepszy rdzeń dla wykrytego procesora.
2. Number of crunchers to run simultaneously ==> -1 (auto-detect)
   Opcja dotyczy maszyn wieloprocesorowych. Jeżeli np. mielibyśmy w swojej Amidze 3 procesory PowerPC, wtedy parametr ten powinien przyjąć wartość "3". Najlepiej ustawić jednak na "-1", gdyż wtedy automatycznie wykrywana jest ilość procesorów. Nie ma tu znaczenia fakt, że mamy w swojej Amidze np. jednocześnie procesor PPC i M68k, gdyż są dla nich przeznaczone osobne wersje klientów.
3. Priority level to run at ==> 0 (lowest/at-idle)
   Priorytet z jakim ma być uruchomiony proces przeliczania kluczy. Oczywiście im wyższy, tym większe zapotrzebowanie na czas procesora. Przy ustawieniu na "0" klient będzie zajmował procesor tylko w momencie, gdy inne programy będą z niego korzystały w minimalnym stopniu. Wybór priorytetu "9" spowoduje, że klient będzie miał pierwszeństwo przed innymi programami.

4. Logging Options - opcje dziennika.

1. Log file type ==> none
   Mamy do wyboru:
   0 - bez dziennika,
   1 - rozmiar dziennika jest nieograniczony,
   2 - dziennik zostanie skasowany i w jego miejsce utworzony nowy, w momencie gdy jego plik osiągnie wielkość podaną w parametrze "Log file limit",
   3 - najstarsze linie dziennika są kasowane, aby mogły zostać dopisane najnowsze. Podobnie jak powyżej, parametrem dodatkowym tutaj jest rozmiar pliku z dziennikiem,
   4 - Co jakiś czas będzie tworzony nowy dziennik. Odstęp czasu ustalamy za pomocą tego samego parametru "Log file limit".
2. File to log to ==>
   Opcja ta jest niedostępna, jeżeli w punkcie powyżej wybraliśmy "0". Określa nazwę pliku dziennika.
3. Log file limit/interval ==>
   Opcja jest dostępna tylko gdy w punkcie 4.1 konfiguracji wybraliśmy wartość 2, 3, lub 4. Definiujemy tutaj rozmiar pliku lub odstęp czasu pomiędzy tworzeniem nowych dzienników.
4. Log by mail spool size (bytes) ==> 0 (mail disabled)
   Klient może samoczynnie przesyłać nam dziennik na podany adres e-mail. Aby określić rozmiar pliku, po osiągnięciu którego ma nastąpić jego wysłanie, należy wpisać tutaj odpowiednią wartość w bajtach (przedział od 2048 do 125000). Aby zrezygnować z tej opcji, wpisujemy "0".

9. Discard settings and exit - wyjście bez zapisania konfiguracji.

0. Save settings and exit - wyjście z zapisaniem konfiguracji.

Przykładowe ustawienia pliku .ini:

[parameters]
id=ajus79@box43.pl	- adres e-mail na który przeliczamy bloki
[buffers]
checkpoint-filename=chkpoint.r72	- nazwa pliku służącego do zapisywania informacji o postępie w pracach klienta
[misc]
project-priority=RC5-72,OGR=0	- w jakich projektach mamy zamiar uczestniczyć? (wartość "=0" oznacza, że danym projektem się nie zajmujemy)
[display]
progress-indicator=relative	- rodzaj wskaźnika postępu (patrz punkt 1.10) konfiguracji)
[networking]
disabled=yes	- wartość "yes" w przypadku aktualizowania buforów drogą mailową (punkt 4.3. niniejszego artykułu), wartość "no" w przypadku aktualizacji automatycznych (punkt 4.1. i 4.2.)
[rc5-72]
core=-1	- rodzaj algorytmu przeliczającego ("-1" - wybór automatyczny)

W jaki sposób pobierać i odsyłać przeliczone bloki na serwer oraz: "Popatrz, ile przeliczyłem!", czyli jak ujrzeć swoje statystyki na stronie distributed.net. :-)

Aby dołączyć do projektu i tym samym móc oglądać swoje statystyki na stronie distributed.net, należy pobrać z serwera co najmniej 1 blok, przeliczyć go i odesłać z powrotem. W jaki sposób tego dokonać? Są 3 powszechnie stosowane metody, przy wykorzystaniu których zmienia się nieznacznie konfiguracja klienta:
1. Wykorzystując stałe połączenie z internetem,
2. Wykorzystując połączenie modemowe,
3. Za pomocą e-maili.

Wykorzystując stałe połączenie z internetem
Jeżeli nie zmienialiśmy nic w pierwotnej konfiguracji klienta w punkcie "2) Buffer and Buffer Update Options" (należy jednak na pewno podać swój adres e-mail na który będziemy przeliczać bloki - punkt 1.1) konfiguracji), spróbuje on automatycznie połączyć się z odpowiednim serwerem, pobrać bloki do przeliczenia, i po skończonej pracy odesłać je z powrotem (pobierane są w tym momencie od razu następne). Nie musimy się tutaj o nic martwić - wszystko przebiega automatycznie.

Wykorzystując połączenie modemowe
Tutaj sytuacja jest bardzo podobna do opisanej w punkcie wyżej. Należy jednak pamiętać, że lepiej jest wtedy przełączyć opcję "Connection Mode" z 'Online Always' na 'Modem Dialup Lurk', lub 'Modem Dialup Lurk-Only'. 'Modem Dialup Lurk' pozwoli klientowi na samoczynne połączenie z internetem w razie potrzeby, natomiast 'Modem Dialup Lurk-Only' zmusi go do sprawdzenia najpierw czy jesteśmy połączeni, i dopiero wtedy wysłania i pobrania bloków. Druga możliwość jest przydatna dla tych osób, które nie chcą, aby program łączył się z serwerem bez ich wiedzy.

Za pomocą e-maili.
Przydatna dla osób nie mających możliwości wykorzystania powyższych dwóch metod lub chcą mieć całkowitą kontrolę nad ilością przeliczanych bloków i czasem ich wysyłania/pobierania.
Postępujemy według schematu:

• wysyłamy maila na adres fetch@distributed.net, wpisując w jego treści:
  blocksize=[cyfra między 28 a 33]
  numblocks=[cyfra między 1 a 500]
  contest=RC5
  UWAGA! Ostrożnie z wpisywaniem wartości parametru 'numblocks'! Przeliczanie jednego bloku na procesorze PPC 603e 210 MHz trwa około 1,5 godziny. W momencie gdybyśmy "zamówili", dajmy na to 128 bloków, musielibyśmy czekać około 200 godzin aż wszystko się przeliczy. Z reguły wartości rzędu 10 - 20 są optymalne, no chyba że ktoś chce załączyć klienta na cały tydzień non-stop - wtedy 100 będzie w sam raz. :-) Pamiętajmy także o mocy swojego procesora. Najlepiej za pierwszym razem wysłać żądanie o 1 blok i sprawdzić ile czasu zajmie jego przeliczenie. Można wtedy lepiej zaplanować sobie przyszłe "zamówienia";
• po kilku chwilach powinniśmy dostać maila z załącznikiem o nazwie 'buff-in.r72';
• załącznik zapisujemy do katalogu z klientem RC5;
• uruchamiamy klienta i czekamy, aż przeliczy wszystkie bloki. Fakt że to nastąpiło można poznać po pojawieniu się w oknie programu komunikatu: 'RC5-72: x packet (x.00 stats units) is in buff-out.r72', gdzie "x" oznacza liczbę zamawianych przez nas bloków. Pojawi się też komunikat: 'RC5-72: Loaded random...'. Chodzi tu o to, że klient zakończył pracę nad ściągniętymi przez nas blokami i teraz przelicza losowo wybrany pakiet.
• przerywamy pracę klienta (np. przyciskiem zamykającym okno); w katalogu pojawi nam się plik o nazwie 'buff-out.r72'
• wysyłamy maila na adres flush@distributed.net z 'buff-out.r72' w załączniku. W niedługim czasie otrzymamy potwierdzenie z serwera, świadczące o przyjęciu przeliczonych bloków.

W tym momencie możemy powtórzyć cały powyższy zestaw czynności, pamiętając aby przed przyjęciem nowych bloków skasować z katalogu z klientem pliki 'buff-out.r72' i 'chkpoint.r72'.

Wracając do kwestii ujrzenia statystyk na stronie distributed.net: Po wysłaniu swoich pierwszych bloków należy odczekać do następnego dnia (statystyki są aktualizowane o północy), a następnie wejść na stronę projektu, gdzie w środkowej wyszukiwarce wpisać adres e-mail na który liczymy bloki (podany przy konfiguracji klienta). Naszym oczom ukażą się statystyki w całej krasie. :-) Następnie klikamy u dołu strony na przycisk "Please email me my password" - otrzymamy wtedy list zawierający osobiste hasło. Pozwoli nam to na edycję swoich danych oraz na ewentualne zapisanie się do jakiejś drużyny.

RC5 Team Amiga Effort - co zrobić, żeby dołączyć do szlachetnego grona?

Po ujrzeniu własnych statystyk, przechodzimy na stronę projektu i wpisujemy w wyszukiwarkę po prawej stronie "The Amiga RC5 Team effort". Po wyświetleniu statystyk, klikamy na odnośnik "Join our team" lub na samym dole na "I want to join this team!" i niebawem możemy cieszyć się członkostwem.

Kalendarium. Najważniejsze wydarzenia w distributed.net.

28 stycznia 1997
Rozpoczyna się RC5-32/12/7 (56-bit) Secret Key Challenge.

Marzec 1997
Organizacja, która w przyszłości stanie się distributed.net, rozpoczyna w kooperacji z genx.net prace nad rozkodowaniem RC5. Pierwszego dnia zostaje przeliczonych 9128 bloków, z prędkością 28,36 milionów kluczy na sekundę (Mkeys/s). Przewidywany czas do całkowitego złamania kodu przy obecnym tempie: 80,6 roku.

18 marca 1997
serwer genx.net ostatecznie zaprzestaje działalności

24 marca 1997
Pierwsza sieć pięciu serwerów 'distributed.net', przydzielających klucze i śledzących już wykonaną pracę, zostaje udostępniona dla ogółu.

Kwiecień 1997
Kilkoro z osób nadzorujących pracę serwerów rozpoczyna tworzenie własnej bazy danych statystyk. Nie są dostępne statystyki globalne.

17 kwietnia 1997
Dzienne tempo przeliczania RC5-56 po raz pierwszy przekracza 100 Mk/s. Obecny status projektu: wykonano: 0,1%, przewidywany czas do całkowitego złamania kodu przy obecnym tempie: 22,1 roku.

8 maja 1997
domena distributed.net zostaje zarejestrowana w InterNIC i rozpoczyna działalność. Dostępne są ogólne statystyki projektu.

18 maja 1997
Status projektu RC5-56: wykonano: 1,03% ze średnią prędkością 370,25 Mk/s, przewidywany czas całkowitego złamania kodu przy obecnym tempie: 6,1 roku.

8 czerwca 1997
Status projektu RC5-56: wykonano: 2,03% ze średnią prędkością 420,35 Mk/s, przewidywany czas całkowitego złamania kodu przy obecnym tempie: 5,3 roku.

17 czerwca 1997
DES I zostaje złamany przez Rocke Verser's Deschall effort.

19 czerwca 1997
Tempo przeliczania RC5-56 po raz pierwszy przekracza 500 Mk/s.

25 czerwca 1997
Dzienne tempo przeliczania RC5-56 przekracza 1 Gk/s. Status projektu RC5-56: wykonano: 3,25%, przewidywany czas całkowitego złamania kodu przy obecnym tempie: 2,1 roku.

14 lipca 1997
Status projektu RC5-56: wykonano: 5,13% ze średnią prędkością 1261 Mk/s, przewidywany czas całkowitego złamania kodu przy obecnym tempie: 1,7 roku.

23 lipca 1997
Dzienne tempo przeliczania RC5-56 po raz pierwszy przekracza 2 Gk/s, status projektu: 6.97% ogólnej liczby kluczy zostało sprawdzone.

3 sierpnia 1997
Status projektu RC5-56: wykonano: 10,06% ze średnią prędkością 2,477 Gk/s, przewidywany czas całkowitego złamania kodu przy obecnym tempie: 10 miesięcy.

16 sierpnia 1997
Przekroczono liczbę 3 Gigakluczy na sekundę jako średnie dzienne tempo przeliczania RC5-56, wykonano 14.13%.

21 września 1997
Status projektu RC5-56: wykonano: 30,29% ze średnią prędkością 4,6 Gk/s, przewidywany czas całkowitego złamania kodu przy obecnym tempie: 125 dni.

22 października 1997
Zakończono RC5-56. Właściwy klucz znaleziono po 212 dniach pracy. Sprawdzono 47.03% ogólnej liczby kluczy ze średnią prędkością 5.3 Gk/s. Przewidywany czas sprawdzenia całkowitej liczby kluczy w tym tempie: 83 dni.
Rozpoczęto RC5-64. Pierwszego dnia sprawdzono 152779 bloków ze średnią prędkością 475 Mk/s. Przewidywany czas całkowitego złamania kodu w tym tempie: 1235 lat.

13 listopada 1997
Status projektu RC5-64: wykonano: 0,017% ze średnią prędkością 5 Gk/s, przewidywany czas całkowitego złamania kodu przy obecnym tempie: 104,5 roku.

16 listopada 1997
Baza danych statystyk została przeniesiona na Best.net.

28 listopada 1997
Status projektu RC5-64: wykonano: 0,10% ze średnią prędkością 8,4 Gk/s, przewidywany czas całkowitego złamania kodu przy obecnym tempie: 69,5 roku.

1 grudnia 1997
Project Gutenberg otrzymuje 8000 dolarów nagrody za odnalezienie właściwego klucza w projekcie RC5-56.

4 grudnia 1997
Średnie dzienne tempo przeliczania RC5-64 przekracza 10 Gk/s, status projektu: wykonano 0,127%, przewidywany czas całkowitego złamania kodu przy obecnym tempie: 57 lat.

18 grudnia 1997
Distributed.net ogłasza chęć uczestniczenia w konkursie DES-II-1.

23 lutego 1998
Zakończono DES-II-1. Sprawdzono 88.4% ogólnej liczby kluczy ze średnią dzienną prędkością 28.1 Gk/s.

5 marca 1998
Status projektu RC5-64: wykonano: 0,50% ze średnią prędkością 11,7 Gk/s, przewidywany czas całkowitego złamania kodu przy obecnym tempie: 49,9 roku.

19 maja 1998
Status projektu RC5-64: wykonano: 1,00% ze średnią prędkością 17,0 Gk/s, przewidywany czas całkowitego złamania kodu przy obecnym tempie: 34,1 roku.

10 lipca 1998
Został sprawdzony miliardowy blok RC5-64.

11 lipca 1998
Rozpoczyna działalność nowy serwer rozdzielający klucze (keymaster). Jest to maszyna wyposażona w procesor K6-300 MHz, 128 MB SDRAM, dyski 4,5 GB UWSCSI, 1,2 GB UWSCSI, 6,4 GB IDE, działająca pod kontrolą FreeBSD 2.2.6-STABLE. Serwer uruchomił się i przydzielał klucze bez zawieszenia się, lub potrzeby restartu, przez prawie 200 dni.

13 lipca 1998
Rozpoczyna się DES-II-2.

17 lipca 1998
Koniec DES-II-2. Właściwy klucz zostaje znaleziony przez Electronic Frontier Foundation, używającą sprzętu wartego 250 tysięcy dolarów.

29 lipca 1998
Rozpoczyna się konkurs na nowe logo distributed.net.

3 sierpnia 1998
Status projektu RC5-64: wykonano: 1,78% ze średnią prędkością 30 Gk/s, przewidywany czas całkowitego złamania kodu przy obecnym tempie: 18,5 roku.

9 września 1998
Statystyki zaczęły być dostępne przez dedykowane zasoby za pośrednictwem http.

14 września 1998
Oficjalnie ogłaszamy OGR jako nasze następne współzawodnictwo. Rayden242 został zwycięzcą konkursu na nowe logo.

30 listopada 1998
Średnie dzienne tempo przeliczania RC5-64 przekracza 50 Gk/s. Status projektu: wykonano: 1,78%, przewidywany czas całkowitego złamania kodu przy obecnym tempie: 11,08 roku.

8 stycznia 1999
Serwer Keymaster działa bez ustanku ponad pół roku, jednak zostaje wyłączony z powodu wymiany dysku do zapisu dziennika (1 GB UWCSCI -> 9 GB UWSCSI) i dodania kolejnych 128 MB pamięci.

18 stycznia 1999
Laboratoria RSA ogłaszają trzecią edycję konkursu DES (DES Challenge III).

19 stycznia 1999
Distributed.net i EFF rozwiązują konkurs DES-III w rekordowym czasie 22 godzin, 15 minut, 4 sekund.

15 kwietnia 1999
Został sprawdzony 5 miliardowy blok.

6 czerwca 1999
Status projektu RC5-64: wykonano: 10,03% ze średnią prędkością 73,92 Gk/s, przewidywany czas całkowitego złamania kodu przy obecnym tempie: 7,13 roku.

27 września 1999
Dzienne średnie tempo przeliczania RC5-64 przekracza 100 Gk/s, Status projektu: wykonano: 13,20%, przewidywany czas całkowitego złamania kodu przy obecnym tempie: 4,93 roku.

27 października 1999
Został sprawdzony 10 miliardowy blok.

17 listopada 1999
Rozpoczęto konkurs CSC. Pierwszego dnia przeliczono 382650 bloków, czyli 0,14% ogólnej liczby kluczy, ze średnim tempem 1,2 Gk/s.

27 listopada 1999
Dzienne tempo przeliczania CSC przekracza 10 Gk/s, status projektu: wykonano 9,75%, przewidywany czas do przeliczenia wszystkich kluczy: 75 dni.

5 grudnia 1999
Status projektu CSC: wykonano: 21,53% ze średnią prędkością 12,8 Gk/s, przewidywany czas do przeliczenia wszystkich kluczy: 51 dni.

15 stycznia 2000
Zakończono konkurs CSC.

15 lutego 2000
Rozpoczęto konkurs OGR-24, jednak zostaje on później zawieszony z powodu nieprzewidzianych problemów.

28 maja 2000
W RC5-64 przeliczono 25% wszystkich kluczy!

13 lipca 2000
Ponownie uruchomiono OGR-24.

1 sierpnia 2000
Pierwszy przebieg OGR-24 został zakończony. Rozpoczęto dystrybucję OGR-25. Drugi, weryfikacyjny przebieg OGR-24 przeprowadzany jest stopniowo równolegle z pierwszym przebiegiem OGR-25.

27 listopada 2000
Distributed.net ogłasza partnerstwo z United Devices.

1 grudnia 2001
Projekt RC5-64 w distributed.net trwa już od 1500 dni. W tym czasie 63% ogólnej liczby kluczy zostało sprawdzone przez ponad 310 tysięcy uczestniczących adresów e-mail.

14 lipca 2002
Po 1757 dniach poszukiwań odnaleziono klucz numer 0x63DE7DC154F4D039, który okazał się być zwycięzcą w konkursie RSA RC5-64. Właściwy klucz został zwrócony przez komputer z Japonii.

3 grudnia 2002
Oficjalnie rozpoczęto RC5-72. Nowa wersja klienta (v2.9001) jest dostępna.