Polityka bezpieczeństwa

Herkos przetwarza klucze prywatne i zaszyfrowane wiadomości, dlatego poważnie traktujemy zgłoszenia dotyczące bezpieczeństwa i wolimy dowiedzieć się o problemie wcześniej niż później.

Zgłaszanie podatności

Prosimy nie otwierać publicznego zgłoszenia (issue) w sprawie problemów z bezpieczeństwem.

Zgłoś je prywatnie e-mailem na security@herkos.email.

Warto podać: na czym polega problem, jak go odtworzyć, na jakiej platformie i wersji go testowałeś oraz co mógłby osiągnąć atakujący. Dowód koncepcji (proof of concept) bardzo pomaga.

Nigdy nie umieszczaj w zgłoszeniu swojego nsec, klucza prywatnego ani sekretu bunkera.

Staramy się potwierdzać zgłoszenia w ciągu kilku dni. Ponieważ Herkos jest małym projektem, daj nam rozsądny czas na poprawkę przed publicznym ujawnieniem. Chętnie wymienimy Cię w komunikacie bezpieczeństwa, chyba że wolisz inaczej.

Co obejmuje ta polityka

Samą aplikację Herkos: obsługę i przechowywanie kluczy, szyfrowanie i odszyfrowywanie wiadomości (w tym weryfikację nadawcy NIP-59 i izolację Bcc w local_packages/nostr_mail), blokadę aplikacji, komunikację z relayami i bridge'ami, obsługę załączników oraz proces budowania i wydawania. W przypadku Herkos Drive także jego pakiet protokołu (packages/herkos_drive_protocol) i strona, która otwiera jego linki (herkos.app/f/); zob. jego własną sekcję niżej.

Czego nie obejmuje

• Samego protokołu Nostr i jego NIP-ów — zgłaszaj to ich twórcom.
• Relayów, bridge'y i serwerów Blossom prowadzonych przez osoby trzecie. Herkos ma je w ustawieniach domyślnych, ale ich nie prowadzi; zgłaszaj problemy ich operatorom.
• Projektu macierzystego Nostr Mail Client, chyba że problem dotyczy zmian wprowadzonych w Herkos.
• Brakujących zabezpieczeń, które już dokumentujemy jako znane ograniczenie (zob. niżej).

Znane ograniczenia, powiedziane wprost

To kompromisy projektowe, a nie podatności. Wolimy je zapisać, niż żeby ktoś odkrył je w bolesny sposób:

