Szyfrowanie nad MAX: AES-256 dla Android/iOS

Szyfrowanie krzyżowe na wierzchu komunikatorów: implementacja na iOS i Android

W sytuacji, gdy dostępne są tylko komunikatory z białej listy bez szyfrowania end-to-end, potrzebna jest warstwa ochrony na istniejącym transporcie. Dark Message implementuje szyfrowanie offline wiadomości, plików i dokumentów przy użyciu AES-256-GCM. Zaszyfrowana treść jest kopiowana do dowolnego kanału transmisji — MAX, e-mail lub SMS — bez dostępu do oryginalnych danych na urządzeniu nadawcy lub odbiorcy.

Aplikacja działa bez uprawnień sieciowych, szyfrując dane lokalnie. Odbiorca odszyfrowuje za pomocą wspólnego hasła, zapewniając kompatybilność między Androidem, iOS i Windows.

Architektura i kryptografia

Szyfrowanie symetryczne opiera się na AES-256-GCM dla poufności i uwierzytelnienia. Pochodzenie klucza — PBKDF2-HMAC-SHA512 z 600 000 iteracjami i losową solą. Format zaszyfrowanego pakietu: [wersja:1B][typTreści:1B][sól:16B][nonce:12B][szyfrogram+tag_GCM:NB]. Gwarantuje to unikalność szyfrogramu nawet dla identycznych danych wejściowych z tym samym hasłem.

Obsługiwane typy:

• Wiadomości tekstowe (wynik — ciąg Base64).
• Obrazy i pliki (wynik — .darkm).
• Dokumenty dowolnych formatów (PDF, DOCX, XLSX, ZIP).

Rozwój z AI: od architektury do debugowania

Claude był używany do generowania kodu, struktury i analizy błędów. AI proponowało architekturę, pisało szkice, pomagało w porównywaniu bajtów podczas testów krzyżowych. Ostateczne testowanie i poprawki były wykonywane ręcznie na rzeczywistych urządzeniach.

Proces:

• Opis zadania — propozycja struktury.
• Generowanie kodu — testowanie lokalne.
• Debugowanie niezgodności (bajty, klucze).
• Testowanie na Pythonie dla weryfikacji.

AI przyspieszyło rozwój, zastępując zespół międzyplatformowy, ale nie wyeliminowało potrzeby walidacji na sprzęcie.

CI/CD bez Maca: GitHub Actions dla iOS

Kompilacja iOS odbywa się na wirtualnym macOS w GitHub Actions. Pipeline używa XcodeGen do generowania projektu z YAML, unikając przechowywania .xcodeproj w repozytorium. Automatyczne podpisywanie i przesyłanie do App Store Connect.

Etapy pipeline'u:

• Klonowanie repozytorium.
• Generowanie projektu Xcode.
• Kompilacja i archiwizacja.
• Przesyłanie do TestFlight (15 minut od commita).

Android jest kompilowany lokalnie przez Gradle (APK/AAB). Zapewnia to rozwój krzyżowy na Windows.

Problemy krzyżowe i rozwiązania

Zapewnienie identycznego odszyfrowania między platformami ujawniło kluczowe niezgodności.

UTF-8 w pochodzeniu kluczy

Java PBEKeySpec przekształca hasło przez char[], iOS — przez bajty utf8. Rozwiązanie: niestandardowa PBKDF2 na Androidzie z passphrase.toByteArray(Charsets.UTF_8).

Wizualnie identyczne znaki

Hasło „a” (cyrylica U+D0B0) na iPhone vs łacińskie „a” (U+0061) na Android. Testowanie skryptem Python potwierdziło różnice w kluczach.

Wybór KDF

Argon2id na Androidzie kolidował z CI/CD (problemy zależności). Przejście na PBKDF2 zapewniło unifikację.

Publikacja: lekcje App Store i RuStore

App Store: dwie odmowy z powodu wzmianek o komunikatorach w metadanych, wygenerowanych zrzutów ekranu i niepełnych lokalizacji. Wymagania: rzeczywiste zrzuty ekranu, czyste opisy, pełne lokalizacje, Support URL z kontaktami.

RuStore: zrzuty ekranu ściśle 9:16, rosnący versionCode.

Co jest ważne

• Praca offline: brak żądań sieciowych, dane nie opuszczają urządzenia.
• Kompatybilność: zaszyfrowane na Androidzie — odszyfrowane na iOS/Windows.
• Odporność: AES-256-GCM + PBKDF2 (600k iteracji) przeciw brute-force.
• Prostota: kopiuj/wklej przez dowolny transport.
• Otwartość: potencjalny open source do audytu.

Wykorzystanie w projektach

Integracja z istniejącymi aplikacjami jest możliwa przez eksport logiki szyfrowania. Dla middle/senior-developerów: zaimplementuj PBKDF2 ze stałymi parametrami dla kompatybilności krzyżowej. Testuj na rzeczywistych urządzeniach, skupiając się na normalizacji UTF-8 haseł.

— Editorial Team