Shadowsocks dokumentasjon
Navigasjon
FREM
FREM står for Authenticated Encryption with Associated Data. AEAD-siffer gir samtidig konfidensialitet, integritet og autentisitet. De har utmerket ytelse og strømeffektivitet på moderne maskinvare. Brukere bør bruke AEAD-chiffer når det er mulig.
Følgende AEAD-chiffer anbefales. Kompatible Shadowsocks-implementeringer må støtte AEAD_CHACHA20_POLY1305. Implementeringer for enheter med maskinvare-AES-akselerasjon bør også implementere AEAD_AES_128_GCM og AEAD_AES_256_GCM.
Navn | Alias | Nøkkelstørrelse | Salt størrelse | Ikke-størrelse | Tagstørrelse |
AEAD_CHACHA20_POLY1305 | chacha20-ietf-poly1305 | 32 | 32 | 12 | 16 |
AEAD_AES_256_GCM | aes-256-gcm | 32 | 32 | 12 | 16 |
AEAD_AES_128_GCM | aes-128-gcm | 16 | 16 | 12 | 16 |
Vennligst se IANA AEAD-registeret for navneskjema og spesifikasjon.
Nøkkelavledning
Hovednøkkelen kan legges inn direkte fra brukeren eller genereres fra et passord.
HKDF_SHA1 er en funksjon som tar en hemmelig nøkkel, et ikke-hemmelig salt, en infostreng, og produserer en undernøkkel som er kryptografisk sterk selv om den hemmelige inngangsnøkkelen er svak.
HKDF_SHA1(nøkkel, salt, info) => undernøkkel
Infostrengen binder den genererte undernøkkelen til en spesifikk applikasjonskontekst. I vårt tilfelle må det være strengen "ss-subkey" uten anførselstegn.
Vi utleder en undernøkkel per sesjon fra en forhåndsdelt hovednøkkel ved å bruke HKDF_SHA1. Salt må være unikt gjennom hele levetiden til den forhåndsdelte hovednøkkelen.
Autentisert kryptering/dekryptering
AE_encrypt er en funksjon som tar en hemmelig nøkkel, en ikke-hemmelig nonce, en melding og produserer chiffertekst og en autentiseringskode. Nonce må være unik for en gitt nøkkel i hver påkalling.
AE_encrypt(key, nonce, message) => (chiffertekst, tag)
AE_decrypt er en funksjon som tar en hemmelig nøkkel, ikke-hemmelig nonce, chiffertekst, en autentiseringskode og produserer en original melding. Hvis noen av inngangene tukles med, vil dekrypteringen mislykkes.
AE_decrypt(nøkkel, nonce, chiffertekst, tag) => melding
TCP
En AEAD-kryptert TCP-strøm starter med et tilfeldig generert salt for å utlede undernøkkelen per økt, etterfulgt av et hvilket som helst antall krypterte biter. Hver del har følgende struktur:
[kryptert nyttelastlengde][length tag][kryptert nyttelast][nyttelasttag]
Nyttelastlengden er et 2-byte big-endian usignert heltall begrenset til 0x3FFF. De to høyere bitene er reservert og må settes til null. Nyttelast er derfor begrenset til 16*1024 – 1 byte.
Den første AEAD-krypterings-/dekrypteringsoperasjonen bruker en tellende nonce som starter fra 0. Etter hver krypterings-/dekrypteringsoperasjon økes nonce-en med én som om den var et usignert lite-endian-heltall. Merk at hver TCP-del involverer to AEAD-krypterings-/dekrypteringsoperasjoner: én for nyttelastlengden og én for nyttelasten. Derfor øker hver del nonce to ganger.
TCP
En AEAD-kryptert TCP-strøm starter med et tilfeldig generert salt for å utlede undernøkkelen per økt, etterfulgt av et hvilket som helst antall krypterte biter. Hver del har følgende struktur:
[kryptert nyttelastlengde][length tag][kryptert nyttelast][nyttelasttag]
Nyttelastlengden er et 2-byte big-endian usignert heltall begrenset til 0x3FFF. De to høyere bitene er reservert og må settes til null. Nyttelast er derfor begrenset til 16*1024 – 1 byte.
Den første AEAD-krypterings-/dekrypteringsoperasjonen bruker en tellende nonce som starter fra 0. Etter hver krypterings-/dekrypteringsoperasjon økes nonce-en med én som om den var et usignert lite-endian-heltall. Merk at hver TCP-del involverer to AEAD-krypterings-/dekrypteringsoperasjoner: én for nyttelastlengden og én for nyttelasten. Derfor øker hver del nonce to ganger.