• Poczta na tradycyjne adresy nie jest szyfrowana end-to-end. Wiadomości między użytkownikami Nostr używają gift wrap NIP-17 i są szyfrowane E2E. Gdy piszesz na zwykły adres e-mail, bridge konwertuje wiadomość i może ją przeczytać.
• Blokada aplikacji (PIN i biometria) to bariera wygody, a nie szyfrowanie danych w spoczynku. Zatrzymuje kogoś, kto podniesie odblokowane urządzenie; nie chroni przed atakującym z pełnym dostępem do urządzenia lub jego pamięci.
• W systemie Windows nie da się wymusić uwierzytelniania wyłącznie biometrią. Windows Hello nie pozwala wybrać metody, więc systemowy PIN zawsze pozostaje dostępny jako rozwiązanie zapasowe.
• Utrata klucza oznacza utratę konta. Z założenia nie ma odzyskiwania.
• Metadane nie są w pełni ukryte. Relaye mogą obserwować wzorce połączeń, a każdy relay widzi Twój adres IP, nawet gdy nie może odczytać treści wiadomości. Czego Herkos nie zdradza (od 30-09-2026), to kto pisze do kogo, gdy relay żąda uwierzytelnienia NIP-42:
• Ustalanie, gdzie doręczyć. O listy relayów i serwerów Blossom odbiorcy pytamy przez osobne połączenie, które nigdy Cię nie identyfikuje, najpierw na relayach niewymagających uwierzytelnienia (purplepag.es, user.kindpag.es, nos.lol, offchain.pub).
• Profile i harmonogram. O nazwę i zdjęcie wyświetlane dla innych osób (kind 0) oraz o listę relayów DVM harmonogramu, gdy planujesz lub anulujesz e-mail, pytamy w ten sam sposób: najpierw anonimowo, a jeśli relay nalega, z tymczasowym kluczem opisanym niżej, nigdy z Twoim (od 01-10-2026; wcześniej relay żądający uwierzytelnienia dostawał Twój klucz i mógł stwierdzić, czyj profil oglądasz). Tylko Twój własny profil jest nadal odczytywany jako Ty.
• Doręczanie. Gift wrapy trafiają do relayów DM odbiorcy, przez to samo osobne połączenie. Jeśli któryś z nich wymaga uwierzytelnienia, Herkos odpowiada kluczem utworzonym w tym celu i przechowywanym wyłącznie w pamięci, nigdy Twoim; każde konto na urządzeniu ma własny. Relay nadal może zobaczyć, że to samo urządzenie (ten sam IP, ten sam tymczasowy klucz) wysłało kilka kopert w trakcie sesji.
• Duże e-maile. Zaszyfrowana kopia e-maila większego niż 32 KB jest przesyłana na serwery Blossom, także odbiorców. Tylko Twoje własne serwery (Twoja lista Blossom) otrzymują przesyłanie autoryzowane Twoim kluczem. Każdy inny serwer otrzymuje je anonimowo, a jeśli nalega na autoryzację — podpisaną tym samym tymczasowym kluczem co wyżej (od 01-10-2026; wcześniej każdy serwer dostawał Twój klucz). Serwer, który przyjmuje tylko znane klucze, odmawia, a kopia zostaje na pozostałych serwerach.
• Twoje własne dane. Synchronizacja skrzynki, etykiet, ustawień i wersji roboczych uwierzytelnia się, gdy relay tego żąda, jako konto, do którego dane należą, nawet podczas przełączania kont. Twoim własnym relayom nie mówi to nic, czego by nie wiedziały: żądania i tak zawierają Twój klucz. Twoje własne listy relayów i serwerów Blossom są publiczne i pobierane bez identyfikowania Cię, podobnie jak relaye wskazane w linku w e-mailu.
• Stan przeczytania i foldery są publicznymi metadanymi (na razie). Oznaczenie e-maila jako przeczytanego, z gwiazdką, zarchiwizowanego lub przeniesionego publikuje niezaszyfrowane zdarzenie etykiety NIP-32 powiązane z Twoim kluczem publicznym, łącznie z nazwami folderów własnych. Nadawca, który zna identyfikator wysłanego Ci e-maila, może stwierdzić, kiedy coś z nim zrobiłeś. Szyfrowanie tych etykiet jest planowane; do tego czasu traktuj nazwy folderów jako publiczne.
• Powiadomienia push i wysyłanie zaplanowane korzystają z usług osób trzecich. Serwer push, jeśli go wybierzesz (domyślnie żaden; api.nmail.li z relay.nmail.li na życzenie), poznaje Twój klucz publiczny, token push i to, kiedy otrzymujesz pocztę; DVM harmonogramu poznaje Twój klucz publiczny i już zaszyfrowane wiadomości, które ma opublikować. Obie funkcje są opcjonalne i opisane w PRIVACY.md. Tekst powiadomienia push wybiera serwer push, a Herkos ufa mu tylko wtedy, gdy UnifiedPush dostarcza go zaszyfrowanego (RFC 8291); niezaszyfrowany ładunek jedynie budzi aplikację, aby sama pobrała pocztę.
• Wersja webowa przechowuje Twój klucz w przeglądarce, która jest dla niego najsłabszym miejscem. Zainstalowane aplikacje przekazują Twój klucz prywatny do bezpiecznego magazynu systemu operacyjnego (Android Keystore, DPAPI w systemie Windows, libsecret, pęk kluczy iOS/macOS). Przeglądarka nie ma nic takiego: klucz leży w magazynie danego pochodzenia (origin) i przy każdym podpisie przechodzi przez JavaScript, w zasięgu każdego kodu działającego na stronie — rozszerzenia przeglądarki z dostępem do wszystkich stron, błędu XSS w aplikacji lub w zależności, zmanipulowanego wdrożenia — oraz każdego infostealera, który kopiuje profil przeglądarki. Nie ma też momentu, w którym weryfikujesz kod raz: podpisany plik binarny jest sprawdzany przy instalacji, a strona internetowa przy każdej wizycie dostarcza nowy kod. Loguj się do wersji webowej zdalnym podpisującym (bunker NIP-46, Amber), aby klucz nigdy nie trafił do przeglądarki, albo traktuj ją jako tożsamość jednorazową, a swój prawdziwy klucz trzymaj w zainstalowanej aplikacji.
• Poczta przez bridge jest tak wiarygodna jak sam bridge. Herkos sprawdza, czy wiadomość oznaczona jako przechodząca przez bridge rzeczywiście została podpisana przez skonfigurowany przez Ciebie bridge (lub jeden z domyślnych). Nie może zweryfikować niczego w tradycyjnym adresie From:, który bridge przekazuje.
• Załączniki otwiera system operacyjny. Herkos nigdy nie uruchamia plików wykonywalnych ani skryptów i pyta, zanim przekaże każdy inny załącznik bez podglądu do domyślnej aplikacji systemu, ale aplikacja, która otwiera plik, jest poza naszą kontrolą.

Herkos Local Relay: co chroni, a czego nie

Herkos Local Relay przechowuje na Twoim urządzeniu zdarzenia Twoich aplikacji, również prywatne (szkice, prywatne listy, koperty, które otrzymujesz). Oto, co je chroni i gdzie leży granica, platforma po platformie. Problemy z bezpieczeństwem relaya zgłaszaj tak samo jak wszystkie inne (wyżej).

Cała baza danych jest zaszyfrowana, łącznie z dziennikiem transakcji (SQLite3 Multiple Ciphers, AEGIS-256). Klucz to 32 losowe bajty utworzone na urządzeniu i trzymane w bezpiecznym magazynie systemu: Keystore w Androidzie, DPAPI w systemie Windows, pęk kluczy (libsecret) w systemie Linux. Nie chroni go żadne Twoje hasło, bo relay musi uruchamiać się sam. Bez klucza relay się nie uruchamia i mówi o tym: nigdy nie otwiera ani nie tworzy niezaszyfrowanej bazy i nigdy nie usuwa takiej, której nie może otworzyć.

Na komputerze granica DPAPI i pęku kluczy jest taka sama jak w przypadku każdego programu: chronią przed innymi użytkownikami i przed tym, kto zabierze dysk, ale nie przed złośliwym programem, który już działa jako Twój użytkownik. Jeśli niepokoi Cię ten przypadek, chroni Cię szyfrowanie dysku systemowego (BitLocker, LUKS) i nieuruchamianie programów, którym nie ufasz. W systemie Linux bez pęku kluczy (bez Secret Service) relay się nie uruchamia i wyjaśnia dlaczego: nigdy nie trzyma klucza w postaci jawnej.

Kto wchodzi, na samym urządzeniu. Relay nasłuchuje tylko na 127.0.0.1, a do tego adresu może dotrzeć każda aplikacja na urządzeniu albo strona internetowa w przeglądarce. Dlatego:

• Aplikacja musi się sparować: pojawia się na ekranie relaya, a Ty ją zatwierdzasz (PIN-em lub odciskiem palca, jeśli je ustawiłeś). Każda aplikacja może nadać sobie dowolną nazwę: zatwierdzaj tylko, jeśli przed chwilą poprosiłeś o to z tej aplikacji.
• Strona internetowa zawsze się paruje, a parowanie działa tylko stamtąd, gdzie zostało wykonane: parowanie aplikacji na urządzeniu nie otwiera niczego stronie internetowej, nawet takiej, która podpisuje tym samym kluczem.
• Sparowana aplikacja czyta i zapisuje tylko te rodzaje zdarzeń, które jej dałeś, i usuwa tylko te, które może zapisywać. Cofnięcie parowania natychmiast ją rozłącza.
• Niesparowana aplikacja czyta tylko Twoje zdarzenia publiczne (które i tak są publiczne) i niczego nie zapisuje, chyba że włączysz ustawienie, które wpuszcza niesparowane aplikacje z urządzenia.
• Zdarzenia prywatne trafiają tylko do tego, kto udowodni przez NIP-42, że ma klucz, do którego należą, a koperta tylko do swojego adresata.

Czego tu nie chroni:

• Złośliwa aplikacja na urządzeniu może spowolnić relay albo zmusić go do zużywania pamięci. Nie może w ten sposób odczytać niczego prywatnego.
• Gdy relay śpi albo nie działa, jego port jest wolny. W Androidzie zasypia po 10 minutach bez połączeń; na komputerze port jest wolny, dopóki go nie uruchomisz. Inna aplikacja mogłaby tam nasłuchiwać i podawać się za relay. Aplikacje Herkos będą sprawdzać klucz relaya przed wysłaniem mu czegokolwiek prywatnego; jeszcze tego nie robią i do tego czasu jest to realna granica.
• Na komputerze inni użytkownicy tego komputera mogą połączyć się jako niesparowana aplikacja: czytać Twoje zdarzenia publiczne i prosić o sparowanie.

Sieć lokalna, jeśli ją włączysz (domyślnie jest wyłączona):

• Tylko wss://, z własnym certyfikatem relaya; poza urządzeniem nigdy niezaszyfrowane ws://.
• Nic przed uwierzytelnieniem (NIP-42) kluczem z Twojej listy. Połączenie, które nie zrobi tego w ciągu 30 sekund, zostaje zamknięte, a sieć lokalna ma własną pulę połączeń: nigdy nie zajmuje tych, które należą do aplikacji na urządzeniu.
• Klucz z listy czyta Twoje zdarzenia publiczne i własne zdarzenia prywatne i zapisuje tylko zdarzenia, które sam podpisał. Usunięcie go z listy go rozłącza.
• Certyfikat jest ważny tylko dla nazw domowych (localhost, .local, adresy prywatne): nawet gdyby ktoś ukradł jego klucz, nie przydałby mu się do podpisania domeny internetowej na urządzeniach, które go zainstalowały.

Czego tu nie chroni: każdy w tej samej sieci widzi, że urządzenie ma otwarty port i ile ruchu przez niego przechodzi, choć nie co; a jeśli urządzenie ma adres publiczny (bez routera pośrodku), ten port widać z internetu, choć nadal wymaga klucza z Twojej listy.

Kopie. Zaszyfrowana kopia ma hasło (scrypt i XChaCha20-Poly1305): bez niego nikt jej nie otworzy, nawet my. Eksport JSONL nie jest zaszyfrowany i zawiera Twoje zdarzenia prywatne w postaci jawnej; aplikacja o tym uprzedza.

Blokada (PIN oraz odcisk palca lub Windows Hello) jest wymagana przy otwieraniu aplikacji, po 30 sekundach poza nią i do zatwierdzenia parowania. To bariera wygody, jak w Mail: niczego nie szyfruje. W Androidzie przy ustawionym PIN-ie nie ma zrzutów ekranu ani miniatury wśród ostatnich aplikacji, a od Androida 12 żadne okno innej aplikacji nie może znaleźć się nad oknem relaya, gdy go używasz.

Herkos Drive: co chroni, a czego nie

Herkos Drive przechowuje Twoje pliki na serwerach Blossom, a listę Twoich plików i folderów na relayach Nostr, w obu przypadkach zaszyfrowane na Twoim urządzeniu. Oto, co je chroni i gdzie są granice. Pełne szczegóły są w spec-drive.md i w modelu zagrożeń amenazas-drive.md, w packages/herkos_drive_protocol/; to, co widzi każdy relay i serwer, opisuje polityka prywatności. Problemy bezpieczeństwa Drive zgłaszaj tak samo jak wszystkie inne (wyżej).

Czego relaye i serwery nie mogą zrobić:

• Odczytać Twoich plików ani ich nazw. Każdy blok pliku jest szyfrowany AES-256-GCM kluczem własnym dla swojej rewizji; nazwy, foldery, rozmiary, daty i klucze są pieczętowane XChaCha20-Poly1305 kluczem folderu, w którym się znajdują. Nic nie jest wyprowadzane z treści: ten sam plik przesłany dwa razy daje różne bloki.
• Niepostrzeżenie zmienić, podmienić ani przenieść czegokolwiek. Każdy blok jest sprawdzany względem manifestu zapieczętowanego we wpisie jego pliku, a każdy wpis jest podpisany kluczem woluminu i zapieczętowany dla swojego miejsca (wolumin, identyfikator i folder): relay nie może podać jednego wpisu za inny ani jednego bloku za inny.
• Przywrócić starej wersji. Aplikacja nigdy nie przyjmuje wpisu starszego niż ten, który już ma dla tego samego identyfikatora.
• Pisać jako Ty, mając tylko klucz woluminu. To, co zapisują Twoje urządzenia, nosi znak właściciela, HMAC z kluczem, którego nie daje żaden link; wpis lub usunięcie bez niego nie jest przyjmowane, a aplikacja Cię ostrzega.

Czego nie chroni:

• Wzorca Twojego Drive. Relaye mogą policzyć Twoje pliki i foldery, zobaczyć kształt drzewa i to, kiedy zmienia się każdy wpis; serwery widzą mniej więcej rozmiar każdego pliku (bloki są dopełniane do 64 KiB, wpisy do potęgi dwójki). Każdy relay i serwer widzi Twój adres IP. Jeśli to dla Ciebie ważne, używaj Tora lub Orbota na poziomie systemu.
• Tego, co ktoś już pobrał. Usunięcie linku albo osoby od razu daje nowe klucze temu, co mogła otworzyć, więc nie otworzy tego, co dodasz później; nie da się jednak odebrać tego, co już zapisała.
• Wycieku linku. Link bez hasła jest kluczem. Przeglądarka może zapisać go w historii, zanim strona usunie go z paska adresu. W przypadku czegokolwiek wrażliwego nadaj linkowi hasło, przekazane innym kanałem, albo udostępnij kontu danej osoby. Słabe hasło można z czasem złamać: kto ma link, może próbować offline.
• Strony herkos.app/f/, która działa w przeglądarce osoby otwierającej link. Jest serwowana ze ścisłą Content-Security-Policy, Subresource Integrity i bez kodu stron trzecich, ale ten, kto kontroluje hosting, mógłby podać inną stronę. To granica każdej strony internetowej, która odszyfrowuje w przeglądarce.
• Kto miał klucz woluminu (Twój albo przekazany z linkiem do folderu), nadal może usunąć bloki, które przesłano z jego użyciem, dopóki nie zostaną przesłane ponownie. Możesz zmienić klucz woluminu (Ustawienia → Klucz woluminu): Twoje pozostałe urządzenia same za tym nadążają.
• Twojego urządzenia. Lista plików jest przechowywana w pamięci podręcznej zaszyfrowana, z kluczem w bezpiecznym magazynie systemu; plik, który pobierasz lub otwierasz, jest zapisywany bez szyfrowania tam, gdzie wybierzesz. PIN w Drive to bariera dla wygody, jak w Mail.
• Komputera kwantowego w przyszłości. Bloki i pieczęcie są symetryczne (AES-256, XChaCha20), ale Twój lokalizator jest szyfrowany NIP-44 na secp256k1: ktoś, kto zachowa go dziś i złamie secp256k1 jutro, mógłby otworzyć cały Drive.

Jak to jest sprawdzane. Dwa wewnętrzne przeglądy pod kątem modelu zagrożeń (2 listopada 2026) i ich poprawki; testy tego, co pokazuje każde zdarzenie i blok; fuzzing każdego czytnika tego, co przychodzi z zewnątrz (zdarzenia, pieczęcie, manifesty, linki, kopie zapasowe). Jeszcze bez zewnętrznego audytu: jeden jest planowany przed publiczną betą, a jego raport zostanie opublikowany w całości. Drive jest wciąż w fazie rozwoju.

Wspierane wersje

Poprawki bezpieczeństwa trafiają do najnowszej wydanej wersji. Ze względu na rozmiar projektu starsze wersje nie są utrzymywane — przed zgłoszeniem zaktualizuj aplikację.